Privacy.

The site does not run third-party advertising trackers. Standard server logs (IP, user agent, request path, timestamp) are retained for 30 days for operational and security purposes only. Logs are not sold or shared.

The contact and update-notification forms store your email and submission timestamp. They are used to reply about mcpindex (project updates, answers to your message) and nothing else. Your email is never sold, shared, or used to sell you anything, because there is nothing on sale. Unsubscribe at any time by emailing hello@mcpindex.ai.

API requests to /api/v1/* are not logged beyond aggregate rate-limit counters. We do not log query strings. We do not persist task descriptions sent to the recommend endpoint.

One scoped exception: the tool screener (/api/v1/screen). The description you paste is screened in-flight and is not storedunless you explicitly check “Contribute this example to improve detection.” If you check it, we store only that description and its verdict - no IP address, no other identifiers - to improve detection. Leave it unchecked and nothing is retained.

Drift telemetry (the @mcp-index/sdk / mcpindex-gate clients): off by default. The SDK sends nothing unless you set MCPINDEX_DRIFT_TELEMETRY to one of the three on settings below - and note that all three, including lookup, send at least a keyed fingerprint. When set to detection, a tool-pin or a contract drift sends one one-way signal to /api/v1/drift: keyed (HMAC) fingerprints of the server/tool id, the contract hashes, the change type, a safety flag, an hour-rounded time, and the client SDK tag (py or ts) - plus a random install id that links one machine’s signals so we can count distinct installs (it is a random token, not derived from you, and is never joined to your IP). Under the same flag, the gate also makes a read-only query to /api/v1/drift/anyto ask whether a tool’s contract already drifted, so it can warn you on the first call; that query sends only a keyed fingerprint. It never sends tool schemas, arguments, descriptions, or URLs. A fingerprint is still not anonymity: the key is a constant in the open client and the registry is public, so anyone can recompute the fingerprint of a registry name and match it. It keeps the name out of the payload; it does not hide which public server it refers to. There are three on settings, each a superset of the one before: lookup is read-only - it makes the /api/v1/drift/any query above and reports none of your own catches back; detection adds the one-way signal; contribute is reserved for a future richer tier and behaves identically to detection today.

Where that setting lives, for the mcpindex-gate clients: the proxy reads it from its own environment, which your MCP host sets from the wired entry in your config file - so unsetting the variable in a shell does not change what a wired server runs with. Turn it off with mcpindex-config-wire wire --repin --drift-telemetry off, which clears the setting from every wired entry. The --repin is required: without it, wiring skips servers it has already wired, so on an already-configured machine the command reports success and changes nothing. We would rather document the flag than let you believe you had opted out when you had not.

From gate v0.13.0, your choice is also recorded locally in ~/.mcpindex/consent.json and re-applied whenever the gate re-wires, so a routine re-wire stops silently clearing a setting you chose. That file holds the mode, a label for how it was set, and when - plus, when the setting was carried over from an existing wired config, a reference to the config it came from (in 0.13.1 that reference is a file path on your machine). No server or tool names, and it is never sent anywhere: it is read only by the wiring command and by status. It is stated plainly as what it is: not a security boundary. Anything running as your user can edit it, exactly as it can edit your host config. What it buys is that your setting survives an upgrade, and that a wired entry disagreeing with it is reported to you rather than silently obeyed.

Project config scanning (the mcpindex-config-wire command): on by default, and it sends nothing. To count the MCP servers you actually run, the gate reads project-level config files - a repo’s own .mcp.json, .cursor/mcp.json, .vscode/mcp.json, .gemini/settings.json, .zed/settings.json. It finds those repos from the project list Claude Code already keeps in ~/.claude.json. Stated plainly, because it is the part worth knowing: this widens what the tool reads on your disk from about ten fixed paths in your home directory to every repository you have opened in Claude Code. It is a local, read-only scan. No file content, no path, and no server name leaves your machine - there is no request associated with this feature at all. Project configs are detected and counted, never wired: they are version-controlled and shared, so wiring one would commit a change that breaks every teammate who has not installed the gate. Turn it off with --no-project-scan or MCPINDEX_PROJECT_SCAN=off; with it off, the reported server count is a floor and the tool says so.

Call receipts (the mcpindex-gate Python SDK wrap() path): on by default. The mcpindex-config-wire install wires a stdio proxy, and the proxy posts no receipts today, so that path sends nothing. After each tool call gated through wrap(), the gate emits a compact, credential-blind receipt. Here is the complete list of what a receipt contains: a random receipt id; the tool contract hash (a sha256 of the tool’s public contract); the gate verdict; a closed-vocabulary action classification (read / write / execute class, resource kind, reversibility); a closed-vocabulary run context (autonomy level, task-intent class, a human-in-the-loop flag, framework name); a closed-vocabulary outcome (status, side-effect class, a reverted flag, a coarse latency bucket); a yes/no/unclear “justified” flag; and a timestamp rounded to the hour. Every field is an enum from a fixed list, a hash, or a boolean - by construction there is no field that can hold free text, so a receipt never contains tool arguments, results, prompts, server names, or URLs. The ingest schema is strict and rejects anything else.

What the hash lets us do, stated plainly: receipts include the tool contract hash, which we can match to servers in our public index. That tells us which indexed tools an install gates - never what you did with them, and nothing for tools we have not indexed. Receipts are linked by a random per-install token (install_id) generated on first run and stored locally. It is pseudonymous, not anonymous: it is a random token not derived from you or your machine and is never joined to your IP, but it does link one install’s receipts together over time. Keyless installs have no account link; if you sign in and configure an api_key, receipts from that install are associated with your key. Set MCPINDEX_RECEIPT_INGEST_ENABLED=0 to suppress receipt egress entirely; your per-install call log is visible (to anyone holding the token) at mcpindex.ai/receipts?id=<install-id>.

First-run disclosure: from gate v0.9.0, the first run on a machine prints a one-line notice of exactly this behavior to stderr and sends nothingthat session - emission starts on run 2, so no receipt is sent before the disclosure and the opt-out were visible. Earlier gate versions emit without the runtime notice, per the packaging README. The gate’s other local lines (the ambient “noted” lines and the weekly summary line) are rendered from local state and send nothing anywhere.

Cookies and similar storage: the site itself does not set first-party advertising cookies. Hosting on Vercel may set a platform routing cookie. We also load Vercel Analytics and Vercel Speed Insights, which may use cookies or local storage for aggregated, privacy-oriented traffic and performance metrics (no advertising profile). See Vercel Analytics privacy. This is our cookie notice for launch; we do not run a separate consent banner because we do not use advertising trackers.

GDPR / CCPA: email hello@mcpindex.ai to request deletion of any personal data tied to you.