An MCP server is the entry point that lets AI agents call the functions of your internal systems and SaaS products. MCP (Model Context Protocol) is an open specification for connecting AI applications to external systems. An MCP server gives the AI a list of the operations it can use, along with a description and an argument schema for each one. The AI reads the user’s request and decides on its own which operation to call and with which arguments. This guide explains how MCP works and walks through building an MCP server for your own systems, including how to design permissions.
How MCP works
Anthropic introduced MCP in November 2024, and the specification is published by version at modelcontextprotocol.io. Three roles are involved:
- Host: the AI application the user works in, such as Claude, Claude Code or Cursor
- Client: the part of the host that talks to MCP servers
- Server: the side that exposes your system’s functions to the AI. This is what you build
The specification defines three main things a server can offer:
| Primitive | What it is | Example |
|---|---|---|
| tools | Operations the AI can execute | List bookings, issue an invoice |
| resources | Context and data for the AI or the user | The text of a policy, product settings |
| prompts | Templated instructions the user can pick | A step-by-step “monthly report” workflow |
In business systems, tools do most of the work. For each tool you define a name, a description of what it does, and an argument schema in JSON Schema. Because the AI chooses between tools by reading their descriptions, the quality of your descriptions directly determines how accurately the AI uses your system.
There are two transports. With stdio, an AI tool on the user’s machine launches the server as a subprocess. With Streamable HTTP, the server is published at a URL. If several people in your company, or a cloud AI such as claude.ai, will use the server, choose HTTP. For HTTP servers, the specification defines authorization based on OAuth 2.1.
Steps to build an MCP server for your systems
- Decide which jobs to hand to the AI. Pick tasks people currently do on screen, such as “list last month’s unpaid invoices” or “find open booking slots.” Starting with read-only jobs is the safe choice
- Split operations into tools. Split by job, not by button. Several focused tools are easier for the AI to choose between than one tool with many arguments
- Write descriptions and arguments. Each description should say what the tool does, when to use it, what it returns, and when not to use it. Give arguments types and allowed values (enums)
- Connect to your existing API. Build the MCP server as a thin layer that calls your API, and keep business rules and input validation in the API. That way the same rules apply whether a person or the AI is acting
- Wire up authentication. For HTTP servers, authenticate users with OAuth and call your API with that user’s permissions. Avoid running everything on one shared, highly privileged key
- Test and refine the descriptions. Try both expected and ambiguous requests from a real AI client. When the wrong tool gets called, rewrite its description
Designing permissions and audit logs
Even when the AI performs an operation, responsibility stays with the person who asked for it. Design permissions along these lines:
- Act as the user. If someone can only view data in your admin console, they can only view it through the AI as well. Do not build a separate permission system just for the MCP server
- Introduce writes in stages. Expose read-only tools first. For updates and deletions, add a stopping point: refuse to run without a confirmation argument, or let the AI create only a draft that is published through approval in the admin console
- Leave out high-impact operations. Bulk deletion, permission changes or changing where data is sent outside the company can simply be left out of MCP
- Keep a record. Log when, who, which tool, which arguments and what came back, and mark operations that came through the AI
- Return only what is needed. Tool results end up in the AI conversation. Return only the fields the job needs, especially for personal data and secrets
What to check before going live
| Area | What to check |
|---|---|
| Descriptions | Can a human tell what a tool does from its name and description alone? |
| Arguments | Are types, required fields and enums defined, and does the server reject invalid values? |
| Permissions | Do viewing and changing follow the same roles as your admin console? |
| Confirmation | Do updates and deletions have a stopping point? |
| Audit | Can operations made through the AI be audited? |
| Results | Does each tool return only the fields needed, and are long lists paginated? |
| Errors | Do error messages tell the AI what to do next? |
SHANNON products that support MCP
Many of our products support MCP. With Webhook Admin, AI agents can register endpoints and retry failed deliveries. With DocRelay, they can create templates and issue documents. With Kiteilog, they can read current rules and past versions and draft revisions, which are then published through approval in the admin console. If you want to add an MCP server to your own systems, see our AI agent development page.
References
- Anthropic: Introducing the Model Context Protocol
- Model Context Protocol: Specification
- Model Context Protocol: Transports
- Model Context Protocol: Authorization
FAQ
What is the difference between an MCP server and an API?
An API is an interface that programs call; an MCP server is an interface that AI agents call. An MCP server hands the AI a list of available operations, with a description and an argument schema for each. The AI reads those descriptions and decides which operation to call with which arguments. In practice, an MCP server is often a thin layer on top of your existing API.
Does an MCP server have to run inside our internal network?
It depends on who uses it. If one person uses it from an AI tool on their own machine, a local stdio server is enough. If several employees or a cloud AI such as claude.ai need it, publish it over HTTP and authenticate users, for example with OAuth. Keep in mind that a server reachable only inside your network cannot be reached by cloud-hosted AI.
Could the AI update or delete data by mistake?
It can happen, so design against it. Start by exposing read-only operations, and require an explicit confirmation step for updates and deletions, such as a confirmation argument or approval in your admin console. Run every operation with the requesting user's own permissions, and log who called which operation.
