MCP Server: call MCP Hunter from your agent | MCP Hunter

Call MCP Hunter from your agent

MCP Hunter is itself an MCP server. Point your client at the address below and six read tools answer from the board: what launched this week, what a product returned when we connected to it, and what happened when we called every remote address in the official registry. No account, no key, nothing to sign up for.

https://mcp-hunter.com/mcp

Add it to your client

Claude Code takes it in one line:

claude mcp add --transport http mcp-hunter https://mcp-hunter.com/mcp

Any client that reads an mcpServers block takes this:

{
  "mcpServers": {
    "mcp-hunter": {
      "type": "http",
      "url": "https://mcp-hunter.com/mcp"
    }
  }
}

Streamable HTTP, protocol revisions 2024-11-05 through 2025-11-25, and no authorization step. The endpoint answers POST only, so a client that opens a server-to-client stream gets a 405 and carries on, which is what the spec asks for.

What you can ask for

  • search_mcp_servers finds a listed product by name, tagline, description or category, and can be filtered down to the ones we connected to successfully.
  • get_mcp_server returns one listing in full: how it is reached, what it returned when we called it, what a guarded server published about signing in, and what a package registry held for it.
  • weekly_leaderboard returns one week's ranked board. A closed week is frozen for good, because votes are only accepted while a week is open.
  • mcp_ecosystem_stats returns what we measured calling MCP servers in bulk: the share of the official registry that answered, refused, or went nowhere on a dated sweep. Aggregates only, with no endpoint named.
  • check_mcp_server and get_check_result run our connection test against any endpoint you name. See below.

Check any endpoint, listed here or not

This is the tool worth having whether or not you care about the board. Hand it the address your client would POST to, and we run the same handshake the gate runs: the negotiated protocol revision, what the server calls itself, how many tools it exposed, what they are named, whether they carry descriptions, and one round trip in milliseconds. It is the answer to "what am I actually about to install", and it comes with a permanent URL you can send to a person.

A real one, run through this endpoint on 11 September 2026:

check_mcp_server  url: https://mcp.deepwiki.com/mcp

Verified 2026-09-11 | 3 tools | responded in 686ms
Protocol revision it answered with: 2025-11-25
It calls itself: DeepWiki 2.14.3
Tools it exposed (3):
ask_question, read_wiki_contents, read_wiki_structure

The check runs on a queue, so the first call hands back a token and get_check_result returns the finished receipt a second or two later. Each caller gets 5 checks a minute and 50 a day, which is sized for an agent verifying something it is about to install. If you would rather do it by hand, the same test has a form.

What the answers mean

Every measurement carries the date we took it, and the tools hand it back in those words: "Verified 12 August 2026, 13 tools, responded in 400ms". We connect once, at submission, so that line describes that moment rather than today. A model reading it should quote the date rather than report the server as live, and the server's instructions say so in as many words.

A listing we could not reach carries what happened and nothing else, and one whose product starts from a local command carries no tool count at all, because we never run a command a stranger submitted. That is the whole claim: a server answered us on a date, never that it is safe to install. We have not read anyone's source and we do not monitor uptime.

Limits

  • Read-only. Voting and submitting need a signed-in person, and no tool here writes to the board.
  • 60 calls a minute per caller, and 5 connection checks a minute with 50 a day.
  • Everything returned is already public on this site. The tools are a second way to read it, not a second set of facts.

If you ship an MCP server

Launch it here and the same record is what your listing is built from. Submitting takes a URL or a start command, one product per maker per week, and a human reads every submission. Or read this week's board first.

Agents that would rather read than call: every listing has a Markdown twin at /server/{slug}.md, and llms.txt names every one of them with its evidence line.