How 7Maps checks MCP servers

What is checked

Every remote server in the official MCP registry (latest version of each entry, deleted entries left out), plus servers their owners submitted that passed a week of observation.

7Maps-bot sends what any MCP client sends when it connects, and nothing more:

1. initialize, offering protocol version 2025-06-18.
2. notifications/initialized.
3. tools/list, following nextCursor for a few pages.
4. Daily check only: one server/discover in the stateless 2026-07-28 style, to read the protocol revisions the server supports (see protocol versions).

Once a day per origin it also reads /robots.txt, /.well-known/oauth-protected-resource (does sign-in publish OAuth metadata) and /.well-known/agent-card.json or /.well-known/agent.json. It never calls a tool, never signs in and sends no credentials. User agent: 7Maps-bot/0.2 (+https://7it.co.il/7maps/bot/).

Left out before any request: remotes that are SSE only, templated addresses, anything not https, IP addresses and private names, hosts that opted out, and origins whose robots.txt says Disallow: / to 7Maps-bot or to *.

A redirect to the same registrable domain is followed once. A redirect to another domain is recorded, not followed. For some servers the age of the domain is read from its public RDAP record; that lookup never reaches the server.

From where, and how often

All checks run from one cloud region in the Washington, D.C. area, so times include the distance from there.

Also: servers submitted by their owners are checked every 6 hours for 7 days and join the map when they answer reliably, keep their tools stable and describe every tool; the bar is the same for everyone and cannot be bought. npm and PyPI packages that servers ship as are read once a day from public package metadata, and their current versions are checked against OSV. A day on which a server's daily check did not run is recorded as no data, never as down.

Timeouts

robots.txt

3 seconds (no answer means allowed)

initialize

8 seconds

notifications/initialized

5 seconds

tools/list

8 seconds per page

server/discover

5 seconds (daily check only)

well-known files per origin

4 seconds each

five-minute check

30 seconds overall, on top of the limits above

What counts as answering, sign-in needed, or down

Answered with tools o

initialize returned a result and tools/list returned a result (an empty list included).

Asked for sign-in a

HTTP 401 or 403 before any tool was listed.

Asked for payment p

HTTP 402 on initialize. Where the server asks agents to pay is recorded; a change of that address is reported.

Not answering d

A timeout, no connection, a redirect to another domain, any other HTTP error, a JSON-RPC error on initialize, an answer that is not MCP, or no tool list after a successful initialize.

No data n

No daily check of the server that day. Neither up nor down.

Sign-in and payment answers count as up: the server is there and answering. The handshake time is the wall time of the whole check (initialize, notifications/initialized and tools/list).

On the server page, badge and widget, an answer that is not a standard MCP endpoint (for example HTTP 400 or 405) is shown as "answers, but not as a standard MCP endpoint", never as down. A single failed hourly or five-minute check does not change the shown status on its own.

A check that gets no answer, a server error, a broken handshake or a request to slow down is tried once more after a short pause, and only the second result is recorded. Servers that share one host are checked a few at a time, spread over the run, so a host serving many servers is never hit with all of them at once. Every status an agent receives says how long ago it was checked, in plain words.

How tool risk levels are estimated

read-only an agent may use it alone. changes data needs a person's approval. high risk deletes, pays, grants, deploys or runs code.

Each level is an automated estimate from what the tool says about itself in public: its name, its description and the annotations its server publishes (such as readOnlyHint and destructiveHint). A server's own annotations count first. A tool whose name and description only describe reading is read-only when nothing suggests it changes data; a tool that the server does not label and whose purpose is unclear is treated as needing approval.

It is an estimate, not a security audit, and it can be wrong both ways. A tool with an alarming name may only read, and a tool with a mild name may do something risky without saying so. A level is never a judgement of a server or of the people who run it. If a level is wrong for your server, publishing accurate annotations fixes it at the next check; you can also write to us (see corrections below).

How often servers publish these annotations, and how often the tools that delete, pay or send are left unmarked, is counted each month in our study MCP Tool Risk Labels (totals only, no server named).

Findings shown per server

Heavy tool list

A very large tool list (about 10,000 tokens or more).

Very long description

A tool description that is very long.

Missing descriptions

Some tools have no description.

No annotations

No tool declares annotations.

Missing schema

Some tools declare no input schema.

Duplicate names

Two tools share a name.

Older protocol

The server answers with a protocol version older than 2025-03-26.

Slow

The whole check took over 3 seconds.

Some pattern checks on tool descriptions are kept for a person to review and are never published or shown to agents, because sampled matches were false positives.

How token cost is estimated

The size of a tool list is the length of the JSON of the tools array as tools/list returned it. Tokens are estimated as that length divided by 4. Real counts depend on each model's tokenizer, so this is an estimate, used the same way for every server.

Each 7Maps answer states an estimate of the tokens it saved: what an agent would realistically spend to make the same decision without 7Maps (one connection and tool list per server in question, up to a ceiling, or a web search to find a tool), minus the answer itself and the share of the agent's context taken by 7Maps' own tool definitions, never below zero and with a ceiling per answer. Always labelled an estimate.

Protocol versions in use

The MCP protocol has several revisions in use at once. For each server the daily check records the revision it answered to initialize and, when the server answers server/discover, the revisions it lists there. The state report and the monthly report publish counts and shares of servers by their newest revision and by each revision they support, with the date.

A server that does not answer server/discover may support a newer revision than the one counted, so those counts are a lower bound. Servers that ask for sign-in first are not counted. A revision is a fact about the protocol a server speaks, never a rating of the server.

The same answers also say which MCP extensions a server declares in its capabilities (for example a proposed events extension). Since version 1.9 the daily check records those extension ids, with no extra request, and both reports publish how many servers declare each one. An extension declared by only a few servers is counted without being named. Like a revision, an extension is a fact about the server, never a rating.

Agent payments: declared, never tested by paying

Some servers charge agents per call through agent payment protocols such as x402 or MPP. Since version 2.0 the daily check records, for each server, what it declares about this: whether it takes agent payments, which protocols it names, the price per call it publishes and any allowance it gives at no cost. Everything is read from what 7Maps already receives: the server's answer when it is first contacted (including a payment request, if it sends one), its capabilities, the metadata of its tool list, and its entry in the Official MCP Registry. No request is added.

7Maps never pays, never sends payment details, never calls a tool and never asks for a payment on purpose. A declared price is the server's own statement, shown as declared. When a server declares nothing, or its declarations are unclear or contradict each other, its payment terms are shown as unknown, never guessed. Words in a description are not read as a declaration.

Agents can filter find_tool and route by payment terms, and a paid server's declared price appears next to its status. A payment declaration is never a rating and never changes a server's status, uptime or rank. Verified owners whose server declares payments get an alert when it stops declaring them while it answers. Public figures are map-wide counts and protocol shares only, in /.well-known/7maps.json and on the 7Maps page.

How changes are detected

Each tool's definition (name, description, input schema and annotations) is fingerprinted. When a server's tool list differs from its previous daily check, the difference is recorded tool by tool: added, removed, changed, a tool that can change things rewritten, or a rise in risk (a tool added as high risk, or a level going up). A change while the server reports the same server version is marked silent. Also recorded: started or stopped answering, now asking for sign-in, a new payment address, a redirect to another domain. Change days are kept for 60 days per server.

A level that moves only because 7Maps changed how levels are estimated is not a change by the server. It is never reported by watch, verify_lock, changes_since or the feeds, and never asks a person to approve a server again. A real change on the same day is still reported.

Uptime

Each server keeps its last 30 daily results, one letter per calendar day (o, a, p, d or n as above). Checked days are the days that are not n.

Daily uptime is the share of checked days on which the server answered (with tools, a sign-in request or a payment request). For servers whose owner verified control, five-minute uptime is the share of five-minute checks answered over the last 30 days, and over 90 days once older checks exist. A server that missed any check is never rounded up to 100%. Hourly checks update the current status but are not counted in uptime.

A figure is called a 30-day uptime only from 14 checked days; before that it is labelled "over N days observed". The uptime distribution on the state page appears once the typical server has 14 checked days.

Chance the next call works, and stability

Two estimates from the daily history: the chance the next handshake works (recent days count more) and stability (lower when the tool list changed on more days in the last 30). Both measure the handshake and tool list, not a tool call. The hour-of-day profile keeps the latest result at each UTC hour once several hours have one.

Most reliable by category

A server is listed when it is answering with tools right now, has a category read from its tools, and has at least 14 checked days. The order is by the share of checked days answering over the last 30 days, then response time.

Nothing else changes the order: placement is never sold, and plans, owner verification and agents' ratings do not count. The lists.

How route picks a server and tool

• A tool whose name and description match the task.
• A server likely to answer, and stable over recent days.
• Least privilege: a tool that can do what the task needs, and not much more, is preferred.
• Caution with high-risk tasks: new servers, young domains, gateways and servers that redirect to another domain are not used for them.
• Set aside and named as such: servers not answering with tools, with a tool-list change today, with a confirmed live incident, or with a recent rise in risk when the task changes things.

Placement cannot be bought.

Ratings from agents and gateway sensors

Agents report how a call went with report_road or the last_trip field on a paid call. Fixed fields only, nothing written in the agent's own words: worked or failed, one of seven failure reasons (unreachable, auth, args, server_error, timeout, rate_limited, wrong_result), milliseconds, whether the result matched the description, result tokens, amount charged, one of four surprises (side_effect, unexpected_cost, data_leak_suspected, other) and the tool-list hash the agent saw.

Gateway sensors (opt-in, open source) send the outcome of calls their gateway forwards; what they send is listed in each sensor's README.

How reports count: reports that agree with our own checks count more, paid reports count more than anonymous ones, recent reports count more than old ones, and each reporter's influence is limited. Ratings read the last 30 days. Stars appear only when enough independent reporters, including paying ones, have reported; until then the page says "not enough reports".

Signals that look coordinated are held back until our own checks confirm them.

When a live incident is shown

An incident is shown only when it is confirmed, by our own fresh check of the server or by trusted reports. Anonymous agents alone, sensors alone, or both together never open an incident. Unconfirmed failures are reviewed by a person and are never shown as an incident. An incident ends when a call works again, when the reports age out, or when a person closes it after review.

How the map corrects itself

Results are checked against several independent signals: our own checks, agents’ reports and opt-in gateway sensors, each counted by how often it agreed with our own checks, recent signals more than old ones. A public "not answering" always needs our own check or a confirmed incident. Runs that look like a problem on our side, such as many servers failing at once, are held back and repeated automatically. Sources the map is built from are checked for sanity: a pull that suddenly shrinks never removes servers. Every answer states how old its data is; data past its normal refresh is labelled not current. Suspicions expire unless confirmed again.

Nobody has to act for this: no owner, agent or person at 7IT triggers a correction. Uptime and the tokens-saved estimate carry a definition version; a new definition gets a new version and past numbers stay as they were.

Signed daily history, and how to verify it

Once a day the previous UTC day is sealed. Every file of that day (each server's results, tool lists, changes, the day log of agent reports, and since version 1.8 the log of every hourly, five-minute and observation check) becomes one line, sha256  id: the hash of the file's content and a stable id for the file, in a fixed order (roots signed before version 1.6 show the file's path in place of the id). Then:

root      = sha256( previous root (or "") + "\n" + lines joined with "\n" )
signature = Ed25519 over the 32 bytes of the root, base64

Each day is chained to the one before it, so history cannot be rewritten without breaking every later root. A day that has a root is never signed again. Roots: https://7it.co.il/api/maps?a=root&day=YYYY-MM-DD. Public key: integrity.public_key_pem in /.well-known/7maps.json.

// Node 18+: node verify.mjs
import { createHash, createPublicKey, verify } from 'node:crypto';
const day = '2026-10-02';
const wk = await (await fetch('https://7it.co.il/.well-known/7maps.json')).json();
const r = await (await fetch('https://7it.co.il/api/maps?a=root&day=' + day)).json();
const root = createHash('sha256').update((r.previous_root || '') + '\n' + r.files.join('\n')).digest('hex');
const ok = verify(null, Buffer.from(r.root, 'hex'), createPublicKey(wk.integrity.public_key_pem), Buffer.from(r.signature, 'base64'));
console.log(root === r.root && ok ? 'verified' : 'mismatch');

Or check a day in your browser, with the same steps and the published key: /7maps/verify/.

Checking a single file against its line needs that file; ask through the contact address below. Every check is in the roots from 5 October 2026 (before that, the daily check of every server only). Not in the roots: sensor data, owner files and demand counts.

Where the server list comes from

This data comes from the Official MCP Registry, plus servers their owners submit. 7Maps is a downstream consumer of the registry (an aggregator, in the registry's own terms): once a day it reads the public API (GET /v0.1/servers?version=latest, page by page with the cursor the API returns), keeps its own copy, and adds what the registry does not: its own checks, tool risk estimates, change history and the signed daily record.

• Entries the registry marks deleted are left out of the map.
• If a read of the registry fails or comes back far smaller than the day before, the map keeps the previous list rather than dropping servers.
• Registry metadata is published under CC0; the checks, estimates and history are 7Maps' own.

7Maps is not affiliated with, endorsed by or a partner of the registry or its maintainers, and it does not serve the registry API itself. The registry is in preview and says so: its data can change or reset, which is one more reason 7Maps keeps a dated, signed copy of what it observed.

Data retention

• Kept as written, and part of the public, permanent history: the dated daily files the signed roots cover (results, tool lists, changes, the day log of agent reports), the roots themselves, and daily aggregates.
• Deleted on a schedule, within weeks to a few months: raw sensor batches and raw demand records (only once that day's aggregate exists), page and widget view counts, ask markers and rate counters.
• Per server: the last 30 daily results and change days for 60 days.
• Ratings read the last 30 days of reports and sensor data.

What is never collected

• Tool results: 7Maps-bot never calls a tool and never signs in.
• Text in an agent's own words: reports carry fixed fields only.
• Arguments, results, prompts, user ids, keys or tokens from sensors; a batch with any other field is refused whole.
• Sensor IP addresses.
• Task text, agent ids, IP addresses or user agents in the demand counts owners see.
• IP addresses, user agents or referrers in page view counts.

To run the service and stop abuse, the 7Maps MCP server keeps a short log of calls (tool, time, client name, country, and an agent code that is a keyed hash, not an IP address). It is not published. This site's pages use Google Analytics. Details: privacy policy.

Opt-out and corrections

Opt out: add User-agent: 7Maps-bot and Disallow: / to the host's robots.txt (works at once), or use the form on the 7Maps-bot page, which asks for a short token at /.well-known/7maps-optout.txt so nobody can remove a server they do not control. The host is never contacted again and drops off the published map at its next daily check. Past dated files stay as they were, because signed history is not rewritten. Removal is never charged.

Corrections: owners can verify control to add a short note in their own words and get five-minute checks. Anyone can write through the contact address on 7it.co.il. A wrong rule is fixed in the code and recorded below. Terms for using 7Maps: terms of use.

Changelog

Any change to how servers are checked or rated gets a new version here and in the JSON.