Before you submit an MCP server
MCP listing preflight
Registries and agents choose a server from what it says about itself: whether it answers, which tools it lists, how each tool is described and what authentication it wants. Paste the server's URL and this page asks it, or paste a tools list you already have and it is checked in your browser.
In URL mode the check sends two JSON-RPC requests, initialize and tools/list, and never calls a tool. In paste mode nothing leaves your browser unless you add a product website, which triggers one request for its llms.txt.
How to use it
- Choose how to check. Paste the public HTTPS address of your MCP endpoint, or paste the JSON your server returns for tools/list.
- Run the preflight. Press Run preflight. A URL is checked live; pasted JSON is analysed instantly in the page.
- Read the checklist. Each check is marked pass, warning or fail, with the detail that was observed and the change that fixes it.
- Fix and run again. Fix failures first, then warnings. Descriptions and parameter docs are the usual fixes and are cheap to make.
- Submit when it is clean. Submit the product with its MCP endpoint. Listing also requires proving you own the domain, which the submit flow walks you through.
The checks, and the rule behind each
Reachable: the server must answer an initialize request on a public HTTPS URL with a JSON-RPC result that names a protocol version. A reply that is an HTML page, a 401 or a connection failure fails this check, because a registry cannot inspect what it cannot initialize.
Tools listed, names, descriptions and schemas: tools/list must return a non-empty tools array; names must be present and unique and should use letters, digits, underscore, hyphen or dot within 64 characters; every tool needs a description (under 25 characters is a warning); every tool needs an inputSchema of type object, and undescribed parameters are a warning. These follow the tools section of the Model Context Protocol specification.
Auth type: the tool-listing request is made without credentials. A normal reply means tools are public to read. A 401 or 403 with a WWW-Authenticate header is recorded as a discoverable authorization flow; without that header it is a warning. llms.txt: the check requests /llms.txt on the endpoint's host and on its registrable domain and runs the same validator as the llms.txt tool. A missing or malformed file is a warning, not a failure.
Passing is about technical readiness only. It does not verify that you own the domain and it does not guarantee a listing.
Questions
Which requests does the preflight send?
In URL mode it sends an initialize request, then tools/list, using the Streamable HTTP transport, and then fetches /llms.txt from the endpoint's host. It never calls a tool, so nothing on your server is executed or changed.
My server needs a key for everything. Can I still check it?
The URL check will fail at initialization because it sends no credentials. Run tools/list yourself, for example with a client you already use, and paste the JSON into paste mode to check names, descriptions and schemas.
What does a good tool description look like?
One or two sentences that say what the tool does, what it returns and when to call it, for example which input identifies the record. An agent picks tools from this text alone, so repeating the tool's name adds nothing.
What JSON can I paste?
Any of three shapes: the full JSON-RPC response to tools/list, an object with a tools array, or a bare array of tool objects. Each tool should have name, description and inputSchema.
Does a clean result guarantee a listing?
No. It shows the server is technically ready. A Toolfound listing also needs ownership of the domain proved by a domain email, a meta tag or a DNS TXT record.
Why is llms.txt part of an MCP check?
An agent that finds a server often also reads the product site. An llms.txt that links the docs and the endpoint gives it a short route from the product to the server. It is a recommendation, so its absence is a warning.