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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered by structured data. The description adds modest context (pen is lifted, session returns to a home state) but never says what is destroyed or whether the drawing is saved, which matters for a destructive 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?

A single short sentence, front-loaded with the action. The vivid phrasing is memorable, though the metaphor slightly blurs rather than sharpens the meaning given the sibling 'home'.

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 parameters, no output schema, and annotations covering safety traits, the description needs only to convey consequences and timing. It conveys the immediate action but omits what happens to in-progress work and whether this returns the agent to a home state, leaving a real gap for a destructive tool.

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?

The tool takes zero parameters, so there is no parameter semantics for the description to explain. Baseline for a parameterless tool 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 verb 'Stop' plus the resource 'the current drawing' makes the core action identifiable, and 'lift the pen' reinforces the physical metaphor. However, 'go home' overlaps with the sibling tool named 'home', so the scope isn't perfectly disambiguated from its neighbors.

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?

There is no explicit guidance on when to call abort versus alternatives such as 'home' or simply not drawing. The phrase implies stopping an in-progress drawing but never states prerequisites, when-not-to-use, or the relationship to the sibling 'home' tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false. The description adds real behavior beyond that: fetched categories are cached on disk so preview and draw match, web candidates are auto-ranked but many are scribbles or contain written words, and the contact sheet exists precisely because of that unreliability. It omits any statement about rate limits or failure modes when the web fetch fails.

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 content is front-loaded and organized into readable blocks, but it strays into instructions for other tools' parameters — the inline {"doodle": category, "pick": N, "box": [...]} object and order="asis" do not exist in this schema, so that text does not earn its place in this definition and risks confusing the agent about what to pass here.

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?

