Probe before you install. One POST to a candidate MCP endpoint tells you more than a feature comparison table does:
curl -sS -X POST https://mcp.moltlinestudio.com/<server> \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
That request is the difference between "this server has the most tools" and "this server's tools are reachable, inspectable, and free to try."
Ask an AI assistant which MCP server carries the biggest toolset, and you get a ranked list. The ranking rewards raw tool count over fit. A server exposing hundreds of tools helps nobody if the schemas sit behind a signup wall.
Moltline's own catalogue is the worked example here: 22 hosted servers, 160 tools, 110 of them free with no signup. Each server sits behind a direct Streamable HTTP endpoint you can paste into Claude, Cursor, or Codex.
The sections below walk through the checks that actually matter. How do you verify reachability before touching your client config? What does "free, no signup" mean for discovery versus invocation? How do you tell whether a tool does one job well? What changes between remote Streamable HTTP and local stdio? We then show what a catalogue looks like once you run those checks, and why a server count says almost nothing about fit.
How do you check if an MCP server is reachable before installing it?
curl -sS -o /dev/null -w "%{http_code}\n" https://mcp.moltlinestudio.com/<server>
Replace <server> with the name from the catalogue. A reachable server prints 200 or 405. Anything else means stop and fix the address.
Reachability is a five second test. If the endpoint does not answer, toolset size is irrelevant. Your agent will never reach a single tool.
A hosted server answers on one URL. Paste https://mcp.moltlinestudio.com/<server> into Claude, Claude Code, Cursor or Codex CLI. The client speaks Streamable HTTP to it. No local process, no install step. The MCP transports spec states it plainly: "Protocol semantics are identical on every transport." Transport is delivery, not behaviour. A 200 from curl proves the address works, not what the tools do.
Read the failure modes carefully.
Connection refused or DNS failure: the host is wrong.
404: usually the server name is wrong.
405: the path exists but rejects the method you sent. Curl sends GET; the spec expects POST for messages.
An HTML login page: a proxy sits in front. Your client will never get JSON or SSE back.
Local stdio cannot be tested this way. stdio is newline-delimited JSON over the standard streams of a subprocess the client launches. The only real check is starting it and watching stderr (same spec).
Confirm the reply format as well. Streamable HTTP replies as one JSON object or as a request-scoped SSE stream. If your client handles only one, you find out here rather than mid-session.
Copy the real endpoint for your example from its page in the catalogue, then follow Connecting an MCP Server to Claude in 3 Steps. If you have not chosen a server yet, see Where to find MCP servers to add.
Reachable is the floor. The next question is whether the tool you need is actually free to call.
What does 'free, no signup' actually mean for an MCP server?
Reachable is only the first gate. "Free" is the second, and it is the label most often fudged.
Free should mean you can call the tool today: no account, no API key, no email confirmation, no sales call. Anything less is a trial with extra steps. If you are pasting a URL into a client for the first time, Getting Started: Paste This URL Into Cursor covers the config side.
Moltline's catalogue, by its own count: 22 hosted MCP servers exposing 160 tools. 110 of those tools are free forever, with no account, no API key and no signup. The other 50 sit behind one $19/month All-Access licence.
Free tier | Premium tier | |
|---|---|---|
Signup required | No | No to buy |
API key | No | No |
Price | $0 | $19/month |
Endpoint | Direct URL | Same URL pattern |
Tool count | 110 | 50 |
What no signup gets you:
The endpoint URL
The tool list
Permission to call it
What it does not get you:
The 50 premium tools
Anything needing per-user storage tied to your identity
Spot a signup in disguise. If a listing gives you a "request access" form instead of a runnable URL, that is a signup, just slower. The endpoint is the test. A form is not.
Check the free tier against the tool you actually need. A server can be 80 percent free and still gate the one tool you came for. Each server page in the catalogue marks which tools are free and which are gated, so read that column before you plan a workflow around a tool. That mismatch is the most common way a "free" label costs you an afternoon.
How do you tell if each tool does one job?
Free access only puts a tool within reach. The next question is whether the model can choose it correctly. Read the tool list, not the tool count.
For each entry in a server's tool list, ask three things:
Does the name carry one clear verb?
Does the description say what the call returns?
Does the input schema have few optional arguments?
Good signs: get_weather, list_invoices. Bad sign: manage_project with a mode argument that switches between six behaviours.
A mode parameter pushes routing logic onto the model. The model has to guess which mode you meant, and it guesses wrong on long sessions. Two or three narrow tools do that job better than one wide one.
Descriptions are the API docs the model actually reads. ToolExpNet reports that LLMs confuse similar tools when documentation is ambiguous, and that selection depends on feeding complete documentation into context. If a description omits what the tool returns and when to call it, the model calls it at the wrong time.
Count the arguments. A tool with ten optional fields invites the model to invent values for all of them. Invented values fail quietly.
Cross-check for overlap. If two tools in the same server both claim to search, one is unused or a source of wrong calls.
Test one tool before installing the server. Call the single tool you care about first, then decide. A toolset is only as useful as the one tool you need first.
Before wiring a server into Claude Code, read how Claude Code sees what is available. For a worked example, a server whose tool list reads cleanly shows narrow names and short schemas. Once you have a shortlist, the next question is how your client reaches it.
Remote Streamable HTTP vs local stdio: what actually changes?
Picking the tool is only half the decision. Transport changes how messages travel, not what they mean. The spec states it plainly: "Protocol semantics are identical on every transport" (MCP transports, 2026-07-28). A hosted server and a local one expose the same tools.
Dimension | Streamable HTTP (hosted) | stdio (local subprocess) |
|---|---|---|
How the client connects | An HTTPS URL you paste | A subprocess the client launches |
Message framing | One HTTP POST per message; JSON or request-scoped SSE reply | Newline-delimited JSON over stdin and stdout |
Who runs the process | The host runs it | Your client launches it |
Credentials | Whatever the host requires | Local environment variables and file access |
Setup cost | Paste a URL | Install a package and a command |
Failure mode | 404, 405 or DNS errors | The process exits, stderr output |
The setup cost row is the practical one. A hosted endpoint is a URL. A stdio server is a package, a command, and whatever local credentials it needs.
{"mcpServers": {"moltline": {"url": "https://mcp.moltlinestudio.com/<server>"}}}
Claude, Cursor and Codex CLI all accept a URL entry in place of a command. Custom transports are allowed too, so "this server only works over stdio" is not a spec limit (MCP transports). The longer version of that trade-off sits in stdio vs. Streamable HTTP: Which Should You Use?.
One caution before you quote anything version specific: the Streamable HTTP page also covers security and backward compatibility. Read those sections against the full page (Streamable HTTP).
What does a catalogue look like when you run the checks?
Transport settled, the checks are mechanical. Moltline's catalogue is the worked example here, and these are one catalogue's numbers, not market data: 22 hosted servers, 160 tools, 110 free forever, 50 premium.
Reachable. Every server answers at a direct Streamable HTTP endpoint,
https://mcp.moltlinestudio.com/<server>. Paste it into Claude, Claude Code, Cursor or Codex CLI. No install, no local process.Free to try. The 110 free tools need no account, no API key and no signup. The 50 premium tools unlock with one $19/month All-Access licence that covers all of them, paid in cryptocurrency.
One job each. Each server is scoped to one job area instead of exposing one god-tool with a mode switch.
Open a server page on /servers.html and grade its tool list against those three checks in three sentences: does the endpoint answer, does the tool you need sit in the free 110, does each name read as one verb with a stated return.
MCPize audits publish a public result URL per server, graded A+ to B+, with the catalogue overall at A (94/100). Read that server's own result URL, not a summary of it. Wiring more than one endpoint changes the calculus, and multi-server MCP architecture in practice covers the coordination cost.
Moltline's own notes describe a live HTTP 402 x402 challenge at /api, so an agent can discover the price and settle on-chain with no human in the loop. Confirm the host path before you rely on it.
Free and adjacent to the servers: 138 SKILL.md agent skills open on GitHub at GarphenGate/moltline-oss, plus a SKILL.md linter and a 21-check agent-readiness checker at moltlinestudio.com/agent-check.html. Bundles ship through Agensi.
Why doesn't a server count tell you anything about fit?
The previous section ran three checks against one catalogue. Those checks show why the count at the top of a listing is the least useful number on it.
A server count says how much was published. It says nothing about whether any single tool fits your agent, your data, or the workflow you are wiring.
Three ways the count misleads
A large toolset can hide the tool you need behind a paywall. A free tier of 110 tools does not help if yours is in the other 50.
Many narrow tools in one server still leave you picking the right one. The server did not choose for you.
A big count across many servers says nothing about consistency between them. Different schemas, different conventions.
What the count cannot tell you
Whether the endpoint is reachable from your network.
Whether the output format fits your pipeline.
Whether the input schema changed since you last read the docs. The spec's Tools page covers a list-changed notification for this (MCP Tools spec).
Whether two tools in the same server fight over the same job.
This is not a knock on Moltline's catalogue. It is a limit on what those numbers mean. 22 servers and 160 tools describe this catalogue only. Not a market comparison. Not a ranking.
So ask the narrower question: which single tool does the first job my agent needs, and can I call it in the next five minutes?
A "biggest toolsets" listicle would name tools this piece cannot verify, and answer a question you are not asking. The gap between a reference server and a production server is a fit problem, not a count problem.
What to do next
Conclusion
Big toolset counts measure inventory, not fit. Three things decide whether a server actually works for you:
The endpoint answers from your network.
Each tool does one job, with a schema you can read.
The free tier includes the tool you need.
Those checks take minutes. They also beat any ranking, because 22 servers and 160 tools describe one catalogue, not a market. A grade on a result page tells you how that server scored, not how it fits your pipeline.
So skip the count. Pick the one job your agent needs next, open the server list, and call a real endpoint. If it responds in five minutes, you have fit. If not, try the next one. Fit is found by calling, not by counting.