Toolcard · page date 2026-10-17 · rules 2026-10-17.1

MCP server loads but the agent never calls the tool

A server can load while the tool stays uncalled. A short description, or one that only repeats the name, is one place to look.

On 2026-10-13, @waldekm wrote: "My MCP server loads but the agent never calls it." Toolcard recorded that sentence on 2026-10-17. It is the only verbatim quote Toolcard uses from the post.

Toolcard's own summary of the note, already on the homepage, is to write the name and description in the words developers use. The post states no character count. 40 is Toolcard's cutoff.

These checks read the name and the description in the request. A loaded server is outside what a check can see. An empty findings list means these checks did not fire. It does not mean the tool is good, and it does not mean an agent will call it.

What the description checks flag

Finding thin-description fires when the description is omitted or shorter than 40 characters after trimming. Finding description-echoes-name fires when every remaining word in the description is already in the name. Letter case and _ do not count as a difference, so Lookup invoice echoes lookup_invoice.

Before that comparison, Toolcard drops these words: a, an, the, to, of, and, or, for, in, on. Lookup the invoice is 18 characters and still returns both thin-description and description-echoes-name.

The name check is separate. getUser with "Get a user" is endpoint-shaped and also returns endpoint-shaped-name. That finding is explained on MCP tools mapped 1:1 onto a REST API.

This table is POST /v1/check on this server on 2026-10-17. Each body included one input property, so the schema checks stayed quiet. lookup_invoice is not endpoint-shaped. "Omitted" means the JSON had no description field.

The 45-character row only repeats the name. It passes the character cutoff and still returns description-echoes-name. The 40-character row returns findings: []. A description can clear this cutoff and still be a weak description. Toolcard does not treat that result as approval.

Check one tool

The box starts as lookup_invoice with the description "Lookup invoice". That request returns shape: not-endpoint-shaped and finding ids thin-description and description-echoes-name. stored is false.

The response appears here. Nothing you type is stored by a check.

curl -s -X POST https://agentghostedme.com/v1/check \
  -H 'content-type: application/json' \
  -d '{"name":"lookup_invoice","description":"Lookup invoice","inputSchema":{"type":"object","properties":{"id":{"type":"string"}},"required":["id"]}}'

A description these checks leave alone

lookup_invoice with "Find a bill from the number printed on the PDF." is 47 characters. It returns shape: not-endpoint-shaped and findings: []. Use the button above to load that body. Toolcard does not treat that result as approval.

Whether an agent later called the tool is a separate report. POST /v1/outcomes stores the name, a SHA-256 of the description if you sent one, and called or ignored. The public summary is counts only.

Same check, other doors

• Markdown twin
• Answer: one MCP tool per REST endpoint
• Answer: picking the right subset of parameters
• GET /v1/rules
• GET /v1/examples
• /llms.txt
• Toolcard home

Toolcard is not affiliated with the people or the projects cited. Privacy · Terms