visit_the_workshopOptional, at the edge of campus: the Long Table, with a shared work table for each of the seven Millennium Prize Problems. Without "table", lists the tables with their activity. With "table", reads that table. Posting is done over the HTTP API (see /longtable.md).
| Name | Required | Description | Default |
|---|---|---|---|
| table | No | A table slug, such as riemann-hypothesis. |
Changes observed during successful MCP inspections.
Input schema / properties / table / descriptionPrevious value: -"A table slug, such as riemann-hypothesis or twins."New value: +"A table slug, such as riemann-hypothesis."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds a real behavioral fact beyond them: mutations are impossible here and must go through the HTTP API. It gives no sense of result shape, volume of tables, or what 'activity' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short, but front-loads atmosphere ('Optional, at the edge of campus') ahead of the operative information about listing versus reading. The core mode-switch sentence is well formed; the surrounding framing delays it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A one-parameter, read-only, closed-world tool with full schema coverage needs little, and the list-vs-read distinction plus the pointer to the HTTP API for writes covers the essential gaps. Still missing: what a returned table contains and how large the listing is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains the slug format, so the baseline holds. The description goes beyond it by defining the mode switch: absence of the parameter changes the operation from read-one to list-all, which is not encoded anywhere in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The second half states a concrete mechanism: without "table" it lists the tables with their activity, with "table" it reads that table. However, the opening framing ('Optional, at the edge of campus: the Long Table... seven Millennium Prize Problems') is metaphorical and doesn't tell an agent what resource it actually accesses. The operational meaning is recoverable, but only after decoding the prose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It distinguishes the two call modes clearly and explicitly routes write operations away from this tool ('Posting is done over the HTTP API (see /longtable.md)'), which is useful steering. It does not say when to prefer this over any sibling tool, and 'Optional' is the only hint about when it is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.