Where MCP Fits in a Real AI System

An assistant can find an order, read a support ticket and prepare a reply. Now someone wants it to issue refunds too.

At that point, “we connected it with MCP” tells me very little about whether the system is ready. I still want to know whose account it uses, which orders it can access and what happens before money moves.

MCP, the Model Context Protocol, is useful to understand because it gives AI applications a shared way to connect to tools and information. It also leaves plenty of work for the people designing the application. Here is where I would put that work.

Draw the connection before choosing the framework

In MCP terminology, the host is the AI application. It creates a client connection to an MCP server, which exposes capabilities. The server can run locally or remotely. It might wrap an existing order API rather than store orders itself. The official architecture overview describes those roles and keeps MCP’s scope separate from the application’s use of the model.

Tools are callable operations, such as looking up an order. Resources expose contextual material; prompts provide reusable interaction templates. You do not need to use all three to make one useful connection.

For our support example, the host manages the conversation and presents the result to the person. The server adapter translates a tool request into something the order system understands. The order system still decides whether the requested operation is allowed.

The practical benefit is a common integration surface for compatible applications. It can reduce repeated adapter work when several assistants need the same capabilities. It does not tell the business what a refund policy should be.

Design tools around decisions people recognise

I would start with a small set of operations: find an order, read its delivery status and request a refund for a specific order and amount.

A generic “execute anything” tool might be convenient while experimenting. In a support product, it would make the allowed behaviour harder to explain, review and test. Narrow operations give the team somewhere concrete to put the rules.

The MCP tools specification defines tools with names, descriptions and input schemas. A schema describes the shape of the request. It cannot establish that this customer owns the order or that the amount is refundable. Those checks belong in the implementation.

I would make the results equally specific. “Refund request accepted” and “Refund completed” should be different outcomes, with an identifier the application can check. A successful protocol exchange is not evidence that the customer’s money has arrived.

Keep responses proportionate to the task too. Reading a delivery status should not return every customer field because it happens to be available in the database. That is an interface decision the team can make before involving a model.

Keep approval and permission separate

A person clicking “Approve refund” expresses an intention. The backend still needs to verify that the person is allowed to refund this order, that the amount is eligible and that the request has not already been processed.

I would show the order and amount before that approval. I would enforce the rules in the order service, where another client cannot bypass them by wording a request differently.

The tools specification recommends visible tool activity and a human ability to deny invocations. It does not prescribe the whole interface. It also says tool annotations must be treated as untrusted unless they come from trusted servers. A label describing an operation as read-only is not a substitute for enforcing what it can do. Tools specification.

For a remote connection, I would review the credentials separately at each boundary. The MCP security guidance explicitly forbids token passthrough: accepting a token without the proper validation and forwarding it to a downstream API is not a sound shortcut. It also covers risks from local servers, which are programs running on the user’s machine.

For our example, the design questions are straightforward: which identity reaches the order service, how is its account scope enforced, and what can the host record without copying sensitive order details into logs? Those answers belong in the architecture review alongside the connection diagram.

Decide whether MCP earns its place

If I own one application calling one internal API, a direct API integration may be the clearest option. An extra server brings another component to run, version, monitor and troubleshoot.

I would consider MCP when the same capability needs to work across several compatible hosts, or when users need to connect an existing tool ecosystem. I would still check the exact capabilities those hosts support. Sharing a protocol does not guarantee identical user experiences.

The ownership questions matter as much as the first demo. Who maintains the adapter when an API changes? Who notices a tool that has started returning partial results? Can the team distinguish a connection failure from a rejected business request?

For a small team, one well-owned read operation is a reasonable first trial. Adding every possible tool on day one makes it harder to learn where the connection actually helps.

Try the boundary on paper

Choose one operation your team understands. Sketch the host, server adapter and existing service. Then walk through a normal request, an expired login, an order from another account and a refund that is no longer eligible.

At each step, write who rejects the request and what the person sees. This costs no service credits and often reveals a missing decision before anyone writes an adapter.

When it is implemented, test those cases through the full path. For an action such as a refund, also check what happens if the connection drops after the service accepts it. The interface needs a way to recover the actual status before trying again.

That is the part of MCP I want to keep clear in my own designs: a useful shared connection, with explicit responsibilities on both sides. Once those are drawn, choosing the integration becomes a much smaller decision.

References

• MCP: Architecture overview
• MCP: Tools specification
• MCP: Security best practices