Imagine a support assistant that needs to read product documentation and prepare a draft response. Before connecting a server, list what information the assistant needs and which actions it may take. This article offers an original integration worksheet using MCP’s documented concepts. It is a design exercise, not a tested server implementation or a configuration recipe.
Start with the protocol’s boundaries
The official MCP architecture documentation describes a host application, clients that connect to servers, and servers that provide context. It distinguishes tools for actions, resources for contextual data, and prompts for reusable interaction templates. MCP concerns context exchange; it does not prescribe how an application manages its model or uses the context. Source: https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture
Build a capability inventory
For the support example, write three rows in a planning document. The documentation search action takes a query and returns matching passages with source identifiers. A product policy resource supplies contextual material. A reply template helps structure a draft. These are proposed responsibilities, not guarantees that an existing server exposes those exact interfaces. Check the actual server’s advertised capabilities and input schemas before designing the client around them.
Separate discovery from permission
Finding an available action answers “what interface exists?” Your application still needs to decide whether the current user may use it on the requested record. In this proposed integration, search is limited to documentation the user can access, and drafting a reply does not send it. If sending is added later, define a distinct action with its own authorization checks. Do not assume a descriptive tool name or an instruction in a prompt enforces access control.
Design evidence into responses
Require retrieved passages to carry stable source identifiers and enough context for a reviewer to locate the original. Keep the quoted passage separate from the system’s interpretation. If the policy cannot be found, the assistant should mark the relevant statement as unresolved rather than inventing a policy. This is a recommended application contract: the protocol connection alone does not establish the truth of retrieved content.
Choose the connection deliberately
The architecture page describes local stdio and remote Streamable HTTP transports. Treat locality as a deployment choice to investigate, not as a security verdict. For your chosen host and server, document where the process runs, how credentials reach it, which data crosses the connection, and who can revoke access. Follow the specific implementation’s documentation rather than copying a command intended for another host. No installation command is needed for this planning stage.
Walk through four cases
Use a permitted question, a question about an inaccessible document, a missing policy, and a document containing instructions to send a message. For each case, record the expected data access, allowed actions, and visible result. The last case should leave message sending unavailable in our read-and-draft design. Verify this through application behavior and server authorization tests; a successful connection is only one check.
Define completion before expanding scope
For this example, integration is ready for a limited pilot when a reviewer can trace a draft to accessible evidence, denied requests stay denied, and failures produce an actionable explanation. Measure those conditions using test accounts and non-sensitive fixtures. Add external writes only after defining their authorization and review requirements. The worksheet is original editorial guidance; the official architecture page is the source for MCP terminology and transport concepts.
Worked example: a support-draft capability inventory
For a fictional documentation assistant, start with a table written in ordinary language. The first capability is reading an approved support policy. Its inputs are a policy identifier and the authenticated user's context; its result is the permitted policy text or a clear denial. The second capability is preparing a response draft from selected evidence. Neither capability includes sending the response.
Assign each capability an owner, an authorization rule, and an expected failure result. A resource being listed should not be treated as proof that every user may read it. A tool being discoverable should not be treated as permission to perform its action. Application services still need to check the actual request under the relevant identity.
Record which information the host can expose to the model and which information must remain outside model context. For example, a draft may need a policy excerpt but not a support administrator's credentials. Keep secrets in deployment configuration, and document how revocation changes subsequent requests. Do not place credentials inside example prompts or reusable configuration snippets.
Write authorization cases before connection tests
Create two fictional users with different document access. Give both the same question and record the expected difference in accessible evidence. Add a direct request for a restricted document identifier. A denial should remain a denial even if the question is phrased as an urgent troubleshooting task.
Next, test a permitted document containing an instruction to ignore previous rules and send its contents elsewhere. Treat that text as document data. The read-and-draft assistant should still have only its original capabilities. This is an application acceptance test; the presence of MCP alone does not prove that a host or server handles such input safely.
Include missing and expired credentials, an unavailable server, and an unsupported request. Specify the user-visible result for each case. An error should identify what the operator can investigate without echoing tokens or restricted document content. A connection check that only asks whether initialization succeeded cannot establish these properties.
Design evidence and error records
A useful draft record includes the question, accessible evidence identifiers, the resulting draft, and unresolved points. Store only what your retention policy permits. For sensitive workflows, an identifier and a restricted evidence store may be more appropriate than placing full document text in a general-purpose log.
Give each attempt a run identifier. When an operation fails, associate the failure with the capability and stage that failed. If reading a resource succeeded but a later service timed out, preserve that distinction. Otherwise an operator may repeat a successful operation unnecessarily or misinterpret a partial result as a complete answer.
If you later add a write tool, define a separate review contract. Describe exactly which destination may change, what confirmation is required, and how a duplicate request is recognized. Repeating an operation after a timeout can be dangerous when the remote side completed it but the response was lost. Design retries around the semantics of the action rather than around a generic desire to try again.
Plan a limited rollout
Start with non-sensitive fixtures and accounts whose permissions are easy to inspect. Compare observed behavior with the acceptance worksheet, then record the chosen host, server version, deployment location, and configuration assumptions. A future upgrade should trigger a review of those assumptions, especially where a host exposes new capabilities.
Keep a manual fallback for the pilot. A reviewer should be able to open an authorized document and prepare a response without the assistant. That fallback makes it easier to distinguish an integration outage from a missing business process. It also gives the team a baseline for assessing whether the integration saves useful effort.
Before adding more tools, revisit the workflow design guide. Use the evaluation worksheet to record expected outcomes and errors. A small integration with clear permissions and inspectable evidence is a better foundation for expansion than a large capability list whose behavior nobody has tested.
Sources
- MCP architecture overview, for protocol participants, primitives and transports. The support-draft worksheet and proposed acceptance cases are original engineering guidance.