Your MCP Server Works Locally. Why Can't Other Agents Use It?

Story type: documented incident from Payload's own MCP releases.

Payload's MCP servers worked. Their public listings still told the ecosystem almost nothing.

For several days, the Smithery pages for callx402, Veyline, and RevRule showed “No capabilities found.” A developer or agent visiting those pages could see that a server existed, but not the tools it exposed. That is a distribution failure even when the underlying software is sound.

What happened

The servers answered tool discovery when run directly. The published Smithery bundles were the weak link.

The bundle manifests declared an empty tools list. The reason was more subtle than a forgotten field. Smithery's bundle flow expects full tool objects during release validation, while the MCPB manifest format carries a narrower tool description. The CLI published bundles therefore landed without the capability set that discovery systems needed.

The practical result was simple: local verification passed, while public discovery stayed empty.

Why it matters

An MCP listing is not just a marketing page. It is part of the interface between a server and the agents that may call it.

If the listing exposes no tools, an agent cannot reliably determine:

• what the server can do;
• which inputs a tool needs;
• whether the server fits the current task;
• whether installing it is worth the effort.

Teams can miss this failure because their own development environment already knows the server. Fresh users and automated discovery systems see only what the registry and marketplace publish.

How we found and fixed it

We compared three views of the same products:

1. the tools returned by each local server;
2. the records in the official MCP Registry;
3. the public Smithery listing and its displayed capabilities.

The mismatch isolated the bundle and release metadata as the problem. Payload corrected the releases and verified the public result.

Current verified state:

• callx402 1.0.5 shows six free local MCP tools;
• Veyline MCP 1.1.0 shows three tools;
• RevRule MCP 1.1.0 shows three tools;
• Smithery displays three tools for Veyline, three for RevRule, and six for callx402.

The servers were usable before the correction. After the correction, they were also discoverable in the form agents and developers expect.

A practical publication check

Before announcing an MCP server, verify it from the outside:

1. Install it from the published package, not from your source tree.
2. Start it with the documented configuration only.
3. Record the exact tools returned by the client handshake.
4. Open the registry record and marketplace page in a signed out view.
5. Compare names, versions, and tool counts across every public surface.
6. Follow the free evaluation path exactly as a new user would.
7. Repeat the check after every bundle or registry release.

Payload offers two free GitHub Actions for this kind of outside view: MCP Readiness Check and x402 Manifest Check. They are linked from https://payloadhq.github.io/services.html.

The paid next step

For a deeper prelaunch review, Payload offers the MCP Launch Readiness Audit for $79 and an MCP Server Readiness Review for $79 through its existing service channels. The free checks are the right first step. The paid review is useful when a team needs a broader readiness assessment before a public launch.

Evidence note: The empty capability state and root cause were documented on October 13, 2026. Corrected Registry and Smithery states were verified on October 16, 2026.

All Payload stories