MCP server development

Without a shared standard, connecting five systems to four assistants means twenty separate integrations. With MCP, each system is built once as a server and each assistant acts as a client. The work then grows with the number of systems, not with systems multiplied by assistants.

An MCP server exposes three things:

• Tools - actions the model can invoke, each with a name, a description and a typed schema for its arguments.
• Resources - data the model can read, addressed by identifier, so context can be pulled in deliberately.
• Prompts - reusable templates the server offers for common tasks, so usage guidance ships with the capability.

The protocol is the plumbing, not the intelligence. An MCP server makes a capability reachable. Deciding when to reach for it, and what to do when it fails, is the agent's job. So Fig AI Systems treats MCP work as part of the same practice as custom AI agent development.

1. Tool and resource design. Every tool needs a name and description that are unambiguous on their own. Argument types must be tight enough to refuse an invalid call. Vague tools are the most common reason a model uses a server badly.
2. Authentication and secret handling. The server holds credentials for the systems behind it; the model never should. Tokens are scoped to the narrowest permission that still does the job. Per-user identity is carried through, not collapsed into one shared service account.
3. Scoping what the model may read and do. Read and write are separated. Destructive operations are excluded or gated behind an explicit confirmation. Resources are filtered to what the current user may see. A server should be safe when the model is wrong.
4. Error surfaces a model can recover from. An error returned to a model is an instruction, not a log line. Name the wrong argument and state the accepted values, and you get a corrected retry. A bare stack trace gets an abandoned task or a confident invention.
5. Transport choice. A local server and a network-reachable server differ in security, deployment and sessions. The choice follows from where the data lives and who must reach it.
6. Rate limiting and cost control. Models retry, loop and call in parallel. Limits, timeouts, pagination and result-size caps protect the systems behind the server and the context window in front of it.
7. Testing under a model. Unit tests prove a tool returns the right value for the right arguments. They say nothing about whether a model picks the right tool from the description, supplies sane arguments, or recovers from an error.

That last point is a discipline in its own right, covered on the closed-loop AI evaluation page. With several servers and agents in play, sequencing and failure propagation become the subject of multi-agent orchestration.

The work generally covers:

• Packaging - building the server in the form the target ecosystem expects, including how users install and authenticate it.
• Review expectations - going through each ecosystem's published requirements on permissions, data handling and behavior.
• Documentation - user- and reviewer-facing material stating what the integration does, what data it touches and which tools it exposes.
• Iterating on feedback - reviews come back with questions and requested changes. Fixing and resubmitting is part of the job.

Each ecosystem runs its own review on its own terms. We do the preparation and the iteration; the outcome and the schedule are theirs, and we will not pretend otherwise.

Build an MCP server when one of these is true:

• The same tools must be reachable from several assistants.
• The tool surface is large enough that bespoke connectors are real work.
• You want the integration distributed outside your own team.
• The capability is a product in its own right, and you want it usable where your users already work.
• Centralizing auth, scoping and audit in one place is worth an extra component.

Do not build an MCP server when exactly one assistant will ever use it and the surface is two or three calls. The protocol layer is then overhead with no payoff. The same applies to a one-off script, or to a system with no stable API to wrap yet.

Sometimes what you want is an application of your own. The products Fig AI Systems has built and owns are examples of that shape.

Get the capability correct and observable first. Expose it over MCP once the tool surface is settled. Wrapping an API you are still redesigning means rewriting schemas the model depends on.