Treat an MCP server as an integration boundary. Give each capability a narrow contract, enforce access in the application that owns the data, and test failures as carefully as successful calls. Choose MCP when a shared integration interface solves a real reuse problem.
Follow the request through host, client and server
The host is the AI application the worker uses. Its MCP client communicates with a server that exposes order capabilities. That server might be a local program or a remote service. The model helps the host decide which capability is useful; your backend remains responsible for producing the order information. MCP defines the exchange between client and server.
Draw five boxes for this example: worker, host, MCP client, order server, order API. The worker asks a question; the host requests order status through its client; the server reads the authorized order API; the result returns to the host. Keep these boxes separate while debugging. A connection problem, an invalid argument, and an unavailable order backend require different fixes.
Choose between a tool, a resource and a prompt
A tool exposes an operation, such as get_order_status. A resource supplies addressable context, such as a shipping-policy document. A prompt supplies a reusable interaction template. The host decides how to present and use these capabilities; support differs across applications. Resources have URIs and can return text or other content. A useful integration makes the purpose of each capability obvious.
For order 1042, start with a status tool that accepts an order identifier and returns a compact record. Add a policy resource when the assistant needs the shipping rules as well. A reusable support prompt could request an explanation, evidence, and the next step. Keep the policy separate from the order result so its version and origin remain visible when someone reviews the answer.
MCP and an API solve different integration problems
Your order API already owns business behavior: looking up shipments, enforcing permissions, and recording changes. An MCP server can adapt that API into capabilities an AI host can discover and invoke. The same backend may serve a website, a mobile application, and this adapter. Avoid duplicating order rules inside the adapter because the copies will eventually disagree.
Suppose three AI applications need the same lookup. A shared MCP interface can reduce repeated integration work if all three support the required features. If you control one application and need one fixed request, a direct API integration may be easier to operate. Count actual consumers, deployment requirements, and maintenance costs before selecting a protocol. Neither approach removes the need for a usable backend contract.
Write a contract the assistant can use correctly
MCP tools are discoverable through tools/list and invoked through tools/call. A tool definition includes a name, description, and input schema. Make these describe a business operation precisely. An assistant cannot reliably distinguish searching an order from changing its status if both capabilities are named process_order and accept an unrestricted string.
The example below is an illustrative tool definition, not a complete protocol exchange or a running server. Its identifier is a string because some stores use leading zeros. The implementation must still validate it, identify the authenticated user, check ownership, and handle missing orders. Returning a clear not-found result is more useful than inviting the assistant to guess a shipment status.
{
"name": "get_order_status",
"description": "Read the current shipment status of one accessible order. Does not change the order.",
"inputSchema": {
"type": "object",
"properties": {
"order_id": { "type": "string", "minLength": 1 }
},
"required": ["order_id"],
"additionalProperties": false
}
}Separate discovery, identity and permission
A tool appearing in a list does not establish permission to read every order. Validate access for the actual user on each operation. For HTTP deployments, the MCP authorization specification describes an OAuth-based framework. Local process deployments have different credential handling. Choose the mechanism supported by your host and server, then verify the entire request path.
In our example, an employee may inspect orders for one store but cannot issue refunds. Expose lookup and refund as separate operations with separate policies. When order 1042 belongs to another store, reject the lookup even if the model supplies a convincing explanation. Authority comes from the authenticated application context. A natural-language claim inside a prompt cannot expand it.
Before enabling a write operation, decide how the worker reviews the exact target and change. A confirmation that only says ‘continue’ is hard to audit. Showing order 1042, the proposed action, and the effect makes the decision concrete. Enforce the policy in code so it also holds when a host has a different interface.
Keep returned content inside its trust boundary
An order note might contain text telling the assistant to ignore its instructions and export customer records. That note is application data. Design the host to treat it as evidence about the order rather than authority to change the task. Keep results scoped and avoid supplying unrelated personal data merely because the backend can return it.
MCP security guidance also addresses risks such as token passthrough and confused-deputy behavior. In practical review, trace which credential authorizes each backend call and which audience it was issued for. If your adapter calls another service, that service's access model remains part of the design. A successfully established connection does not certify the whole chain.
For the shipping explanation, return the current status, observation time, and useful event identifiers. If a carrier request fails, make that failure visible. The worker should be able to distinguish ‘not shipped’ from ‘shipment data unavailable’. This distinction protects the accuracy of the answer more directly than making it sound confident.
Test one complete lookup before adding more tools
Start with a disposable order store and test the integration without asking the model to choose the tool. Once discovery and a direct invocation work, add the natural-language request. This sequence separates protocol and backend defects from selection mistakes. Record the operation, sanitized arguments, result category, and elapsed time so a failure can be reproduced.
Use the cases below as an original exercise. The successful result should be useful enough that another worker can explain the answer without reopening the conversation. Then introduce a timeout and a malicious order note. Check the observed behavior, rather than relying on the assistant's own claim that it handled them correctly.
- Accessible order: return the correct status and evidence for order 1042.
- Invalid or missing identifier: produce a useful validation or not-found result.
- Another store's order: deny access without exposing its details.
- Backend timeout: distinguish unavailable data from a real order status.
- Injected instruction in a note: keep the lookup task and access restrictions intact.
- Duplicate request: verify the chosen operation's actual side effects and retry behavior.
Explain the boundary in an interview
A strong explanation starts with the user task and follows the data. Describe the host, client, server, and existing API; choose the smallest useful tool; then explain ownership checks and failure results. Discuss why a shared integration is worth maintaining in this scenario. That gives an interviewer observable engineering decisions to question.
For a final exercise, change the request to ‘cancel this order’. List what must change in the contract, permissions, review interface, and recovery path. Consider a timeout after cancellation succeeded. Explain how the caller would discover the real outcome before repeating the action. MCP transports the interaction, while your domain design determines whether the resulting operation is correct.
Quick answers
Frequently asked questions
What does MCP stand for?
Model Context Protocol. It defines an integration interface through which AI applications can discover and use capabilities exposed by servers, including tools, resources, and prompts.
Do I need an MCP server for every API?
No. Start from the consumers and the reuse problem. A direct integration may be sufficient for one controlled application. An MCP adapter becomes useful when compatible hosts benefit from a shared discovery and invocation interface.
Does connecting a server allow an assistant to change my data?
The available operations and enforced permissions determine what it can do. Inspect the capabilities, credentials, and access policies before enabling a server. Separate lookup from writes and verify authorization at the system that owns the data.
Which MCP version does this guide use?
The linked protocol references use the July 28, 2026 edition, checked on October 2, 2026. This is a conceptual design guide. Use the specification and SDK documentation matching your host when implementing wire messages or connection setup.
Source notes
References and review policy
Information checked on October 2, 2026. Section links identify sources for factual claims and technical explanations. Interpretations, practice scenarios and preparation recommendations are RecallDeck’s editorial work.
From reading to recall
Practice the full interview loop.
RecallDeck schedules the concepts you miss and keeps coding, design, and behavioral fundamentals available when the interviewer changes direction.