We scanned 1,320 public MCP servers. Here's what agents are being handed.

Vulnify research · snapshot taken on 17 October 2026 · all figures are aggregate, and no individual server is named.

AI agents increasingly get their tools from remote MCP servers. You paste a URL, and the agent can suddenly search, write, send or run code. We wanted to know what that surface looks like in practice, so we asked public servers one polite question each: "what tools do you have?"

Read this first. The classification is heuristic. It describes what a tool can do based on its name, description, inputs and annotations. It is not a finding that any server is vulnerable or unsafe. Servers that require login (about 38% of the hosts we tried) are not included. Tool lists change, so treat this as a snapshot from 17 Oct 2026.

What we did

• Collected remote MCP endpoints from the official MCP Registry and community lists, and probed 2,841 endpoint URLs across 2,593 unique hosts, so that large hosting platforms don't drown everyone else out.
• Sent only initialize and tools/list. We never called a tool and never used credentials. Concurrency was low, the user agent clearly identified the scan, and any 401/403 or authentication error ended the probe of that endpoint.
• 1,320 servers answered without login and listed at least one tool, 16,431 tools in total. Another 993 hosts (38%) asked for authentication, and we left them alone.
• Classified every tool into action classes: READ, WRITE, DELETE, EXPORT, SEND, PAY and EXEC. We also recorded MCP's optional safety annotations (readOnlyHint, destructiveHint).

Headline numbers

What the server's tools can do	Share of no-login servers
Only read-style tools	41%
Write or modify data	23%
Delete something	19%
Send messages, posts or outbound requests	35%
Handle payments (strict: tool name or input schema, e.g. amount, charge, transfer)	15%
Execute code, shell or raw queries (strict: name or inputs)	6%
A send tool plus at least one read-style tool (upper bound, see method)	up to 32%

• The median server exposes 6 tools (mean 12.4; the top 10% expose 24 or more; the largest lists several hundred).
• About 4% of servers have write, delete, send and payment tools in one place (payments counted strictly).
• The most common leading verbs are get, list and search. The most common action verbs include create, update, delete and submit.

Annotations: better than expected, not a guarantee

• 64% of servers annotate at least one tool, and 70% of tools carry some hint.
• Still, 1 in 7 delete-capable tools (14%) carry no annotation at all, and 1 in 4 (25%) are not marked destructiveHint: true. Among servers that can delete, 1 in 5 ship at least one delete tool with no annotation.
• Hints are self-declared. Of the tools that declare readOnlyHint: true, 15% have names or inputs that look like a write, delete, send, payment or execution (payments and execution counted strictly). That doesn't mean the tool misbehaves. It means the label alone can't tell a client what the tool does.
• 74 code-execution tools and 197 send tools carry no hints at all.

Why it matters

The MCP spec says clients should treat annotations as untrusted hints. In practice, an agent that connects to a server inherits every tool on the list. About a fifth of servers bring a delete tool. About a third can send data out, and almost all of those also expose a read-style tool. We can't tell from a tool list whether those tools reach private data, so treat this as an upper bound. Where they do, reading and sending in one place is the pairing prompt-injection exfiltration needs.

What to do

• Server authors: annotate every tool, set destructiveHint on anything irreversible, and split read and write servers where you can.
• Agent builders: don't rely on hints alone. Check DELETE, SEND, PAY and EXEC calls at runtime with allow, review or block before the call runs. Our Agent Action Risk Framework shows one way to score them.
• Security teams: keep an inventory of the MCP URLs your agents connect to and review their tool lists the way you'd review OAuth scopes.

Check any server's tool list with the Vulnify MCP Scanner. It's read-only and uses the same method as this study.

Methodology and limits

• Heuristic classification. Classes come from tool names, descriptions, input schemas and annotations. They say what a tool may do, not that it is vulnerable. PAY and EXEC are reported in a strict variant (name or input schema only), because descriptions of paid-per-call tools inflate the loose payment figure (32% of servers). Tools with no other class count as READ. So read-style includes any tool we couldn't classify, and the read + send share (up to 32%) is an upper bound, not confirmed access to private data.
• "Looks like it writes" means the tool's name or inputs match the WRITE, DELETE, SEND, PAY or EXEC heuristics while it declares readOnlyHint: true. PAY and EXEC use the strict variant here too.
• Sample. Endpoints come mostly from the official MCP Registry (entries without required headers), plus a small set from community lists. Endpoints that need an API key or login, about 38% of the hosts we tried, are excluded. These numbers describe the open, no-login part of the MCP ecosystem, not authenticated enterprise servers.
• Snapshot. Scanned on 17 Oct 2026. Tool lists change, being listed doesn't prove a tool works, and some servers are demos or tests.
• No tool was called and no credentials were used. Per-server data is not published.
• Why and how we keep the data. We ran this study as aggregate security research on public, no-login endpoints. Results are published only as totals, and no server, company or person is named. Hosts on the Vulnify Scanner opt-out list are left out of the dataset. The raw tool lists and per-server files stay internal and are deleted by 17 Oct 2027. Only the aggregate figures are kept.
• Opt-out and contact. Run an MCP server and want it left out of future scans? Write to security@vulnify.io from an address at the server's domain. Questions about this research: security@vulnify.io. Our Privacy Policy explains how scanner data is handled.