Context7

The server holds no broad credential of its own: each request carries the user's own Context7 API key (or OAuth token), and the server only ever uses it for two read-only lookups against the Context7 API, so one user's request cannot act as another user. But the server does not validate most tokens itself: on the default /mcp endpoint any key or token is forwarded unchecked to the backend, and token validation on the protected endpoint is not a strict boundary. Forwarding the client's token downstream is the MCP 'token passthrough' pattern, which caps this criterion.

The server exposes exactly two tools, both pure lookups against the Context7 documentation API, and both carry accurate read-only, non-destructive annotations. Neither tool can change state anywhere: the only upstream calls are two HTTP GETs to a fixed host. There is nothing consequential for a host to approve, and the tool set is hard-coded with no way to add tools at runtime.

The tools are narrow by design: instead of a generic HTTP fetch, each builds a request to one fixed Context7 endpoint, with the model's arguments placed into encoded query parameters, so the model cannot choose the host or the path. Arguments are only typed as strings, though: there is no length limit and no format check on the library ID, and the server does not cap how much documentation it returns.

The server never interprets model text as code: there is no shell, subprocess, eval, or dynamic code loading anywhere in the MCP package. Arguments only become URL query parameters on a lookup request.

The server's job is to put third-party, community-contributed documentation into the model's context, and it does so as plain text with no provenance marker or untrusted flag that the host could act on. Its own tool descriptions and server instructions also contain directives to the model ('You MUST call this function', 'Use even when you think you know the answer'), so content and instructions are mixed. The server itself cannot take actions, which limits what a hijack can do through it, but every query the model writes is sent to Context7 and there is no no-egress mode.

The MCP server is stateless: it keeps no memory, writes no files, and loads no workspace instruction or config files. Only operator-scope environment variables configure it. (The Context7 documentation index is a shared, community-written store, but it lives in the private backend and is reached here only as untrusted input, scored under C5.)

The server loads no third-party code at runtime: no plugins, no MCP sub-servers, no package installs. Its only dynamic imports load its own telemetry modules.

API keys arrive per request (HTTP) or from an environment variable or command-line flag (stdio) and are kept in memory only. They are never echoed back into tool results, and the telemetry records only tool names and outcomes, never arguments or headers. There is, however, no redaction layer: secrets stay out of logs only because no code path happens to log them, not every error path keeps secrets out of its output, and the keys themselves are long-lived.

In the shipped configuration the server keeps no per-call record of what it was asked: only errors are printed to stderr, and aggregate metrics count calls by tool and outcome. OpenTelemetry spans exist but go nowhere unless the operator installs an exporter, and even then they hold the tool name and outcome, not the arguments or who asked.

Each upstream lookup has a hard 60-second timeout, OAuth metadata fetches have 10 seconds, SSE keep-alives and notification subscriptions are disabled, and shutdown is bounded. The server itself has no rate limit, no concurrency cap and no output size limit (quotas are enforced by the private backend), and a client's cancellation of a tool call does not abort the in-flight upstream request.