The problem: a connection name tells you too little

A connection called 'Engineering Reports' might expose a narrow snapshot reader, a database query service, or a command runner with broad machine access. Its friendly name does not answer which data it can read or what it can change. Before using it, inspect its operator, transport, capabilities, individual tool contracts, and authorization scope. Treat this as reviewing a small interface specification before connecting an unfamiliar block.

For the pinned MCP 2025-11-25 lifecycle, client and server first exchange protocol version and capabilities. A server advertising tools says that it supports that feature family. It does not promise every possible report tool, and it does not authorize every call. See the versioned lifecycle definition. A host may offer several server connections, each with a client; seeing one server's tools does not describe the others.

Three different interfaces

The resources specification describes URI-addressed context, while the prompts specification describes reusable message templates. Fetching a prompt returns messages; it does not mean a model has answered them. A resource URI identifies content but is not automatically a browser URL or permission to read arbitrary paths. A server can offer tools without offering either of the other two features.

Worked synthetic connection review

1
2
3
4
5
6
7
8
9
10
11

SYNTHETIC connection review card; not host configuration
operator: training-report-service
server implementation version: 0.1.0
protocol selected for this exercise: 2025-11-25
transport: local stdio
advertised server capabilities: tools only
tool: search_reports
arguments: query (nonempty text), limit (integer 1..3)
data boundary: approved training-r1 snapshot
implementation restriction: no filesystem paths, shell, or URLs accepted
host policy: allow this named tool for this training task only

From this card, the learner should expect tools/list to reveal the tool's argument schema. They should not expect resources/list or prompts/get to work because those capabilities were not advertised. They should also ask how the snapshot restriction is enforced. A claim in a review card is a requirement to verify against implementation and operating policy, not proof that a process is isolated.

Transport and identity are separate questions

The 2025-11-25 transport documentation describes stdio and Streamable HTTP. In this example, local stdio means launching a process, so the launch command and its inherited access need review before connection. For a remote service, inspect the approved endpoint and operator rather than guessing a URL from its display name. Product-specific setup screens are outside this provider-neutral lesson.

Authentication identifies the caller; authorization determines permitted access. The 2025-11-25 authorization specification covers an HTTP authorization flow and treats stdio differently. Use the organization's supported identity flow where required. Do not place secrets in a lesson, prompt, report query, or shared configuration. A connected status alone tells you neither the active identity's project scope nor the destination of returned report text.

Exercise and expected inspection notes

A replacement server advertises tools and resources, exposes search_reports plus run_command, and asks for report-write scope. Your task is still to summarize one approved DV failure excerpt. Write three inspection findings and decide whether the expanded interface is necessary. Include what you would do if the host cannot disable the unrelated command tool.

Limitations

Hosts differ in supported features and permission controls. A schema constrains the shape of arguments, while implementation and service policy control their effects. Neither a reassuring description nor a read-only annotation establishes those effects. Carry that distinction into the next lesson's complete message walkthrough.

Related topics

• Up: MCP and Skills

• Next lesson