CursiveLines

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds that results are a scrollable gallery with specimen images, which is genuinely useful context, but it says nothing about paging behavior or result ordering beyond what the schema's cursor parameter implies.

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 filler or redundancy. The only slightly decorative phrase is 'scrollable gallery', which is minor and arguably communicates the UI affordance.

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 rich annotations, full schema coverage, and an output schema handling return values, the description only needs to establish purpose and scope, which it does. The remaining gap is the lack of sibling differentiation among seven related tools, which an agent would have to resolve by opening other definitions.

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 100%, with every parameter documented including the enum values for category and the default page size. The description restates that browsing is by name and category, adding no syntax, format, or edge-case detail beyond the schema, 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?

States a specific verb and resource: shows a gallery of famous signatures from the CursiveLines collection, with search and category filtering. It is clear what the tool returns (specimen images), though it never names a sibling such as find_handwriting to sharpen the boundary between browsing and searching.

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 word 'browse' plus 'searchable by name and filterable by category' implies a discovery use case, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative sibling tool. An agent must infer that this is the exploratory option rather than the targeted-lookup one.

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, non-destructive and closed-world, so the safety profile is covered. The description adds useful behavioral context beyond that: the result is a side-by-side rendering across five named styles, each with stroke playback. It does not discuss output format details, but an output schema exists to carry those.

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 well-formed sentence that front-loads the core action and enumerates the styles compactly. There is no redundant or filler wording, and every clause carries 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?

For a read-only tool with one optional, fully documented parameter and an existing output schema, the description supplies enough context to call it correctly. Minor gaps remain around what exactly playback looks like, but the output schema and annotations fill the rest.

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 100%, and the schema already documents the 12-character limit, pattern, and default of "Aa". The description restates 'one letter or a short word' without adding syntax or format details beyond the schema, so the baseline of 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 states a concrete verb and resource ('Shows one letter or a short word in all five cursive styles side by side') and enumerates the five styles, so the agent knows exactly what the tool produces. It does not explicitly name how it differs from siblings like show_letter or show_alphabet, but 'all five styles side by side' implicitly distinguishes it as the comparison view.

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 comparison framing implies when to reach for it (to contrast styles for a given letter), but there is no explicit when-to-use or when-not guidance and no sibling is named as an alternative. The agent must infer that show_letter is for a single style while this is for the multi-style view.

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, destructiveHint=false and openWorldHint=false, so the safety and determinism profile is fully covered. The description adds only that results come back as 'pages with thumbnails', which is largely redundant with the existing output schema and says nothing about pagination behavior or result limits.

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 well-formed sentence with the action and resource front-loaded and no filler. The trailing return-value clause is the one mildly expendable element given the output schema exists.

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?

All four parameters are required-free and fully documented, an output schema covers return values, and annotations cover the safety profile, so an agent has enough to call this correctly. The only shortfall is the absence of any routing hint among the many similarly named sibling tools.

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 100%, so every parameter (query, cursor, category, pageSize) is already documented in the input schema. The description echoes the query dimension ('letter, topic or practice task') but adds no syntax, matching behavior, or combination rules beyond that. Baseline 3 applies when the schema does the heavy lifting.

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 gives a specific verb plus resource — 'Searches the CursiveLines handwriting lessons and guides' — and enumerates the searchable dimensions (letter, topic, practice task). It is clearly distinct from sibling tools like generate_signature or make_worksheet, though it never names a sibling explicitly.

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 implied by the phrasing 'by letter, topic or practice task', which hints at search-style retrieval as opposed to the direct lookups offered by show_letter or show_alphabet. However, there is no explicit statement of when to choose this over those siblings, and no exclusion 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 read-only and idempotent annotations, it discloses the concrete workflow: multiple style ideas with advice, famous-signature styles, and a generator opened with the name and style prefilled for PNG/SVG export. The phrase "where the PNG and SVG download" leaves unclear whether downloading is automatic or merely available through the generator.

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 compact sentences front-load the action and then describe the style content and export handoff with little redundancy. The final clause is grammatically awkward and ambiguous, which slightly reduces clarity.

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 two-parameter tool with safety annotations and an output schema, the description adequately covers the generated content and external generator workflow. It would be more complete with explicit sibling-selection guidance and a clearer statement of how downloads are delivered.

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%, including the name constraint and the meanings and default of the format enum. The description reinforces that the name is carried into the generator but adds no parameter guidance beyond the schema, so the baseline score 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 gives a specific action and resource: writing a name in CursiveLines signature styles, including six advised ideas and famous-signature handwriting styles. The prefilled generator and PNG/SVG workflow distinguish it practically from browsing or comparing signatures, although no sibling is explicitly named.

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 implied for someone seeking styled signature ideas and downloadable PNG/SVG results. There is no explicit when-to-use guidance or direction to alternatives such as browse_signatures or compare_styles when the user is still exploring options.

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 state readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds that this is a preview plus a site-side PDF download, which is useful context, but it does not say what happens when both text and preset are supplied, nor how many pages/preview images come back.

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 that names the resource first and then the options; nothing is redundant. The trailing 'with a PDF download from the site' clause is slightly tacked on but does add 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?

