MCP server development

What MCP is for, in plain terms

Without a standard, every assistant needs its own plugin or API glue to reach your system. The Model Context Protocol defines one way for an assistant (the client) to ask a server what it can do and then call it. You write the server once and compatible clients can use it.

Typical owners of an MCP server are SaaS companies who want customers to use their product from inside an assistant, and companies that want staff to query internal systems through one approved doorway.

Worked example: one tool, designed carefully

Take an invented billing system. The lazy design exposes a tool called run_query that accepts SQL. It works in a demo and is a security incident waiting to happen. The careful design looks like this.

• Name and description: find_invoice, 'Look up one invoice by number and return status, amount and due date.' The model chooses tools from these words, so they must be exact.
• Input schema: invoice_number as a string matching a known pattern. No free text, no SQL.
• Authorization: the tool runs as the signed-in user, so it can only see invoices that user may see.
• Output: a short structured object, not the whole database row. Less output means less cost and less to leak.
• Limits: rate limit per user, a timeout, and an audit log line with user, tool, input and result size.
• Second tool, later: send_payment_reminder, which needs a confirmation step because it has side effects.

What a build includes

We have no published case study on MCP servers, so this is the usual scope rather than a client reference.

1. Tool inventoryList what people actually ask assistants to do with your system. Keep the first release to five tools or fewer.
2. Design and schemasNames, descriptions, typed inputs and outputs, error messages the model can act on.
3. AuthOAuth sign-in for hosted servers so each user acts with their own rights, or scoped service tokens for internal use.
4. Build and testServer in TypeScript or Python, tested with more than one client, plus a set of adversarial prompts.
5. Deploy and observeHosting, logging, usage dashboards and a runbook for revoking access.

If you want the assistant side too, see AI agent development and AI integration.

Security gotchas

• Prompt injection through tool results. If a tool returns text from a support ticket or web page, that text may contain instructions aimed at the model. Treat returned content as data, and never give one tool both untrusted input and a powerful action.
• Over-broad tools. Every extra capability widens what a mistaken or manipulated model can do. Start read-only.
• Shared credentials. One service token for everyone erases accountability. Prefer per-user authorization.
• Descriptions that mislead. A tool named 'cleanup' that deletes records will be called at the wrong moment.
• Local servers on laptops. A server that runs on a user's machine runs with that user's rights and may fetch code from a package registry. Pin and review it.

Our AI agent security checklist covers the review we run before any server goes live.

Timeline

The protocol is still young and clients differ in what they support, so we allow time to test against each client you care about. The quote fixes the scope and the list of clients.