Toolcard · page date 2026-10-18 · rules 2026-10-17.1
Picking the right subset of parameters
A tool the agent can call without guessing needs a smaller parameter list. More than 8 top-level input properties is one place Toolcard looks.
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 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 that the work includes choosing which parameters to expose. The post states no number. 8 is Toolcard's cutoff. Nested properties are not counted.
These checks count keys on inputSchema.properties. They do not see which parameters a caller actually needed. An empty findings list means these checks did not fire. It does not mean the subset is the right one, and it does not mean the tool is good.
What the wide-input check flags
Finding wide-input fires when inputSchema is a JSON object, its type is object, and properties has more than 8 keys. 8 keys do not fire it. A missing properties key is counted as zero. A name listed only in required is not counted. Nested keys under one property are not top-level keys.
Omitting inputSchema returns missing-input-schema, not wide-input. An inputSchema whose type is string returns input-schema-not-object, not wide-input. Those two checks follow the MCP schema reference, 2025-06-18 revision, which lists inputSchema as a required object schema.
The name and description checks are separate. Every row below uses the name find_bill and the description "Return the invoice that matches the number printed on the form." That description is 63 characters, so the description checks stay quiet. find_bill is not endpoint-shaped. The name check is explained on MCP tools mapped 1:1 onto a REST API. The description checks are explained on MCP server loads but the agent never calls the tool.
This table is POST /v1/check on this server on 2026-10-18. stored was false on each row. Rules version 2026-10-17.1. The eight properties, in order, are number, customer, status, issued_after, issued_before, currency, minimum_amount, and maximum_amount. The ninth is due_after. The tenth is due_before. The nine nested keys are name, email, id, city, region, postal_code, country, phone, and tax_id.
| Top-level properties | Schema | Finding ids |
|---|---|---|
| 0 | properties is {} | none |
| 0 | type is object, and properties is omitted | none |
| 1 | number | none |
| 1 | customer only, with the nine nested keys | none |
| 8 | the eight string properties | none |
| 8 | the eight, and customer has the nine nested keys | none |
| 8 | the eight, and required also names due_after | none |
| 9 | the eight plus due_after | wide-input |
| 10 | the nine plus due_before | wide-input |
| not sent | no inputSchema field | missing-input-schema |
| not counted | inputSchema.type is string | input-schema-not-object |
The 9-property row returns wide-input only. The 8-property row returns findings: []. Eight can still be the wrong subset. Toolcard does not treat that result as approval.
Check one tool
The box starts as find_bill with those nine string properties. That request returns shape: not-endpoint-shaped and finding id wide-input. 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":"find_bill","description":"Return the invoice that matches the number printed on the form.","inputSchema":{"type":"object","properties":{"number":{"type":"string"},"customer":{"type":"string"},"status":{"type":"string"},"issued_after":{"type":"string"},"issued_before":{"type":"string"},"currency":{"type":"string"},"minimum_amount":{"type":"string"},"maximum_amount":{"type":"string"},"due_after":{"type":"string"}}}}'
Eight properties this check leaves alone
find_bill with the same description and the eight string properties 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: the server loads but the agent never calls the tool
- GET /v1/rules
- GET /v1/examples
- /llms.txt
- Toolcard home
Toolcard is not affiliated with the people or the projects cited. Privacy · Terms