Client side tool validation to defend against tool poisoning

[alorispax8]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Context

The folks at Invariant Labs posted about tool poisoning, I would like to open up a discussion to move towards a solution for situations where the MCP server is hosted remotely.

Proposal

It seems like the root cause of the problem is that clients don't keep track of server side tools locally. It might make sense to implement client side baselining and drift detection for tool descriptions exposed by the server. Possibly as follows:

Client registers with server

a) The client receives a copy of the complete tool description of all the tools in scope
b) The human reviews and approves the descriptions of the current tool set. If the descriptions contain instructions that might be hidden to the UI, then either the human is notified/warned by the client
c) The human is given the option to reject any tool from being used
d) All accepted tool names and descriptions (maybe a signed hash of them) are stored client side

When the human asks the agent to perform some action

a) An MCP server is selected but no tools can be used until descriptions have been checked for drift
b) MCP server gets polled for the description of all the approved tools
c) All descriptions are checked against the values stored locally
d) Only tools that have not changed their descriptions can be used, tools that have drifted are blocked
e) Tools that have drifted are submitted for re-approval by the human
f) LLM and MCP client can now interact with MCP server

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[Gelembjuk]

I think this is not part of the protocol specification.
It is just common sense of software usage.
It is possible to verify any MCP server before to use it.

• use MCP inspector
• if it is STDIO server then analyse the code

But best would be - use only MCP servers from trusted vendors. It includes both local STDIO and remote SSE.

Example, if you want to integrate Slack with your LLM then use MCP server officially created and maintained by Slack, not someone else.

If you use MCP server created by noname then it is your responsibility

[jonathanhefner]

I agree that this seems to be outside the scope of the protocol, but there are probably some best practices that MCP clients could implement to better protect users, and it could be helpful if the MCP documentation mentioned those.

[alorispax8]

My train of thought was around how OIDC mandates that clients verify the validity of various claims in the standard.

For example: https://openid.net/specs/openid-connect-core-1_0.html#IDToken

nonce
String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. If present in the ID Token, Clients MUST verify that the nonce Claim Value is equal to the value of the nonce parameter sent in the Authentication Request. If present in the Authentication Request, Authorization Servers MUST include a nonce Claim in the ID Token with the Claim Value being the nonce value sent in the Authentication Request. Authorization Servers SHOULD perform no other processing on nonce values used. The nonce value is a case-sensitive string.