Toolcard · page date 2026-10-17 · rules 2026-10-17.1
MCP tools mapped 1:1 onto a REST API
Map the tool to a capability. Do not add one MCP tool for each REST method.
On 2026-08-27, @arpit_bhayani wrote: "Think of a tool as a capability, not an endpoint." Toolcard recorded 764 likes on that post on 2026-10-17. That sentence is the only verbatim quote Toolcard uses from it.
The MCP specification does not forbid one tool per endpoint, and it does not define this list. The check below is a heuristic. An empty findings list means these checks did not fire. It does not mean the tool is good.
What the name check flags
Finding endpoint-shaped-name fires when the name starts with get, list, create, update, delete, or set, followed by another word. Those six verbs are the ones in the examples this check cites from that note. Letter case and _ or - do not hide the verb, so GET_USER is endpoint-shaped. fetchUser, a bare get, list, Settings, and manage_user are not-endpoint-shaped.
The API message also says that one MCP tool per REST endpoint loads every endpoint into the context window. That clause is Toolcard's summary of the note, not a second quotation.
This table is POST /v1/check on this server on 2026-10-17. Each name was sent with a long description that does not repeat the name, so the other checks stayed quiet.
| Name | Shape |
|---|---|
getUser | endpoint-shaped |
list_users | endpoint-shaped |
createOrder | endpoint-shaped |
updateUser | endpoint-shaped |
deleteUser | endpoint-shaped |
setUserPermissions | endpoint-shaped |
GET_USER | endpoint-shaped |
fetchUser | not-endpoint-shaped |
retrieve_invoice | not-endpoint-shaped |
get or list alone | not-endpoint-shaped |
Settings | not-endpoint-shaped |
manage_user | not-endpoint-shaped |
Check one tool
The box starts as getUser with the description "Get a user". That request returns shape: endpoint-shaped and three finding ids: endpoint-shaped-name, thin-description, and description-echoes-name. The last two cite a different note, @waldekm, 2026-10-13: write the name and description in the words developers use. That note is answered on MCP server loads but the agent never calls the tool. The 40-character cutoff is Toolcard's. A check stores nothing.
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":"getUser","description":"Get a user","inputSchema":{"type":"object","properties":{"id":{"type":"string"}},"required":["id"]}}'
A name that does not trip this check
manage_user with a description of what the tool does, and two input properties, returns shape: not-endpoint-shaped and findings: []. Use the button above to load that body. Toolcard does not treat that result as approval.
Choosing which parameters to expose is a separate question. On 2026-10-13, @AvinashDalvi_ described the work as "translating it into something an agent could call without guessing, picking the right subset of parameters." Toolcard flags more than 8 top-level input properties. That post states no number. 8 is Toolcard's cutoff. Nested properties are not counted. That check is answered on Picking the right subset of parameters.
Same check, other doors
- Markdown twin
- 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