There is no output schema, so the description reasonably explains what comes back (a category list, or a numbered contact sheet of candidates) and why. Combined with the annotations covering safety and the open-world nature, an agent has enough to call it correctly, with only count/start left unexplained.

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 carries the full burden. It explains 'source' (auto/web/bundled semantics) and 'category' (present vs absent behavior) thoroughly, but 'count' and 'start' are never mentioned, leaving their pagination meaning entirely undocumented. Partial compensation only.

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 names a specific resource (real doodles from Google's Quick, Draw! dataset) and explains two distinct modes: no-category returns the bundled/web category list, and with-category returns a numbered contact sheet. It does not explicitly contrast itself against siblings like preview_paths or draw_paths, but the resource is unique enough that an agent can distinguish it.

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 conditions: use no category to see what's available, supply a category to get a contact sheet and choose a pick, and it spells out the source tradeoffs ('auto' curated-first, 'web' always fetches with more variety but no human review, 'bundled' never goes online). It stops short of naming sibling tools as alternatives for the actual drawing step, so it is clear context without explicit routing.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the agent knows this mutates canvas state. The description usefully adds what is drawn and how to interpret the result, but says nothing about whether existing canvas content is preserved or cleared, or whether a canvas must exist first — meaningful gaps for a mutation 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?

A single sentence that front-loads the action and the artifact, then gives the interpretation rule. No filler, nothing repeated from annotations or schema.

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, the description carries the return-value burden and does so by explaining that the result is a visual frame plus 'F' a human reads. For a zero-parameter diagnostic tool whose annotations cover the safety profile this is nearly complete, missing only the effect on pre-existing canvas content.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description correctly describes a no-argument action.

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?

States a specific verb (draws) plus the exact artifact produced (a frame around the canvas and an 'F' in the top-left corner), which is a purpose no sibling tool shares — draw_paths, draw_svg, draw_text and draw_scene all render user content, not a diagnostic overlay. An agent can identify this tool without opening the schema.

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 clause 'so a human can confirm the canvas orientation' gives clear context for when this tool is appropriate, and the parenthetical 'F must read normally, top-left' states the success condition. It stops short of naming alternatives or exclusions (e.g. use preview_* to check content without mutating the canvas), so it is clear context rather than full routing guidance.

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

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

Beyond the annotations (which only mark it non-read-only, non-idempotent, open-world), the description discloses that it returns a job_id (async job model), clarifies that speed is interpolation granularity rather than a speed dial, and reveals that pen-up travel is governed by the external LINEUS_TRAVEL_SPEED setting. These are meaningful behavioral facts an agent cannot infer from annotations or schema.

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?

Content is front-loaded with the core call contract (paths format, return value) before the parameter detail, and the nested order explanations are indented and scannable. It runs long on the order tradeoffs, but nearly every clause carries decision-relevant information.

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?

No output schema exists, yet the description states the return value (job_id) and explains the async job model. Combined with full parameter documentation and the external travel-speed caveat, an agent has everything needed to invoke it correctly.

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?

With 0% schema description coverage and 3 parameters, the description carries the full load: it documents the paths structure precisely, gives speed's valid range (1–30) and default (5), and enumerates the three order values with their sequencing semantics. This is exactly the compensation needed for an undocumented 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 description states a specific verb and resource — 'Draw polylines given in canvas millimetres' — and pins the exact input shape ([[u,v],...] with each inner list a pen-down stroke). This clearly separates it from siblings like draw_svg, draw_text, and draw_scene that take different input formats.

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 concrete guidance for the 'order' parameter, explaining when each mode is appropriate ('human' for natural-looking output, 'fast' for least travel, 'asis' when the caller controls sequencing). It never names or excludes the sibling preview_paths, so there is no explicit when-not or alternative-tool routing.

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

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

Annotations already declare a non-read-only, open-world, non-idempotent, non-destructive write. The description adds genuinely new behavior: compilation is deterministic and content-hashed (so previewed output is reproduced exactly) and the call returns a job_id and scene_id, signaling async job semantics.

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?

Three tight sentences: purpose, the determinism guarantee, and the return contract. Nothing is redundant and the differentiating information (see preview_scene) is front-loaded in the first sentence.

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 mutation tool the annotations carry the safety profile and the description names the return values, which is good. But with a nested scene object at 0% schema coverage and unexplained 'order'/'speed' parameters, an agent lacks the argument-level detail needed to invoke it confidently.

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% across three parameters (order, scene, speed). The description points to preview_scene for the shape language of 'scene', which is useful, but 'order' and 'speed' receive no explanation anywhere, so the description does not compensate for the coverage gap.

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?

States a specific verb+resource ('draw a declarative scene') and explicitly ties it to its sibling by noting the scene object is the same as preview_scene, so the agent can separate 'draw' from 'preview' and from draw_paths/draw_svg/draw_text without opening schemas.

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?

Implies a clear workflow: pass the scene you previewed and it draws exactly what you saw, which routes the agent through preview_scene first. It does not explicitly state when to choose this over draw_paths, draw_svg, or draw_text, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=false, non-idempotent, open-world, non-destructive, so the mutation profile is covered. The description adds real value beyond them: the coordinate box in canvas mm, aspect-ratio preservation, the fill/hatching limitation, and the asynchronous 'Returns a job_id' contract.

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?

Three tight sentences with the core action, sizing semantics, and return value front-loaded; no filler and every clause is actionable.

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?

Covers the essential action, units, aspect ratio, content suitability, and async return. With 7 undocumented params and no output schema, gaps remain around 'order', 'speed', and how to retrieve the resulting job, which sibling tools like get_job would address.

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 carries the burden. It meaningfully explains the x/y/w/h box and aspect-ratio behavior, but leaves 'order' (default 'human'), 'speed', and the 'svg' payload itself completely unexplained.

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?

States a specific verb+resource ('Draw an SVG') and adds the sizing semantics (fitted into box in canvas mm, aspect ratio kept). It clearly implies a physical/plotted output versus the sibling preview_svg, but it never names an alternative to fully disambiguate the pair.

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?

Offers content-level guidance ('Line art works best; fills are not hatched'), which helps an agent choose suitable input. However, it gives no explicit when-to-use condition and never distinguishes itself from the sibling preview_svg or explains when to prepare a scene instead.

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

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

Annotations already declare the safety profile (readOnly=false, destructive=false, openWorld=true, idempotent=false), so the bar is lower. The description adds real behavioral detail (fonts weld into one stroke per word; speed controls pen-down step size), but says nothing about physical-plotter side effects, connection/auth requirements, or what happens to prior output.

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?

Front-loads the core action, then layers font advice, the scene alternative, and speed semantics. Dense but ordered; a couple of clauses (e.g. the G94 aside) are jargon-heavy for the value they add.

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 an 8-parameter tool with 0% schema coverage and no output schema, the description covers purpose, fonts, an alternative, and speed, but leaves order semantics and the auto-fit behavior of null w/h unexplained. Adequate but with clear gaps given the complexity.

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. It clarifies the box coordinates (x,y,w,h in mm) and the speed parameter ('G94 S, max step size for pen-down moves, 1..30'), and names good font values, but leaves `order` (default 'human') and the null w/h behavior entirely undocumented.

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?

States a specific verb and resource ('Write text with a single-stroke Hershey font') plus the operating constraint ('fitted into box (x,y,w,h) mm'). It also names the sibling alternatives (list_fonts, draw_scene), so an agent can distinguish this from preview_text/draw_scene without opening any schema.

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?

Gives concrete guidance: prefer handwriting faces for specific looks, and 'For multi-line or MULTI-FONT text prefer a scene: draw_scene' names the alternative and the condition that selects it. It stops short of explicit when-not-to-use exclusions, but the routing advice is actionable.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds useful behavior beyond that: the dual list/return mode and the fact that each scene carries a _comment explaining what made it work. No auth, rate-limit, or pagination details are given.

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?

Front-loaded with the resource and its dual behavior, then the workflow hint. The sentences are a little run-on with parenthetical asides, but each carries weight and nothing is redundant.

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 one-optional-parameter tool with no output schema, the description covers purpose, both invocation modes, the return content (_comment), and the follow-up workflow. Nothing an agent needs to call it correctly 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 description coverage is 0%, so the description must carry the parameter meaning, and it does: empty name lists, a name returns the scene. It even illustrates how to modify a returned scene. That compensates well for the undocumented `name` parameter.

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?

States a specific resource (worked example scenes) and a clear dual-mode behavior: no name lists them, a name returns the scene. It also names a sibling (preview_scene) as the downstream consumer, so an agent can place it in the workflow without opening the schema.

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?

Gives clear context for use: pull an example to preview as-is or to modify rather than starting from nothing, which is a genuine routing hint. It does not, however, state when to avoid this tool or contrast it with siblings like doodles or plan_scene.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and safe non-destructive behavior. The description adds nothing beyond the annotation title 'Drawing progress'—no return format, polling advice, or auth needs are disclosed. Minimal added value beyond structured metadata.

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 short phrase with no waste, but it is arguably too terse to be useful; it is front-loaded but lacks a clear action verb and structure. Not wasteful, but not well-structured for an agent to parse action and intent.

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 simple read tool with no output schema, the description should explain what 'progress' entails (e.g., status, percentage) and how to obtain job_id. It omits both, leaving key context missing and relying entirely on annotations and the parameter name.

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% and the description does not mention the required job_id parameter at all. It fails to clarify format, source, or constraints, leaving the single parameter undocumented beyond its self-explanatory name.

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 'Progress of a drawing job' implies the tool retrieves job progress, but uses a noun phrase with no explicit verb and does not differentiate from sibling 'get_status' which could also report status of an entity. It identifies the resource but lacks specificity about the action and scope.

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?

No guidance on when to use this tool versus alternatives like get_status or preview tools. It provides no context about prerequisites, polling behavior, or conditions for calling, leaving the agent to infer usage entirely.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety and repeat-call behavior are covered. The description adds real value by disclosing what the response contains (firmware banner, canvas size in mm, job info), which the annotations do not.

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?

A single front-loaded sentence listing the three returned artifacts, with zero filler or repetition of the tool name. Nothing could be cut without losing information.

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 parameters, the description carries the burden of telling the agent what comes back, and it does so for three of the likely fields. It stops short of full completeness because it doesn't indicate whether the payload is a fixed shape or what 'last job' means relative to get_job.

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?

The tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to disambiguate. No parameter-level claims are made or needed.

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 names the concrete payload (firmware banner, canvas size in mm, current/last job), which makes the tool's scope identifiable at a glance. It does not explicitly differentiate itself from the sibling get_job, even though 'current/last job' overlaps with that tool's territory, so it falls short of a 5.

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?

There is no statement of when to call this versus the alternatives; a reader must infer that this is the general status snapshot and get_job is the per-job detail call. No prerequisites or exclusions are given.

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

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

Annotations already declare the mutation/idempotent/non-destructive profile, so the safety burden is covered. The description adds one useful behavioral detail (the pen is lifted, so homing won't drag the pen across the work), but says nothing about whether the call blocks, how long it takes, or any connection prerequisites.

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?

A single compact sentence with the key action front-loaded. Every word earns its place and nothing is redundant.

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 zero-parameter action tool with no output schema, the description covers what the tool physically does. The main gap is the absence of any indication of when the agent should invoke it or what happens on completion, but the operation is simple enough that little more is strictly required.

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?

There are zero parameters and 100% schema coverage, so the baseline is 4. There is no parameter meaning the description could or should add.

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 states a specific verb (lift) and physical resource (the arm to its home position), which is distinctive against drawing siblings like draw_paths and preview_svg. It does not explicitly name an alternative, but the homing action is self-evidently distinct.

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 description never says when to call this tool, under what conditions the arm should be homed, or how it relates to siblings like abort or draw_paths. Usage must be inferred entirely from the action itself.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description adds real context: the two families, the license note for fonts/ (SIL OFL), and the three measurements (passes, aperture, joins) that appear in the results. It stops short of describing the literal return format or field order, but the semantic behavior is well disclosed.

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 front-loaded with the purpose sentence and organized into labeled blocks, which helps. But for a simple listing tool it is verbose, spending many lines on illustrative lore (a capital H in rowmant is 27 strokes; brush at 0.89 mm) that informs font choice rather than tool invocation.

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, the description carries the burden of describing results, and it does so semantically by naming the families and the three decision measurements an agent will see. Pagination, counts, or exact returned fields are not covered, but the agent has enough to call and interpret it.

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 0%, so the description must carry the parameter, and it does: it explains what include_hershey=true does (list the legacy Hershey faces) and pairs that with a concrete reason to avoid it. The default is left to the schema, which is fine.

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 opening sentence states the resource (typefaces/fonts) and ties it to the consuming tools (text, draw_text, a scene's "text" producer), so the agent knows this is the discovery step before drawing text. It is clear but does not explicitly differentiate itself from siblings like preview_text or get_example beyond the font-listing scope.

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?

Guidance is implied rather than explicit: it says handwriting faces are preferred and that include_hershey=true reveals the legacy set, which is useful selection advice. However, it never states plainly when to call this tool (e.g., before draw_text to discover valid font names) or why not to use include_hershey by default beyond the scribble warning.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context beyond the annotations: it clarifies that the tool compiles and reports cost without drawing or rendering, and it lists the exact output contents (counts, bounding box, travel, warnings).

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?

A single front-loaded sentence with no wasted words. The key constraint (no drawing/rendering) and the reported outputs are packed efficiently using a colon list.

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?

The description adequately covers the tool's purpose and output content even without an output schema, and annotations cover safety. However, the input scene parameter is a nested object with no schema description and the description provides no structural guidance, leaving a notable gap for an agent trying to construct a valid call.

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?

There is one required parameter named 'scene' with 0% schema description coverage and a nested object type, yet the description only repeats the word 'scene' from the tool name. No details about the scene structure, format, or required fields are provided, so it does not compensate for the schema's lack of parameter documentation.

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?

States the specific verb 'Compile' and resource 'scene', and explicitly distinguishes the operation from drawing/rendering siblings with 'WITHOUT drawing or rendering'. It also names the reported outputs (stroke/point counts, bounding box, pen-up travel, warnings), so an agent can tell it apart from draw_scene and preview_scene without opening the schemas.

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 description implies usage by saying it compiles and reports cost without drawing or rendering, which helps avoid using it when actual drawing is needed. However, it does not explicitly state when to choose this tool over siblings like preview_scene or draw_scene, nor does it name alternatives or prerequisites.

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

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds genuine value beyond them: it discloses what is returned (diagnostic view with pink pen-up travel, grey page box) and that simulate=true is the default that shows what the arm will actually draw.

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?

Two sentences, front-loaded with the core action and format before the return-value detail. Every clause earns its place with no filler.

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?

No output schema exists, so the description correctly explains the return (diagnostic view and simulation). It is sufficient for a read-only preview tool, though it omits details like units per segment beyond 'canvas mm' and whether the view is returned as an image or structure.

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 0%, so the description must carry parameter meaning, and it does: it documents the nested paths format ('canvas mm, [[[u,v], ...], ...]') and explains that simulate (default true) controls whether the simulated on-paper result is shown. This compensates well for the empty schema descriptions.

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?

States a specific verb+resource (render/preview polylines) and clarifies scope with 'without drawing', which distinguishes it from the draw_* siblings. The input format is also given inline. It stops short of naming the draw_paths alternative explicitly, but the intent is unambiguous.

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?

'Without drawing' implies this is the preview counterpart to draw_paths, so usage is inferable. However, there is no explicit when-to-use/when-not guidance or named alternative, leaving the agent to infer the preview-vs-draw choice.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds a genuine behavioral guarantee not in the annotations: the preview is a faithful stand-in for draw_scene output, and no drawing occurs. It also discloses the 'exactly one producer per shape' constraint. It does not explain the simulate flag or return delivery, so not a 5.

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?

Front-loaded with purpose and routing, then organized into producers/modifiers blocks that are easy to scan. It is long, and a couple of sentences (e.g. the rationale for having no shape catalogue) are more justification than instruction, but for a DSL this length is largely earned.

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?

No output schema exists, so the description carries return-value burden; 'Render ... as a PNG' states the artifact type but not how the image is delivered. The DSL surface is otherwise thoroughly specified. The undocumented 'simulate' flag is the main remaining hole.

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 0% and the scene object is undocumented in the schema, so the description must compensate — and it does so exhaustively, enumerating producers, modifiers, variables, functions, and constants with examples. However, the second parameter 'simulate' (default true) is never mentioned anywhere, leaving a real gap.

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?

States a specific verb and resource ('Render a declarative SCENE as a PNG without drawing') and immediately distinguishes itself from siblings preview_paths and draw_scene. An agent knows exactly what this does and how it differs from the drawing tools.

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?

Explicitly says 'Prefer this over preview_paths', gives the reason (scene ~50x smaller than compiled coordinates), and ties it to draw_scene ('draw_scene given the SAME scene provably draws what you previewed'). It also routes to doodles() first for doodle picks. Clear when-to-use and named alternatives.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: fills are ignored (strokes only), coordinates are in canvas mm, and the box defaults to the whole canvas. It omits any mention of what the simulate flag does.

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?

A single compact sentence with no waste, front-loading the render action and the strokes-only constraint. It could be shorter only by dropping genuinely useful detail.

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 readOnly/idempotent annotations and no output schema, the description correctly states the PNG return, so return handling is fine. However, the simulate parameter (default true) is never explained, and the svg input format is unspecified, leaving gaps an agent must guess at for a 6-parameter tool.

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 carry parameter meaning. It documents x,y,w,h as a fit box in canvas mm with a whole-canvas default, but says nothing about the required svg string's expected format or the simulate parameter at all, leaving two of six parameters uninterpretable.

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?

States a specific verb ("Render") and resource (SVG, paths/shapes) and declares the output (PNG), so the agent knows exactly what it produces. It does not explicitly distinguish itself from the sibling draw_svg, but the "preview" framing is implied by the render-only nature.

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?

Usage is only implied: rendering rather than committing, and returning a PNG, suggests a non-side-effecting preview as opposed to draw_svg. There is no explicit when-to-use/when-not statement or named alternative, leaving the agent to infer the preview-vs-draw split from the name alone.

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

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

Annotations already establish readOnly/idempotent/non-destructive, so the bar is lower. The description adds real context beyond that: box-fitting in mm, '\n' newline semantics, and the caveat that most Hershey names retrace every stem. It stops short of saying what the preview output actually looks like.

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?

Front-loaded with the core operation, then the operational details. The font enumeration is somewhat long but is high-value content rather than filler, so waste is minimal.

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?

Adequate for a preview tool with no output schema, but incomplete: 7 parameters at 0% schema coverage means the description should clarify at least simulate and the optional box coordinates, and it does neither. An agent still has open questions about what the call returns.

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 0%, so the description carries the burden, and it does explain the box semantics (x,y,w,h in mm) and newline handling for text. However, font is only hinted at via face names, and the defaulted simulate flag plus the null-default nature of x/y/w/h are never explained.

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?

States a specific verb+resource ("Render single-stroke (Hershey) text fitted into box") and clarifies units (mm) and newline handling. It does not, however, distinguish itself from the sibling draw_text, leaving the preview-vs-draw distinction to inference.

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?

Gives concrete guidance on font selection (prefer handwriting faces, with named examples) and points to list_fonts() for measurements, which is useful. But it never says when to choose preview_text over the sibling draw_text or preview_svg, and the simulate parameter's role is left unaddressed.

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