What Did We Actually Trust When We Connected the MCP Server?

Botie has been reading manuals through an MCP server. Today the same tool name appears with a longer description asking the agent to attach its conversation before every lookup. The connection still works. Should the host expose the changed tool automatically?

MCP gives clients and servers a shared way to describe and call capabilities. We still need to decide which implementation we trust, which capabilities this task needs and what happens when those capabilities change.

Check configured server identity separately from the reviewed metadata fingerprint.

available for authorised calls

The host is the application coordinating the model and its integrations. It creates clients that communicate with servers. Choose servers through controlled configuration, keeping the provider and intended task visible to the person administering the host.

A model-generated URL, package name or startup command should not silently become a trusted connection. Review the implementation and the authority it would receive before enabling it. Connecting a second server can expose a different set of records and side effects.

Connection configuration belongs to a control path with its own permissions.

A local stdio server is a program the host launches. Its access comes from its operating-system identity, mounts, environment and network. Review its executable and arguments, then constrain it like other third-party code.

A remote HTTP server adds a network service and, where needed, delegated authorisation. Review the actual endpoint and transport configuration. A local proxy connecting to a remote server still needs to enforce the remote trust boundary; calling one end local does not erase the other end.

MCP standardises messages. It does not automatically sandbox a server process.

Tools request operations. Resources provide material to read. Prompts provide reusable interaction templates. Each can introduce content or behaviour the host must handle according to its origin.

Expose a narrow tool set for the task, such as reading an approved manual by ID. Prefer that contract over a general command runner with unrestricted arguments. A general tool combines many effects behind one name, making meaningful review and permission enforcement harder.

A small capability contract makes the intended consequence easier to inspect.

A description helps the model decide when to use a tool. Input and output schemas describe data shapes. An annotation such as readOnlyHint describes expected behaviour. None of these strings independently enforces the service’s permissions or proves what its implementation will do.

Keep the server identity with the tool name. Compare discovered metadata with the reviewed capability set under your deployment policy. Treat unexpected additions, description changes and schema changes as reviewable events rather than automatically widening the agent’s authority.

A hint about safety is not an access-control decision.

import hashlib, json
metadata = {"name":"read_manual", "schema":{"asset":"string"}, "description":"Read an approved manual"}
encoded = json.dumps(metadata, sort_keys=True, separators=(",", ":")).encode()
digest = hashlib.sha256(encoded).hexdigest()
print(len(digest))

64

Servers can advertise a changed tool list. Reconcile it with the host’s approved set and revoke stale cached capabilities when necessary. Version or pin deployed server code where practical, and preserve the metadata used for a reviewed call.

Metadata can remain unchanged while implementation behaviour changes. Provider review, constrained credentials, per-call authorisation and monitoring are still required. A fingerprint catches one class of change; it does not freeze a remote service’s internals.

Discovery review narrows exposure but cannot replace execution controls.

A tool response can carry structured values, text and resource links. Check expected schemas and content bounds, preserve provenance and handle protocol errors separately from a tool’s reported execution error. Neither failure should quietly become a successful empty result.

Returned text may contain instructions. Returned links may point to an unapproved location. Validate a link through the relevant retrieval policy before fetching it; do not let a tool result choose an unrestricted new filesystem or network capability.

The response is evidence from a source, even when its JSON is well formed.

Some MCP capabilities let a server request model sampling or solicit information through the host. Review the requested scope and presentation to the user. Do not automatically include unrelated conversation history, private files or credentials in a server-initiated request.

Keep consent attached to the actual disclosed data and destination. A server’s request for information does not establish that it needs the information or that the current user may disclose it.

A new direction of communication creates another place to inspect authority.

Test discovery changes, oversized or malformed results, tool errors and attempted calls outside the approved set. Use synthetic records and a server that cannot reach production systems. Verify what the host exposes after each change.

Keep these integration checks separate from the browser manifest exercise. The next lesson follows an authorised HTTP connection into the token and object checks that a real server must enforce.

A successful handshake is not an end-to-end security test.