What is the feature or problem you’d like to solve?
There is no hook to intercept tool calls before handler execution. Cross-cutting concerns — authorization, audit logging, argument validation — must be hardcoded into individual tool handlers or require forking the server.
Why do you need this feature?
Teams deploying these servers in multi-tenant or regulated environments need to enforce per-tool authorization policies and log invocations for compliance without modifying handler code. The existing DENIED_COMMANDS mechanism shows the need already exists — a middleware hook generalizes it across all servers in the repo and makes it extensible without touching server internals.
Cloud Audit Logs and IAM operate at the GCP API layer — they record what executed and whether the caller had permission. A middleware hook operates at the MCP tool call boundary, one layer earlier, where per-agent context is available that IAM cannot see: which agent made the request, what task it was assigned, what delegation chain authorized it. Two agents sharing the same service account are indistinguishable to IAM but distinguishable to middleware.
Without this, every team reimplements the same interception logic in their own fork with no interoperability between implementations.
Example prompts, workflows, or additional information
A middleware interface registered at server startup:
interface ToolMiddleware {
beforeToolCall(
toolName: string,
arguments: Record<string, unknown>,
meta: Record<string, unknown> | undefined,
): Promise<Record<string, unknown>> // return modified args or throw to deny
}server.use(myAuthMiddleware, myAuditMiddleware)
Middleware runs in registration order. Throwing short-circuits the chain and returns an MCP error response without invoking the handler. meta exposes params._meta so middleware can read authorization context passed by the client.
The GitHub MCP server merged equivalent support in github/github-mcp-server#2026. Happy to submit a draft PR.
What is the feature or problem you’d like to solve?
There is no hook to intercept tool calls before handler execution. Cross-cutting concerns — authorization, audit logging, argument validation — must be hardcoded into individual tool handlers or require forking the server.
Why do you need this feature?
Teams deploying these servers in multi-tenant or regulated environments need to enforce per-tool authorization policies and log invocations for compliance without modifying handler code. The existing
DENIED_COMMANDSmechanism shows the need already exists — a middleware hook generalizes it across all servers in the repo and makes it extensible without touching server internals.Cloud Audit Logs and IAM operate at the GCP API layer — they record what executed and whether the caller had permission. A middleware hook operates at the MCP tool call boundary, one layer earlier, where per-agent context is available that IAM cannot see: which agent made the request, what task it was assigned, what delegation chain authorized it. Two agents sharing the same service account are indistinguishable to IAM but distinguishable to middleware.
Without this, every team reimplements the same interception logic in their own fork with no interoperability between implementations.
Example prompts, workflows, or additional information
A middleware interface registered at server startup:
server.use(myAuthMiddleware, myAuditMiddleware)
Middleware runs in registration order. Throwing short-circuits the chain and returns an MCP error response without invoking the handler.
metaexposesparams._metaso middleware can read authorization context passed by the client.The GitHub MCP server merged equivalent support in github/github-mcp-server#2026. Happy to submit a draft PR.