The same MCP server works in one developer's client and appears incomplete in another. The second client lists search and read operations but not the export the team needs. Reconnecting changes nothing, and asking the agent to "try harder" produces guessed tool names.

An MCP discussion about tool requirements describes the underlying usability problem: a tool can depend on a capability the client does not provide.

Locate where the tool disappeared#

Four lists are involved:

The server has its configured operations.
The authenticated connection exposes a permitted subset.
The client discovers that subset.
The host chooses which definitions enter a particular model request.

A tool missing from the model's view can still exist at every earlier layer.

Find the list where the tool dropped out.

Record the server address, authenticated principal, client version, negotiated protocol version, and time of discovery. Compare those facts between the working and failing clients. A successful connection to a development server says nothing about a production server with a similar label.

For the versioned protocol used here, MCP initialization negotiates capabilities. Examine that exchange, since clients do not all support the same optional features.

The tools specification also defines paginated listing and change notifications. A client that fetches one page or retains an old catalog presents an incomplete set even when authentication is correct.

An export that fails before it begins#

Take an export tool that asks the client for additional user input before preparing a file. One client supports that interaction and another does not, so the server hides the export from the second client or returns an error when it is invoked.

A capability mismatch should identify the missing feature and the supported recovery path. It should never surface as "no matching tool," which encourages the model to invent alternatives or route the task through an unrelated connector.

In another environment, the export is on the second catalog page and the discovery iterator has to finish. In a third, the principal lacks export permission, and installing a newer client would do nothing.

Observation	Next evidence	Likely owner
Absent from server response	Server configuration and permission decision	Connector administrator
Present on a later page	Complete list traversal	Client adapter maintainer
Present in discovery, absent from request	Host tool-selection policy	Agent runtime maintainer
Listed but requires unavailable feature	Negotiated capabilities and call error	Client integration owner
Appears only after reconnect	Cache and change-notification handling	Client or gateway maintainer

Make the comparison safe#

Use the same low-risk discovery operation under each identity, and never copy one developer's credential to another machine. If permissions differ, record the difference and use a controlled test identity with the intended access.

Compare canonical tool identifiers and skip display titles, and check any namespace transformation when two servers expose the same local tool name. A renamed title is usually harmless, and an operation routed to another server is a real problem.

Refresh discovery through the client's documented path. If the server reports catalog changes but the host never refreshes, fix that behavior and add a test.

Give the user an actionable failure#

An agent should be able to say, "This connection can read the report, but this client cannot perform the required export interaction," or "The export operation is not permitted for this identity."

Do not return a bare empty list for every failure: no matching operation, failed discovery, and denied access are different states.

You can keep your existing agents while testing this connection contract. Deixic's MCP gateway documentation and agent identity guide describe the integration and identity path, and connection setup covers administration. Keep a small compatibility fixture for each client you use: discovery completes, the required capability is negotiated, and the intended operation either succeeds or explains why it cannot.