You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
docs/examples: add a tool-response detection middleware sample? #2617
Per CONTRIBUTING.md ("PRs are for execution, not exploration"), opening an issue first to gauge appetite before writing code.
Question
Would the maintainers accept an examples/snippets/security/ directory with a single self-contained file that demonstrates how to scan MCP tool responses through a detection-rule callback before they reach the client?
The intended file would:
Be additive only (new file under examples/, no changes to SDK core or existing examples)
Use the MCP Server API only (no SDK-internal hooks)
Depend on one optional third-party package (pip install pyatr) for the rule engine itself; not added to the SDK's own requirements
Pass ruff + the existing example file conventions
Why this might be in scope
Production MCP deployments increasingly need a tool-response scanning hook for prompt-injection / tool-poisoning detection. The example would not advocate for any single detection product. The same pattern works with any callable detector. Showing the wiring once removes a class of "how do I plug security in" questions.
Reference for the rule engine
I maintain ATR (Agent Threat Rules), an MIT-licensed open detection rule format. It is in production at Microsoft Agent Governance Toolkit (PRs #908 and #1277, both merged) and Cisco AI Defense skill-scanner (PRs #79 and #99, both merged), and integrated into MISP/CIRCL via misp-taxonomies #323 and misp-galaxy #1207 (both merged by @adulau).
I like the shape of this as an example, but I would strongly suggest making the snippet dependency-free and using a tiny detector protocol/stub in the file itself.
That keeps the example focused on the SDK wiring rather than on a specific rule engine, and avoids creating an implied endorsement or support surface for an optional package. The snippet can still show where a production detector such as ATR, a custom regex policy, or a hosted scanner would plug in:
Then the example can fail closed on any findings and remain fully runnable with only the SDK's normal example dependencies. That would probably make it easier to accept as a general security wiring pattern under examples/.
Activity
scosemicolon commentedon May 27, 2026
I like the shape of this as an example, but I would strongly suggest making the snippet dependency-free and using a tiny detector protocol/stub in the file itself.
That keeps the example focused on the SDK wiring rather than on a specific rule engine, and avoids creating an implied endorsement or support surface for an optional package. The snippet can still show where a production detector such as ATR, a custom regex policy, or a hosted scanner would plug in:
Then the example can fail closed on any findings and remain fully runnable with only the SDK's normal example dependencies. That would probably make it easier to accept as a general security wiring pattern under
examples/.maxisbey commentedon Aug 10, 2026
Thanks for the report. I'm closing this out as part of a backlog cleanup now that v2 is out. Feel free to reopen if this is still relevant.