MCP Servers: Connecting Existing Software to AI

MCP is a protocol boundary, not a replacement for application engineering

The Model Context Protocol defines how a host application, clients, and servers exchange capabilities and context. In the current specification architecture, a host manages client instances; each client maintains a connection to a server; servers expose focused capabilities. Servers can provide tools, resources, and prompts, and both sides negotiate which features they support.

That standard boundary is valuable because each client integration does not need a completely unrelated contract. But an MCP server does not make an unsafe API safe, invent missing authorization, or decide which application actions should be exposed. Those remain engineering and product decisions.

The authoritative starting point is the MCP architecture specification. Because the protocol continues to evolve, production work should pin a protocol revision and review changes before upgrading.

Tools, resources, and prompts serve different roles

Tools are executable capabilities a model can request: find an account, prepare a draft, create a ticket, or advance a workflow. A useful tool has a narrow purpose, a clear name, typed inputs, predictable outputs, and explicit errors.

Resources provide context or data that a client can read and attach. Examples might include a policy document, a record view, or a generated status representation. Resources are not a back door around the source application’s permissions.

Prompts are reusable templates or interaction starters exposed by the server. They can guide a user into a known workflow, but should not be confused with enforceable security policy.

The MCP server overview describes these primitives and their control relationship. Not every client supports every feature in the same way, which is why “MCP-compatible” must be tested against the actual clients an organization intends to use.

Start from the existing application

A production server usually sits over application APIs or services that already understand users, tenants, records, and rules. Inventory those boundaries before defining MCP primitives:

1. Which users or machine identities will connect?
2. Which records can each identity read?
3. Which actions are safe to expose?
4. Which actions require confirmation or separate approval?
5. Which API errors and retry behaviors are meaningful?
6. What should be logged for audit and diagnosis?

Do not start by wrapping every endpoint. Low-level or overly broad tools increase selection ambiguity and enlarge the consequence of a bad call. Prefer task-shaped tools that preserve the application’s own language and validation.

Authorization must bind to the right resource

For HTTP-based protected servers, the MCP authorization specification defines an OAuth-based flow and requires resource-aware token handling. The server acts as a protected resource; tokens must be validated for the intended audience; token passthrough to downstream APIs is prohibited. The current MCP authorization specification also defines protected-resource metadata and authorization-server discovery.

The practical implication is important: the token presented to the MCP server is not a generic credential to forward everywhere. If the server calls an upstream application API, it needs a deliberate downstream identity and authorization design. Tenant and user context should remain explicit at every boundary.

Local stdio servers and remote HTTP servers have different credential and deployment considerations. Choose the transport and hosting model around the intended client, environment, and operational ownership.

Tool safety lives in several layers

A model-readable tool description helps selection; it does not enforce policy. Strong tool execution includes:

• schema validation and size limits;
• authentication and authorization;
• allow-listed identifiers or scopes where appropriate;
• idempotency for repeatable write requests;
• confirmation or approval for consequential actions;
• timeouts and bounded retries;
• redaction-aware logs;
• clear, non-sensitive error messages;
• protection against instructions embedded in untrusted resource content.

Read tools and write tools often deserve different controls. A search tool may be broadly useful while a delete, payment, publication, or customer-contact action may be excluded entirely or placed behind an approval workflow.

Test the server as a product interface

Protocol conformance is necessary but incomplete. Test representative client tasks: discovery, selection, valid calls, malformed arguments, expired credentials, insufficient scopes, upstream timeouts, duplicate requests, partial responses, and server upgrades.

Also evaluate the model-facing contract. Does the intended client select the right tool among realistic alternatives? Are descriptions distinct? Are schemas small enough to understand? Does the result return the minimum context required for the next step?

Compatibility is empirical. Verify each intended host or client and document the supported revision, transport, authentication pattern, and known limitations.

Deployment and change management

Treat tool schemas as external interfaces. Renaming a field, changing an enum, or altering error behavior can affect client behavior even when an application API remains stable. Version deliberately, keep contract tests, and observe selection and execution failures after release.

The best MCP server is usually focused: a clear capability surface over a well-understood application boundary, operated by a team that owns its permissions and downstream effects.

Sources and further reading

• MCP specification: Architecture
• MCP specification: Server primitives
• MCP specification: Authorization

See MCP Server Development & AI Tooling for CodeCradle’s implementation approach.