Class McpToolCategoryHeader
- Namespace
- MailFathom.Mcp.Tools.Categories
- Assembly
- MailFathom.Mcp.dll
The request header a client narrows its own view of this surface with.
public static class McpToolCategoryHeader- Inheritance
-
McpToolCategoryHeader
- Inherited Members
Remarks
It takes away and never grants. What the deployment published is the authority; this says which part of it a particular client wants to see, so one endpoint can serve an agent that only reads beside one that does everything, and a client that needs a fraction of the surface need not carry the rest in its model's context. A category the configuration excluded is never published because a header asked for it, and no value here enables a capability, widens a grant, or reveals that a withheld tool exists.
It is therefore not an authorization mechanism and nothing may be built on it as one. The value is written by the caller, so it is untrusted input in the ordinary sense: it is read, bounded, and mostly ignored. A value naming no published category is dropped rather than refused, because a client sending one has asked for nothing this endpoint can act on and failing its request would turn a narrowing convenience into an outage.
The name is MailFathom's own and collides with nothing on the path a request takes. The Streamable HTTP transport
reads Mcp-Session-Id, MCP-Protocol-Version, and Last-Event-ID; the authentication methods read
Authorization; a reverse proxy writes the X-Forwarded-* family. None of those is this, and the product
prefix keeps a future one from becoming this. It carries no X- prefix, which RFC 6648 deprecates for exactly
the reason a header outliving its experiment then cannot be renamed. A browser client reaches it because the
endpoint's CORS policy names it among the request headers it permits.
Fields
- Name
The header a client writes the categories it wants in.