All seven parameters are optional and fully documented in the schema, and an output schema exists so return values need not be explained. However, the relationship between the text and preset parameters and the distinction from practice_handwriting are left unaddressed, which matters for correct invocation.

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 every parameter is documented with its default and enum values, so the schema carries the semantics. The description only restates the parameter list ('alphabet, style, paper size, guide and repeat count') without adding precedence rules or format details beyond 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 description uses a specific verb and resource ('Previews the printable practice sheet pages') and enumerates the dimensions of the sheet (alphabet, style, paper, guide, repeats) plus a PDF download. It is clear what the tool produces, though it never distinguishes itself from the sibling practice_handwriting, which plausibly overlaps.

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 phrase 'for a text or a practice preset' hints at two alternative input modes, but there is no guidance on when to use this versus practice_handwriting or show_alphabet, and no statement about whether text and preset are mutually exclusive or which wins.

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 and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses what the practice surface contains (scrollable lane, guide, stroke playback, trace pad, score), which tells the agent what to expect from invoking it. No mention of what happens if both text and preset are supplied.

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 action and followed by the input modes; no filler. The UI inventory in the first sentence is dense but each element informs the agent about the returned surface.

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 5 optional parameters, full schema coverage and an output schema, the description is close to sufficient. Minor gaps remain around precedence between text and preset and around how guide/style/alphabet combine, but the core call path is clear.

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 a 3 is the baseline, but the description earns a point by expanding 'practice preset id' into concrete examples (everyday words, loops and joins, numbers, lesson exercise, kids size set) that the schema does not provide. It does not explain how text and preset interact when both are given.

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: 'Opens the one-lane handwriting practice' with the text lane, guide, stroke playback, trace pad and score. The adjective 'one-lane' implicitly separates it from the worksheet sibling, but no sibling is named explicitly, so differentiation is left 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?

Usage is implied rather than stated: 'one-lane' plus 'custom text or a practice preset id' suggests single-user interactive practice rather than a printable worksheet, but the description never says when to pick this over make_worksheet or show_letter, and gives no exclusions 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 declare readOnlyHint, idempotentHint, non-destructive behavior, and a closed-world scope. The description adds useful context beyond that by naming the printable alphabet sheet and clarifying that print ignores the cursive style setting.

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 front-loaded sentence with no filler. It packs in the scope, style options, letter coverage, and printable output, though the phrasing is slightly run-on.

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 an output schema present and annotations covering safety and idempotency, the description supplies enough detail for correct invocation. It could be strengthened by relating the tool to its siblings, but 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%, and both parameters have enum descriptions, so the schema already explains the style and alphabet choices. The description reinforces that there are five styles and a print option, but adds no syntax or default details beyond 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 description states a specific verb and resource: it shows a full A-to-Z chart, with capitals and small letters, in one of five cursive styles or print, plus a printable alphabet sheet. This clearly distinguishes it from show_letter, which presumably shows a single letter.

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 shows the full alphabet rather than a single letter, but it does not explicitly name alternatives such as show_letter or compare_styles, nor does it state when not to use this 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 readOnly, idempotent, non-destructive, closed-world behavior, while the description adds substantive output context: capital and small forms, numbered pen strokes, direction arrows, stroke playback, trace scoring, printable sheet, and style support. It does not contradict the annotations.

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 no filler. The feature list is dense but useful, and every phrase contributes to what the agent should expect.

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 single-letter display tool, the description plus 100% schema coverage, rich annotations, and an output schema provide enough to call it correctly. It could be stronger by stating when to choose it over show_alphabet or practice_handwriting.

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 the style/alphabet enum meanings, defaults, and print/cursive relationship are already documented in the input schema. The description only lightly confirms "five styles or print" without adding format or interaction details beyond the schema, so 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, "Shows," and resource, "one letter," and enumerates capital/small forms, stroke annotations, playback, tracing, and printable sheet. It is clear, but it does not explicitly name a sibling such as show_alphabet or practice_handwriting to distinguish overlapping cases.

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 implies the use case of viewing a single letter with instructional strokes, but gives no explicit when-to-use or when-not-to-use guidance. The agent must infer its boundary from "one letter" and the listed features without any named alternatives.

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