Mastery checklist and next steps

A newly connected project server advertises search_projects, create_task, and delete_project. The host immediately passes all three definitions to the model because discovery succeeded. What is wrong?

Answer: Discovery reports what the server offers. It does not express host policy, current user intent, or authorization. The host should filter capabilities before model exposure. It may allow search, conditionally allow task creation with validated arguments and confirmation, and block deletion entirely.

The server must also enforce its own authorization. Host filtering protects the application experience and limits model reach; server-side checks protect the service if the host is mistaken or compromised. Neither layer should assume the other is sufficient.

A useful follow-up is to ask what happens when the server later advertises another tool. Safe default behavior is to keep it unavailable until policy explicitly classifies it.

An IDE launches a local repository server and connects to a remote issue server. The team says there is one MCP client because the user sees one chat. Is that a useful architecture model?

Answer: No. The host is the IDE, and it conceptually manages a separate client connection for each server. The local repository connection and remote issue connection have distinct lifecycle, transport, credentials, permissions, data, and failure.

The local server is not automatically trusted. Its executable and dependencies run with some operating-system permissions. The remote server needs verified network identity and approved authentication. The host decides which repository text or issue data can enter model context.

Draw the connections separately even if an SDK presents one convenient manager. Clear boundaries make it possible to disconnect one server, scope logs, and diagnose which component failed.

A server offers a known handbook page, a parameterized handbook search, and a reusable “prepare onboarding questions” interaction. Which primitives fit?

Answer: The known page fits a resource because it is addressable context. Search fits a tool because it performs an operation with arguments. The onboarding interaction fits a prompt because it is a reusable template or workflow starting point.

These choices communicate intent but do not establish risk. The handbook resource still needs access control. A search tool still needs argument and output limits. A server prompt remains untrusted input to the host; it cannot override system policy or invoke operations without the host's control.

If client support or domain needs justify another representation, document the tradeoff. The goal is not ritual classification. It is an honest, governable capability surface.

A tool creates an external support ticket. After confirmation, the client times out and receives no result. The application retries immediately. What could go wrong?

Answer: The first request may have succeeded. A blind retry can create a duplicate ticket. The operation needs an idempotency key, a provider-supported request identifier, or a reconciliation query that determines whether the original action completed.

The interface should report an unknown outcome rather than definite failure or success. Logs should preserve correlation across proposal, user approval, server request, downstream request, timeout, and reconciliation.

Cancellation has the same nuance. Canceling local waiting does not prove the downstream ticket creation stopped. Operational language must match confirmed state.

A team says, “The server uses MCP over an encrypted remote transport, so document access is secure.” Give at least four missing questions.

Answer: Ask:

• How is the server authenticated?
• Which user or service identity is presented?
• How is that identity authorized for each document?
• Which scopes and credentials does the server hold?
• What context does the host send?
• Which capabilities can the model see?
• When is user consent required?
• How are results treated as untrusted content?
• What is logged, cached, and retained?
• How can the capability be disabled during an incident?

Encryption can protect messages in transit. It does not decide whether a request is permitted, whether the endpoint code is trustworthy, or whether retrieved content should influence the model.

Use this checklist before implementation and again before launch.

Purpose and boundaries

• The user promise is written in one sentence.
• MCP is chosen for a concrete interoperability or reuse benefit.
• A direct API alternative was considered.
• Host, client connection, server, downstream service, and model boundaries are drawn.
• Data crossing each boundary is classified.

Capability design

• Every tool has one narrow, honest purpose.
• Tools, resources, and prompts are chosen by semantics rather than convenience alone.
• Read and write capabilities are distinct.
• Input schemas constrain model-produced arguments.
• Outputs have size, content, and provenance expectations.
• New discovered capabilities default to unavailable until policy classifies them.

Identity and control

• Authentication comes from trusted connection context, not model text.
• Server and downstream authorization are enforced for every operation.
• Credentials are least-privilege, protected, and rotatable.
• The host filters what the model can see.
• Consent shows the actual side effect and target.
• Organization policy can deny an action even when a user confirms it.

Lifecycle and compatibility

• Initialization failure has a clear user and operator outcome.
• Supported protocol, SDK, server, and transport combinations are tested.
• Capability metadata cache and change behavior are defined.
• Disconnection and shutdown release resources safely.
• Server and dependency updates have ownership and change control.

Failure and operations

• Errors distinguish validation, authorization, availability, domain rejection, and unknown outcome.
• Every write has a retry, idempotency, and reconciliation policy.
• Correlation links intent, approval, request, and downstream result.
• Logs redact secrets and minimize sensitive content.
• Limits cover concurrency, duration, arguments, and results.
• Operators can disable a server or capability quickly.
• Failure exercises include expired auth, malicious content, version change, and lost responses.

The next lesson, MCP in code, turns this map into an actual connection: configure a server, initialize a client, list capabilities, invoke a bounded tool, and log the result. Carry the checklist with you. Code that merely reaches a successful tool result proves connectivity, not production readiness.

During implementation, prefer a current maintained SDK for your language and consult the current protocol documentation for exact message and transport behavior. The conceptual JSON in this topic showed capability intent; it was not a substitute for SDK types or the specification.

Start with a read-only server and one narrow operation. Print or inspect discovered capability metadata, then add a host allowlist before any model can select a tool. Validate arguments, cap results, preserve source identity, and simulate a timeout. Only after that path is understandable should you add authentication complexity or writes.

The durable architecture remains the same even as libraries evolve: the host owns user experience, consent, context, and application policy; the client manages a server connection; the server exposes and enforces bounded capabilities; the downstream system remains the final authority over its data and actions.