MCP Server Development for Business Systems

What does an MCP server expose?

According to the official MCP introduction, MCP is an open-source standard for connecting AI applications to external systems, and it is supported by AI assistants such as Claude and ChatGPT and by development tools such as Visual Studio Code and Cursor. A server can offer three kinds of thing, and each one is controlled by a different party.

• Tools are actions the model can call, such as find a customer or create a draft invoice. The specification describes them as model-controlled and says a human should always be able to deny a call.
• Resources are readable data identified by a URI, such as a database schema or a policy document. They are application-driven: the client app decides what context to include.
• Prompts are reusable instruction templates that a user chooses explicitly, often shown as slash commands.

Most business servers are mainly tools, with a few resources. Prompts are the least common.

Do you need an MCP server at all?

Often you do not. The decision is mostly about how many AI clients will touch the system, and who.

• One automation, one system. A direct API call inside an n8n workflow is simpler and cheaper to maintain.
• One agent you control end to end. Function calls defined inside the agent are enough. See agentic AI development.
• Several AI clients, or staff using their own AI tools. This is where MCP pays off. You build the connection once and each compatible client reuses it.
• A SaaS product that customers want to use from Claude. A remote MCP server becomes a product feature, which is why it often sits alongside AI SaaS development.

Our design rules for a server you can trust

1. Few tools, narrow tools. Ten well-named tools beat a hundred overlapping ones. Models choose better from a short list, and every extra tool is extra attack surface.
2. Read before write. The first release only looks things up. Each write tool is added separately and starts as a proposal that a person confirms.
3. No tool that does everything. We avoid a generic run-any-query or send-any-request tool. If a task needs a query, it becomes a named tool with fixed shape.
4. Per-user identity. A shared admin key means every person's AI client acts with admin rights. Sign-in per user keeps the permissions your system already has.
5. Validate everything on the server. The specification says servers must validate tool inputs, apply access controls, rate limit calls and sanitise outputs. We treat the model's arguments like any untrusted form submission.
6. Log every call. Caller, tool, arguments, result status and time.
7. Treat returned content as untrusted. A support ticket or web page that passes through a tool can contain instructions aimed at the model. Permissions, not hope, limit what such text can cause.

Local or remote: how do you choose a transport?

The specification defines two standard transports. Anthropic's own guidance for servers that other people use in Claude is to use Streamable HTTP, and Claude Code's documentation marks the older SSE transport as deprecated.

Authorisation is optional in the specification, but for HTTP-based servers it is built on OAuth 2.1, and servers must check that a token was issued for them as the audience. The specification also tells HTTP servers to validate the Origin header, and local ones to bind to localhost.

Illustrative example: a CRM server

This is a worked example of how a scope might look, not a client project. Say a sales team wants to ask Claude about their pipeline.

• find_contact and list_open_deals: read-only, available to everyone who signs in, filtered by the user's own territory.
• get_deal_history: read-only, returns notes and stage changes, with personal fields redacted by rule.
• draft_follow_up_note: writes a note flagged as draft, which the owner must confirm in the CRM.
• Not exposed at all: deleting records, changing deal values, bulk export.

The point is the last line. Deciding what is left out matters as much as what is built.

Where Claude can use it, and what to watch

Anthropic's documentation says people add a server to Claude as a custom connector by entering its URL, or get it from a reviewed directory, and that Claude connects from claude.ai, Claude Desktop, mobile, Cowork and Claude Code. Three practical limits, as of November 2026, are worth knowing:

• Claude does not yet support resource subscriptions or sampling, so we do not build features that depend on them.
• On claude.ai and Desktop, tool results are capped at roughly 150,000 characters and each call times out after 240 seconds, so big exports belong in a link, not in a response.
• The protocol itself is changing. The latest specification revision changed how Streamable HTTP handles sessions, and SDKs adopt revisions on their own schedules. We pin to what your clients support and plan upgrades, instead of assuming the newest revision.

Check the vendor documents for current figures before you design around any of these.

When not to commission an MCP server

• No one will use AI clients with it. If the only consumer is one automation, skip the protocol.
• Your underlying system has no usable API or permissions model. Fix that first, since MCP exposes what is already there.
• You expect the model alone to enforce access rules. Rules must be enforced in the server and the system behind it.
• You need a customer-facing assistant rather than staff tooling. That points to a custom assistant on company data or a chatbot.

For the background, see our guide to what MCP means for business. To describe your system and get a scoped plan, contact us.