Preview a symbol

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

Annotations already mark the tool as read-only and non-destructive, but the description adds substantial behavioral detail: every record kind gets its own marker, followed by a per-kind count line and legend; coordinates are schematic units (10 units = 1 grid); output is limited to max_width x max_height characters. This fully paints the execution behavior and output format beyond what annotations convey.

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 description is a single dense paragraph but is well-organized: purpose, output format, parameter semantics, units, then routing to alternatives. Every sentence carries needed information, though the structure could be slightly broken up for easier scanning. No wasted words.

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?

For a read-only preview tool with a full schema, the description covers the output structure, parameter effects, coordinate system, output size limits, and alternatives. There is no output schema, but the description explicitly describes what the ASCII-art output contains (markers, count line, legend), so an agent knows what to expect. Nothing essential is missing.

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 each parameter's basic meaning is documented. The description adds extra nuance by explaining scale in 'characters per 10 schematic units', clarifying part_id's default and the all-parts behavior of 0, and stating the coordinate-unit convention. This goes beyond the schema descriptions while remaining consistent with them.

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 opens with a specific verb and resource: 'Render an ASCII-art preview of one symbol in a .SchLib.' It immediately clarifies the tool's scope (one symbol), its purpose (quick visual check), and its non-archival nature (not a drawing to keep), which distinguishes it from other library tools without needing to see sibling names.

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?

Provides explicit routing: use get_component or read_schlib for exact coordinates/properties, and render_footprint for a .PcbLib footprint. This tells an agent exactly when to choose this tool over alternatives and when to defer to others, leaving no ambiguity about its niche.

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