Most people who ask me about a custom MCP server start with the wrong spec. They want every endpoint of their API exposed to the agent. That's the fastest way to get an agent that picks the wrong tool, burns context and can't be trusted with write access.
Short answer: a good MCP server exposes the handful of tools your agents actually need, scoped to your data and permissions. Before you hire anyone, be able to say which systems the agent has to reach, what it should do there, who it acts as, and where the server will run. Those four answers decide most of the timeline.
What You're Actually Buying
An MCP server is a translation layer. On one side is your system: Salesforce, an internal API, a database, a SaaS tool. On the other is any client that speaks the Model Context Protocol: Claude, Agentforce, or one of the growing list of agent platforms. The server decides what the agent can see and do.
So the deliverable isn't really code that calls an API. It's a set of decisions about which actions exist, what they return, and what the agent is never allowed to touch. The code is the easy part.
Tools, Not Endpoints
The biggest difference between a server that works in a demo and one that works in production is tool design.
- Fewer, task-shaped tools. "Find open cases for this account" beats exposing generic query, describe and retrieve calls and hoping the model strings them together.
- Clear names and descriptions. The model picks tools by reading them. Vague names mean wrong picks.
- Small, predictable responses. Return the fields the agent needs, not the whole record. Big payloads crowd out the rest of the conversation.
- Errors the agent can act on. "No account found with that name, try the account number" gets a retry. A raw stack trace gets a hallucination.
If someone quotes you a server by counting endpoints, ask how they decide what not to expose.
What Drives the Timeline
On my projects these are the things that move the estimate, roughly in order:
- Number of systems. One system is the simple case. Each additional system adds its own auth, data model and failure modes.
- Read only or read and write. Writes need confirmation patterns, validation and audit logging. Read-only servers ship much faster.
- Auth model. An API key for one internal user is quick. OAuth so each person acts as themselves, with their own permissions, takes real design.
- Where it runs. Local next to Claude Desktop or Claude Code is the fastest. A hosted remote server for a whole team adds deployment, monitoring and access control.
- Tenancy and compliance. Multi-tenant or regulated deployments add isolation, a security review and more testing.
For reference, a single-system server is typically 1 to 2 weeks, multi-system with auth and remote deployment 2 to 4, and multi-tenant or regulated deployments 4 to 8.
Security Questions to Settle Early
Agents with write access to production data need the same scrutiny as any integration user, plus a few things specific to AI:
- Who does the agent act as? A shared service account is simple but flattens permissions. Per-user OAuth keeps your existing sharing model intact.
- Least privilege. The server's credentials should only reach what its tools need.
- Read-only modes. Useful for rollout. Let people trust it on reads before you turn on writes.
- Audit logs on every write. You want to know what the agent changed, when and for whom.
- Prompt injection. Anything the server returns, like a case description or an email body, can carry instructions. Tools that write should never act on text they just read without a check.
Questions to Ask Before You Hire
- Which tools would you build for our use case, and which parts of the API would you leave out?
- How do you handle auth, and can users act as themselves?
- How do you test it? Against our real systems or mocks?
- What happens when the MCP spec changes?
- Who maintains it after launch?
- Does it work with more than one AI platform, or only one vendor's client?
The last one matters more than it looks. MCP's whole value is that you build the server once and any compatible client can use it. A build that only works in one tool gives that up.
Build It Yourself or Hire It Out
If you have engineers who know the system well and the server is read-only for internal use, build it yourself. The SDKs are good and a first server is a reasonable weekend project.
Hire it out when the server writes to production systems, spans more than one system, needs per-user auth, or has to be hosted for a team. That's where the tool design and security decisions take experience, and where mistakes are expensive.
If you want a second opinion on how yours should be scoped, book a call. More on how I build and deliver them on the MCP development page.