inspect

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose meaningful behavior: style is 'as rendered' with inheritance, bboxes are measured by Inkscape, and large layers/groups are summarised with counts and first/last ids (a truncation/summarisation trait the agent must know to expand results). It still omits read-only guarantees, error behavior, and which document is targeted by default, leaving gaps for a 5-param tool.

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?

The main outline behavior is front-loaded, and the second paragraph cleanly enumerates the find filter modes with compact examples. It is information-dense with little waste, though the run-on first sentence is somewhat heavy.

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?

With no output schema and no annotations, the description does the needed work of describing what the return contains (tree structure, per-element style, text, hrefs, bboxes) and how summarisation appears. The main remaining gap is the unspecified doc_id — the agent cannot tell from the description which document is inspected by default.

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 description coverage is 0%, so the description must compensate for all five parameters. It explains max_children (summarisation threshold), layer (name or group id), and find with worked examples including colour-notation tolerance. But bbox and doc_id are never mentioned, leaving two parameters entirely undocumented in both schema and description.

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 concretely defines the tool as producing a rendered document outline (layers, groups, elements with ids, style, text, use hrefs, and Inkscape-measured bboxes), which is far more specific than the bare name 'inspect'. It is clearly the structural/rendered read tool rather than a mutation or preview tool. However, it never explicitly contrasts itself with siblings like render_preview or document_open, so it stops short of full sibling differentiation.

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 gives clear conditional guidance for its own two modes: the default tree, and 'find: a flat list of matching elements instead of the tree', plus 'To list one of them, pass layer ... and a larger max_children' when a layer/group is summarised. This tells the agent when to switch modes. It does not, however, state when to choose inspect over the other 22 sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.