list_drawingsLists visible drawings with their Space and folder, most recently edited first. Use it to find and browse drawings before reading or editing them.
Lists the drawings you can see, most recently edited first, with their Space and folder.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 50. | |
| space | No | Only this Space. | |
| folderId | No | Only this folder (see list_folders). |
Changes observed during successful MCP inspections.
v0.8.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered; the description adds genuinely new behavior by disclosing default sort order (most recently edited first) and that Space and folder are attached to each result. It does not mention pagination or what happens when limit is exceeded, but for a read-only listing the added context is solid.
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?
One sentence, front-loaded with the verb and scope, then ordering, then return shape. No filler and nothing an agent has to re-read.
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 simple read-only list tool with zero required parameters, full schema coverage, and safety already carried by annotations; the description covers what it returns and in what order. Only pagination behavior is unaddressed, which is minor here.
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%, so all three parameters (limit, space, folderId) are already documented, including the enum and the list_folders cross-reference. The description adds no meaning beyond "Space and folder" appearing in the output, so the baseline 3 applies.
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 description uses a specific verb and resource ("Lists the drawings") and pins down scope ("you can see"), ordering ("most recently edited first"), and returned fields (Space and folder). It stops short of naming how it differs from search_drawings, which is the closest sibling, so an agent must still infer the browse-vs-search split.
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?
"the drawings you can see" implicitly frames this as an unfiltered browse-all operation, which suggests search_drawings is for targeted lookup, but that contrast is never stated. No exclusion, no prerequisite, no guidance on when the filters make it the wrong choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.