Custom MCP server development for your product
A custom MCP server exposes your product to AI agents through the Model Context Protocol, so your customers can use it from Claude, ChatGPT, Cursor or their own agents. I design and build them: the tools, the auth, the permissions and the evals that make an agent actually succeed with your product.
I’ve done this for my own product. Craaft ships an MCP server alongside its REST API, and AI agents use it to work the same kanban board as the humans on the team.
Why SaaS companies are building MCP servers
Your customers are starting to work through AI assistants. If their assistant can’t reach your product, it routes around you – to a competitor that it can reach, or to copy-and-paste. An MCP server is how you show up inside those tools.
MCP is an open protocol: one server works with any compliant client, so you don’t build a separate plugin for each AI vendor. If you need the basics first, read what is an MCP server.
Tool design is the whole game
Wrapping every REST endpoint as a tool is the most common mistake in MCP server development. Agents choose tools by reading names and descriptions, and they get worse as the list grows and the tools get vaguer. Good tool design looks like this:
- Model tasks, not endpoints. One “move card to column” tool beats three calls to fetch the column, update the position and rebalance the order.
- Descriptions written for a model. What the tool does, when to use it instead of its neighbor, what each argument means, and an example.
- Compact, relevant output. Return the fields an agent needs to take the next step, with IDs it can pass on. Paginate. Don’t dump a 40 KB JSON blob into the context window.
- Errors an agent can recover from. “Column ‘Done’ not found; available columns: Backlog, Doing, Review” lets the model fix its own call. A bare 400 doesn’t.
- Bulk operations where agents need them. Agents often want to create or update many items at once; a bulk tool saves dozens of round trips and tokens.
- Read-only and destructive tools clearly separated, with annotations clients can use to ask for confirmation.
In Craaft, the tools follow how people actually use a board – get the board, create or move cards, comment, check what needs attention – rather than mirroring database tables.
Auth and permissions
A remote MCP server is a public API that a model drives, so treat it like one. For remote servers I implement the protocol’s OAuth-based authorization so users grant access through your existing login, with scoped tokens and revocation. For developer and automation use, personal access tokens are often simpler.
The server must enforce the same permissions as your UI – no service account that sees every tenant. In Craaft an agent has exactly the access of the user or member it acts as: same cards, same permissions. Add rate limits per token, audit logs for every tool call, and input validation as strict as any public endpoint. Assume the agent calling you may have been prompt-injected by content it read elsewhere.
What a build includes
- Tool inventory. We list the jobs customers would want an agent to do in your product and design the smallest set of tools that covers them.
- Server implementation with an official MCP SDK, in your stack, reusing your existing service layer so business rules live in one place.
- Transport and hosting. Streamable HTTP for a hosted, multi-tenant server; stdio for a local or developer-tooling server. Deployed alongside your API with the same monitoring.
- Auth, permissions and rate limiting as above.
- Agent evals. Scripted tasks run against real MCP clients to check that agents pick the right tools and complete the job. Tool descriptions get tuned from the failures.
- Docs and listing so customers can connect it in a few clicks.
MCP server or agent?
An MCP server lets other people’s agents use your product. If you want an agent inside your product doing work for your users, that’s AI agent development. Many teams do the MCP server first: it’s smaller, it reuses your API, and it shows you what customers actually ask agents to do. If your product has no clean API yet, that’s the first job – an MCP server built on a tangle of controllers inherits the tangle.
Do you need a custom build?
Not always. If you only need an internal agent to call a handful of endpoints, a generic OpenAPI-to-MCP bridge may be enough for a while. A custom MCP server earns its cost when customers will use it, when permissions are non-trivial, or when agents are failing on your auto-generated tools. I’ll tell you which camp you’re in during the first sprint. For the security side of exposing tools to agents, see AI agent security.
Questions
What is a custom MCP server?
It’s a server built for your product that implements the Model Context Protocol, exposing tools, resources and prompts that AI clients like Claude, ChatGPT and Cursor can discover and call. Custom means the tools are designed around your product’s tasks and permissions rather than auto-generated from an API spec.
How long does it take to build an MCP server?
A focused server over an existing, well-structured API can be working with real clients inside a two-week sprint. Remote hosting with OAuth, tenant isolation, evals and documentation for customers takes longer, mostly depending on the state of your API and auth.
Should our MCP server be local or remote?
For a SaaS product, remote over Streamable HTTP is usually right: customers connect with a URL and sign in, and you control updates. Local stdio servers suit developer tools that need access to files or a local environment.
Is an MCP server secure?
It’s as secure as you make it. Enforce your existing permissions on every call, use scoped OAuth or personal tokens, rate-limit, log every tool call, and validate inputs strictly. Treat requests as coming from a model that may have read malicious content.
Want AI agents to use your product properly?
Tell me what customers would ask an agent to do. In a two-week sprint we design the tools, build the server on your API and test it with real clients.
GMT+2 · Full EU overlap · US East mornings