# 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.

Page date 2026-10-17. Rules version `2026-10-17.1`. The HTML page, which includes the same checker, is [here](https://agentghostedme.com/mcp-tools-mapped-1-to-1-onto-a-rest-api.html).

On 2026-08-27, [@arpit_bhayani](https://x.com/arpit_bhayani/status/2092973180306833697) 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. 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

`getUser` with the description "Get a user" returns `shape: endpoint-shaped` and finding ids `endpoint-shaped-name`, `thin-description`, and `description-echoes-name`. The last two cite [@waldekm, 2026-10-13](https://x.com/waldekm/status/2109907029963780339). That note is answered on [MCP server loads but the agent never calls the tool](https://agentghostedme.com/mcp-server-loads-but-the-agent-never-calls-it.md). The 40-character cutoff is Toolcard's. A check stores nothing.

```
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"]}}'
```

`manage_user` with a description of what the tool does, and two input properties, returns `shape: not-endpoint-shaped` and `findings: []`. Toolcard does not treat that result as approval. The same body is the second sample at [GET /v1/examples](https://agentghostedme.com/v1/examples).

Choosing which parameters to expose is a separate question. On 2026-10-13, [@AvinashDalvi_](https://x.com/AvinashDalvi_/status/2110042506901786873) 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](https://agentghostedme.com/picking-the-right-subset-of-parameters.md).

Rule list: [GET /v1/rules](https://agentghostedme.com/v1/rules). Home: [Toolcard](https://agentghostedme.com/).

Toolcard is not affiliated with the people or the projects cited.

[Privacy](https://agentghostedme.com/privacy.html) · [Terms](https://agentghostedme.com/terms.html)