Summary
Propose adding a new example server, examples/servers/admission-gate, demonstrating a real approve/deny use of ServerMiddleware — the SDK has this real, documented pre-execution veto point (runner.py's own comment calls it a "middleware veto") but no existing example actually denies anything. The one middleware example (stories/middleware) is audit-logging only; the SDK's only human-in-the-loop pattern (stories/refund_desk) uses elicitation for mid-call parameter confirmation, a different mechanism from a pre-call approve/deny gate on the whole tool call.
What it is
A filesystem server (read_file/write_file/delete_file) whose write_file/delete_file calls go through a middleware that queries an admission model with a written policy and the proposed action, and raises MCPError (the same mechanism handler errors already use) instead of calling call_next when the model says the policy requires denial.
The model backend is real tulip-agents code (tulip.models.native.openai.OpenAIModel, whose base_url override is documented for vLLM endpoints) — a dependency of this one example only, declared in its own pyproject.toml, not the rest of the workspace. Demoed against Clusiana, a real (unreleased) checkpoint trained for this exact three-way decision; any tulip-compatible chat model works the same way.
Verified
Real MCP client, real stdio transport, the server run as its own installed console script, the gate backed by a live model over a real network call — 4/4 correct on a representative probe, with the denied writes/deletes independently confirmed to have genuinely not touched the filesystem (not the tool's own claimed result). Full methodology: gist.
Scope
Doesn't touch src/mcp at all — new example directory only, own pyproject.toml, matches the existing examples/servers/* pattern (each with independent dependencies, e.g. simple-auth adds pydantic-settings).
Have a working, tested implementation ready — opening this first per CONTRIBUTING.md before submitting the PR.
Summary
Propose adding a new example server,
examples/servers/admission-gate, demonstrating a real approve/deny use ofServerMiddleware— the SDK has this real, documented pre-execution veto point (runner.py's own comment calls it a "middleware veto") but no existing example actually denies anything. The one middleware example (stories/middleware) is audit-logging only; the SDK's only human-in-the-loop pattern (stories/refund_desk) uses elicitation for mid-call parameter confirmation, a different mechanism from a pre-call approve/deny gate on the whole tool call.What it is
A filesystem server (
read_file/write_file/delete_file) whosewrite_file/delete_filecalls go through a middleware that queries an admission model with a written policy and the proposed action, and raisesMCPError(the same mechanism handler errors already use) instead of callingcall_nextwhen the model says the policy requires denial.The model backend is real tulip-agents code (
tulip.models.native.openai.OpenAIModel, whosebase_urloverride is documented for vLLM endpoints) — a dependency of this one example only, declared in its ownpyproject.toml, not the rest of the workspace. Demoed against Clusiana, a real (unreleased) checkpoint trained for this exact three-way decision; any tulip-compatible chat model works the same way.Verified
Real MCP client, real stdio transport, the server run as its own installed console script, the gate backed by a live model over a real network call — 4/4 correct on a representative probe, with the denied writes/deletes independently confirmed to have genuinely not touched the filesystem (not the tool's own claimed result). Full methodology: gist.
Scope
Doesn't touch
src/mcpat all — new example directory only, ownpyproject.toml, matches the existingexamples/servers/*pattern (each with independent dependencies, e.g.simple-authaddspydantic-settings).Have a working, tested implementation ready — opening this first per CONTRIBUTING.md before submitting the PR.