Service · 03 — MCP servers

MCP servers for the tools you already use.

The Model Context Protocol lets an AI assistant call your real tools — your database, your internal API, your CMS — through a typed, audited interface instead of a hand-rolled chat plugin. The studio builds those servers, free and paid.

What you get

• An MCP server tailored to your tools — not a generic shim. Real schemas, real auth, real error messages the assistant can actually act on.
• Compatibility with Claude Desktop, OpenClaw, and any spec-compliant client out of the box. One server, every assistant your team uses.
• Auth handled properly — OAuth, API keys, or per-user delegation. Your secrets stay your secrets; the assistant never sees them.
• Per-tool rate limiting and audit logs so a runaway prompt can’t drain a paid API or delete production data.
• A SKILL.md next to the server describing every tool exposed, what it does, what it returns, and the gotchas — so the LLM uses it correctly without you babysitting the prompt.
• Open source by default. Private fork on request when the work is sensitive.

Recent work in this space

• OpenClaw Free MCP Servers — open-source MCP servers for image generation and text-to-speech, designed to need no API keys for the basics. Reference architecture for how the studio structures provider-agnostic MCP servers.
• Presearch Search Skill — clean SKILL.md for the Presearch API; example of how to wrap a third-party data source so an agent uses it correctly on the first try.
• Private client servers — covered by NDA, but we’ll walk you through the design patterns on a call.

How scoping an MCP server goes

1. Which tools do you want exposed? Read-only first is usually right — “list tickets”, “search the wiki”, “get current usage”.
2. Who’s calling it? A single user’s desktop assistant, a team-shared server, or an automated agent in CI?
3. What can the assistant safely do without confirmation? What requires “are you sure?” What is never allowed?
4. How do you want to see what it did? Server logs, audit DB, Slack pings on writes — pick what fits your ops.

Honest answers

Should this be open source or private?

If the server wraps a generic API everyone uses (a public datastore, a popular SaaS), open source helps everyone and earns you reputation. If it wraps your proprietary internal API, keep it private — that’s a default, not a debate. We’ll decide together on the kickoff call.

Can it be self-hosted?

Yes — most MCP servers we build run as a small process on the same machine as the assistant, or as a container behind your auth. No SaaS dependency unless you specifically want one.

Will it work with future MCP versions?

Built against the published spec, with a small adapter layer where the spec is still moving. When a breaking change lands, the upgrade is a small PR — usually within a week of the spec update.

Cost?

A read-only server wrapping a single API, with auth and audit logs, lands in the low four figures. A team-grade server with multiple tools, write paths, and per-user delegation is meaningfully more. Quote within two business days of a one-paragraph brief.

Stack

MCP + Py

Turnaround

2–6 wks

License

OSS or private

Location

Remote, US