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

With no annotations provided, the description carries the full burden and handles it well. It discloses that the tool returns a formatted markdown report, does not modify glyph colors by default, and only colors glyphs when mark_glyphs=True. It also clarifies the cross-master behavior of master_id. This is transparent about side effects and scope.

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 appropriately detailed for a complex analysis tool. It is front-loaded with the core purpose, then uses a bulleted list for checks and a compact Args section. Every sentence earns its place, including the recipe pointer and side-effect note.

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?

Given the tool has no annotations and multiple behavioral nuances, the description covers the key aspects: input parameters, side effects, checks performed, and return format. An output schema exists, so not detailing the full report fields is acceptable. Minor gaps remain, such as not mentioning whether the analysis requires any permissions or what 'verdict' precisely means, but overall it is complete enough 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 description coverage is 0%, so the description must compensate for the bare schema. It does: master_id is explained as optional with cross-master checks always running across all masters, and mark_glyphs is explained as coloring glyphs by verdict only when explicitly requested. This adds real meaning beyond the schema's titles and defaults.

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: 'Analyze kerning quality across all masters.' It enumerates exactly what checks are performed (missing pairs, sign changes, outliers, redundant exceptions, group orphans). However, it does not explicitly differentiate itself from the nearby sibling analyze_kerning_groups, which could overlap on the group-orphans check.

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 gives useful context: for kerning from scratch, call get_recipe('kerning_from_scratch') first, which implies this tool is for analyzing existing kerning rather than creating it. However, it does not explicitly state when to use this tool versus alternatives like analyze_kerning_groups or get_kerning, and there are no clear exclusion conditions.

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?

With no annotations to rely on, the description carries the full burden and succeeds: it discloses destructive behavior ('overwriting any existing values'), the five-tier resolution strategy, group-naming conventions, and the fact that glyph colors are not modified by default. These are exactly the behavioral traits an agent needs before invoking the 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 description is longer than average, but it is organized into clear sections (recipe, strategy, naming, args) and most sentences carry decision-relevant information. The front-loaded purpose and the strategy list are appropriate; only the detailed group-name examples add slight optionality rather than necessity.

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?

Given the tool's complexity and zero annotation coverage, the description covers purpose, side effects, algorithm, parameter semantics, and usage conditions. An output schema exists, so not detailing return values is acceptable; nothing essential for selecting or calling this tool 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 fully compensate. It does: each of the four parameters is explained with its default and effect, including the dry-run behavior of apply, the empty-slot-only behavior of overwrite, and the explicit-request condition for mark_glyphs.

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: 'Analyze and assign kerning groups to all glyphs.' It clearly states the tool's scope (all glyphs) and names its core behavior, but it does not explicitly differentiate itself from sibling tools such as analyze_kerning or auto_kern.

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 gives helpful context (recipe first, mark_glyphs only on explicit request, apply as dry run), but it does not state when to choose this tool over alternatives like analyze_kerning or auto_kern, nor does it mention exclusions.

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?

With no annotations provided, the description carries the full burden and does so well. It explicitly states 'Does not modify glyph colors by default' and explains the conditional mark_glyphs behavior with color verdicts. It also discloses the algorithm's scope (scanline ray-casting, consistency checks) and the naming convention for exceptions, making side effects and behavior clear.

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 well-structured: a concise opener, a recipe pointer, a coherent bulleted list of checks, and a side-effect note before Args. It is front-loaded and scannable, but the mark_glyphs behavior is somewhat redundantly stated both in the prose and in the Args section, costing full efficiency.

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 complex analysis tool with no annotations and zero schema coverage, the description is remarkably complete. It covers the recipe prerequisite, measurement methodology, all parameter meanings, and the conditional side effect of color marking. Since an output schema exists, return-value documentation is not required 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 description coverage is 0%, so the description must compensate, and it does. Each parameter is explained: master_id defaults to all masters when empty, glyph_names defaults to all Letter glyphs, and mark_glyphs is described as applying verdict colors only when explicitly requested. This adds meaningful semantics beyond the raw 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 opens with a specific verb and resource: 'Analyze spacing quality across all masters.' It then enumerates concrete checks (sidebearing group consistency, Tracy/Smith rules, counter-based validation, cross-master drift) that clearly distinguish it from sibling tools like analyze_kerning or measure_stems. The scope and method are 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?

The 'RECIPE' section explicitly recommends calling get_recipe("spacing_workflow") first for systematic spacing work, giving clear context for when this tool fits into a workflow. However, it does not state when not to use it or compare it directly with sibling analysis tools such as analyze_kerning, so it falls short of full 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?

With no annotations provided, the description carries the full burden, and it does well: it explicitly states that it does not modify glyph colors by default, that mark_glyphs should only be set when the user explicitly asks, and that omitting master_id means analyzing all masters with worst-verdict-wins logic. This meaningfully discloses side effects and aggregation behavior.

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 front-loaded with the main purpose and remains mostly efficient. Minor extras like the RECIPE line and the specific density ratio range add useful context but could be tightened without losing the core message.

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 is complete for a two-parameter audit tool: it covers purpose, grouping logic, side effects, master selection, and usage timing. Since an output schema exists, not detailing return values is acceptable. It could be slightly stronger with explicit guidance on choosing among the many sibling audit/measure 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 0%, so the description must fully compensate. It explains both parameters: master_id as optional with 'empty = all masters', and mark_glyphs as a conditional flag that colors glyphs by verdict only when explicitly requested. This adds behavioral meaning well beyond the raw schema defaults.

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 clearly states a specific operation: a full font color audit that analyzes all letter glyphs grouped into uppercase, lowercase, and figures and evaluates them against expected density ratios. It positions itself as the comprehensive 'is my font's color even?' check, which helps distinguish it from more narrow metrics tools, though it does not explicitly name or differentiate from related siblings like measure_color or compare_color.

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 gives clear usage context: use before final production to catch weight inconsistencies, and follow a specific recipe for a full consistency audit. It also explains when mark_glyphs should be true, but it does not explicitly say when to prefer a sibling tool 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?

With no annotations, the description carries the full burden. It discloses the algorithm (ray-casting, trapezoidal weighting), auto-calibration behavior from nn/HH, the default overwrite=False safety behavior, dry_run preview mode, and the effect of use_groups. It doesn't explicitly state that existing kerning is preserved by default or what happens on conflict, but the overwrite parameter and dry_run are disclosed. Minor gap: no mention of side effects on group kerning or master_id behavior, but the description is rich.

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 long but earns its length: algorithm explanation, workflow, and per-parameter semantics. It is front-loaded with the core purpose and algorithm, then workflow, then args. Slight redundancy (workflow steps repeat pairs modes already in Args) but not wasteful. A 4 because it's dense and well-organized, though a bit long.

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 complex 12-parameter tool with no annotations and 0% schema coverage, the description covers algorithm, calibration, workflow, parameter semantics, and safety (dry_run, overwrite). The output schema exists, so return values need not be described. Nothing critical is missing for an agent to select and invoke this tool 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?

Schema description coverage is 0%, so the description must fully compensate. It does: every parameter is explained with its mode, meaning, default, and often examples ('critical' — ~75 essential pairs, 'explicit' — use pairs_list, area — None = auto-calibrate from nn/HH). This is exactly what an agent needs to construct correct arguments.

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: 'Auto-kern glyph pairs using optical gap analysis (MB LetterKerner algorithm).' It clearly distinguishes this from sibling tools like set_kerning_pair (manual single pair) and analyze_kerning (verification) by describing the algorithm and workflow. The purpose is unmistakable.

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 provides an explicit 6-step recommended workflow, including when to use dry_run, when to use 'critical' vs 'auto' pairs, and prerequisites (finalize spacing, assign kerning groups). It also names the verification sibling (analyze_kerning) and the group-assignment sibling (analyze_kerning_groups). This is exemplary usage 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?

No annotations are provided, but the description discloses that it does NOT modify glyph colors by default, and only marks when mark_glyphs=True. It explains the color coding (red, orange, green). This is strong for an unannotated tool, though it could mention side effects on glyph colors more prominently.

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 well-structured with a recipe hint, a detailed but bulleted list of checks, and a clear args section. It is front-loaded with the main purpose and recipe. Every sentence adds value; no fluff.

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 (indicated in context), the description doesn't need to explain return values. It covers the main checks, the side-effect behavior, and the recipe. For a checking tool with two optional params, this is complete.

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 has 0% description coverage, but the description explains glyph_names (optional list of glyphs, default all) and mark_glyphs (color by verdict only when requested). This adds meaning beyond the schema, though it doesn't specify the format of glyph_names (list of strings) which is clear from 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 clearly states it checks master compatibility across all glyphs, listing specific checks (paths, components, anchors) and verdict meanings (red, orange, green). This distinguishes it from related tools like analyze_kerning or check_overshoots.

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 an explicit recipe: call get_recipe('master_compatibility') first for a complete pre-export check. This is a clear when-to-use instruction and references a specific alternative workflow. It also explains when mark_glyphs should be used, clarifying the default behavior.

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?

With no annotations provided, the description carries the full behavioral burden. It clearly states that glyph colors are not modified by default, and only marks colors when mark_glyphs=True, specifying the color scheme (red/yellow/green). It also discloses the default scope for master_id and glyph_names. This is transparent about side effects. It does not mention whether the operation is read-only or if it returns a report, but the existence of an output schema covers that. Slightly more could be said about error behavior or non-mutating nature, but it's well above average.

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 well-structured: a one-line summary, followed by a detailed breakdown of what is measured and checked, then default behaviors, then side-effect disclosure, and finally an Args section. The information is front-loaded with the core purpose. It is slightly longer than necessary but every sentence adds value; no filler or tautology.

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 check tool with an output schema (which presumably defines the return format), the description covers the essential aspects: the checks performed, the glyph scope, the master scope, and the marking behavior. It does not describe the exact output structure (left to schema) nor discuss performance or edge cases like empty results, but given the complexity and that all parameters are optional, the description is sufficiently complete for an agent 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?

Schema coverage is 0%, so the description must fully compensate. It does so with an explicit Args section explaining each parameter: glyph_names (optional list, defaults to all), master_id (empty = all masters), mark_glyphs (colors only when explicitly requested). It also adds meaning beyond the schema by explaining the effect of each parameter and the defaults. This is exemplary compensation for a sparse 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 opens with a clear, specific statement: 'Check diagonal stroke weight consistency and ratio to vertical stems.' It enumerates the exact glyph set (V, A, W, X, Y, Z, etc.) and defines the two checks (consistency of related groups, ratio within professional range). This clearly distinguishes it from sibling check tools like check_overshoots or check_related_forms, which focus on different aspects. The purpose 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?

The description explains the default behavior when parameters are omitted (checks all diagonal glyphs, analyzes all masters) but does not explicitly guide when to use this tool versus alternatives. With 50+ sibling tools, many of which are also checks, the absence of any 'use this instead of X' or 'when not to use' guidance is a notable gap. The defaults are useful context but not full usage differentiation.

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?

With no annotations provided, the description carries the full behavioral disclosure burden. It states that the tool queries a public API and returns match counts, trademark info, review status, timestamp, and a link. It also discloses the important 'not legal clearance' caveat, giving the agent a realistic sense of what the operation does and does not guarantee.

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 efficiently structured: a one-sentence summary, a concise explanation of the query and returned data, a crucial caveat, and a single-argument Args section. Every sentence adds value and is front-loaded with the core purpose.

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-parameter external lookup tool with no annotations and no output schema, the description covers the essential behavioral, return-value, and parameter semantics. It could go slightly further by noting external API dependencies or potential failure modes, but the agent has enough information to invoke the tool correctly and interpret its result.

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 input schema only says 'name' is a string, with no description, so the schema coverage is 0%. The description compensates fully by defining the parameter: 'Proposed typeface family name to check.' This is exactly the semantic context an agent needs to supply the correct value.

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 'Screen one proposed typeface family name for known collisions,' which names a specific verb, resource, and goal. It clearly differentiates this tool from sibling checking tools like check_language_support and check_glyphset_coverage, which target different font properties.

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 conveys a clear usage context: use this to screen a typeface name before relying on it. It also provides an explicit limitation ('not legal clearance') and warns that no match does not guarantee availability, though it does not name a specific sibling alternative or define when-not-to-use conditions beyond that.

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?

With no annotations, the description carries full behavioral burden. It discloses the tool's dual behavior (listing vs. checking) and explains that add_missing=True creates empty glyphs marked with blue color label. It implies read-only behavior when add_missing is false (reports), and clearly indicates modification when true. It doesn't mention edge cases (invalid glyphset names, effect on existing glyphs) but covers the core behaviors adequately for a font-checking 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 description is well-structured: a concise opening sentence stating the core function, followed by a short explanation of modes, then an Args section with detailed parameter explanations. It includes examples that are helpful but not excessive. While it is somewhat lengthy, every sentence adds value—the examples clarify shortcuts and the add_missing effect is necessary. It's appropriately front-loaded with the main purpose first.

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 tool with 2 optional parameters and an output schema (not shown but implied), the description is complete. It covers both parameter semantics, the two operational modes, and the side effect of add_missing. It explains what the tool returns (which glyphs are present/missing) and how to list all glyphsets. No critical information is missing for an agent to call 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?

Schema description coverage is 0%, so the description must fully compensate. It does so excellently: the glyphset parameter is explained with concrete examples and shortcuts (GF_Latin_Core, latin_core, latin_all, cyrillic_core, etc.), and add_missing is described with its effect and visual marker. This adds substantial meaning beyond the bare schema types and defaults, making it easy for an agent to select correct values.

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 clearly states the tool's purpose: checking font coverage against Google Fonts glyphset definitions. It distinguishes between two modes (listing all glyphsets vs. checking a specific one) and explicitly names the action (reports present/missing, optionally adds missing glyphs). This is a specific verb+resource that separates it from sibling tools like check_language_support or check_overshoots.

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 provides clear usage context: 'With no arguments, lists all available glyphsets. With a glyphset name, reports which glyphs are present and which are missing.' It also explains the optional add_missing parameter. It does not explicitly state when NOT to use this tool or mention alternatives, but the function is unambiguous and the context signals (e.g., no other tool checks glyph coverage) make the usage obvious. It lacks explicit exclusions but is still clear.

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?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses the measurement mechanism, the interpretation of thinning percentages, the grouping logic, the all-masters default when master_id is omitted, and the important side-effect behavior: colors are not modified by default, but mark_glyphs=True marks glyphs red/green. This is exemplary transparency for a tool with no 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?

The description is well front-loaded with the purpose and metric definition, and the structured Args section is easy to parse. It loses a point because some information is repeated: 'If master_id is omitted, analyzes ALL masters' duplicates the Args line 'empty = all masters', and the mark_glyphs color behavior is stated twice. Still, every section earns its place overall.

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 tool has three optional parameters, no required inputs, an output schema, and moderate complexity. The description covers default glyph lists, default master behavior, the meaning of the reported percentage, consistency-group semantics, the absolute-value exclusion, and the color side effect. Nothing an agent needs to decide whether and how to call this tool 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 fully explain the parameters, and it does. The Args section spells out glyph_names default values, master_id's empty-means-all-masters semantics, and mark_glyphs' verdict-coloring effect. This fully compensates for the schema's lack of property 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?

The description opens with a specific verb and resource: 'Check junction thinning consistency across related glyphs.' It then concretely explains the measurement technique (horizontal rays at multiple heights), the metric (thinning %), and the comparison groups (n≈m, b≈p, d≈q), making its scope unmistakable and distinct from siblings like measure_stems or check_related_forms.

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 gives clear when-not guidance: it 'Does NOT flag based on absolute values' and 'Only flags inconsistencies between related forms,' which tells an agent when this tool is appropriate. It also explains master_id default behavior. However, it does not explicitly name alternative sibling tools such as measure_stems or compare_stems, so the routing guidance is strong but not fully explicit.

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?

No annotations are provided, so the description carries the full burden. It discloses that it 'Exports a temporary binary from the active Glyphs font' and runs Shaperglot, which is a side effect. It also describes the two output modes. However, it does not explicitly state whether the tool modifies the font or is read-only, nor does it mention any permissions or rate limits. The temporary binary disclosure is useful, but more detail on side effects would be expected for a tool with zero annotation coverage.

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 well-structured: a one-sentence purpose, a two-sentence process explanation, and a bulleted Args section. It is front-loaded with the purpose and the key behavior. It is not overly verbose; every sentence contributes to understanding. The structure is clean and scannable, earning a high score for conciseness.

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?

Given the tool's complexity (5 parameters, no annotations, output schema present), the description is quite complete. It explains the process (temp export, Shaperglot run), the two modes, and parameter details. It does not explain return values, but the output schema exists, so that is acceptable. It covers prerequisites implicitly (open font) and describes the threshold behavior. Minor gaps include potential error handling and installation requirements, but these are not critical for basic usage.

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 does so with an Args section that explains each of the 5 parameters: languages, instance_name, export_format, support_threshold, and max_results. It provides types, defaults, and examples (e.g., 'en_Latn', 'Turkish', 'Navajo'). This adds meaning beyond the schema, though some parameters like support_threshold and max_results could use more context about how they affect the output. Overall, the description effectively documents the parameters.

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 clear verb+resource: 'Check the open font's language support with Shaperglot.' It is specific about the tool's purpose and mentions the underlying mechanism (Shaperglot). It does not explicitly differentiate from sibling check tools like check_glyphset_coverage, but the unique focus on language support is evident. The description distinguishes between two modes (with/without languages), adding clarity.

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 explains what the tool does and how it behaves in two modes, but it does not provide explicit guidance on when to use this tool versus alternatives, nor any exclusions. Usage is implied by the purpose ('check language support'), but there is no mention of alternatives or when not to use it. This leaves the agent to infer context from the tool name and siblings.

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?

With no annotations, the description carries the full disclosure burden and meets it: it states the default scope, default master behavior, that glyph colors are not modified unless mark_glyphs=True, and the exact color side effect when requested. It also reveals the 1-2% zone-height threshold and the pointed-form exception, which are not inferable from schema or 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?

The description is longer than average but well structured with RECIPE, quality criteria, defaults, side effects, and an Args section, so no major filler exists. It could be tightened, but every section earns its place.

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 3-optional-parameter analysis tool with no annotations but with an output schema, the description covers invocation defaults, side effects, scope, and evaluation criteria. Nothing needed to call it correctly appears to be 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 Args section is the only semantic source for the parameters. It explains glyph_names, master_id, and mark_glyphs with defaults and behavioral consequences, fully compensating for the bare input 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 opens with a specific verb and object, 'Check overshoot values', which clearly separates it from sibling checks like check_compatibility, check_junctions, and check_related_forms. It further defines the resource by naming round and pointed form categories and giving the optical criteria used.

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 RECIPE line explicitly frames this as a pre-export check within the get_recipe('master_compatibility') workflow, and the defaults sections tell the agent when all glyphs and all masters are included. It does not explicitly list when-not-to-use conditions or alternative check_* tools, so it stops short of a perfect 5.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that pairs with missing glyphs are skipped, all masters are analyzed when master_id is omitted, and that glyph colors are not modified unless mark_glyphs=True, with specific color verdicts. This is transparent about side effects and defaults.

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 well-structured: purpose is front-loaded, checks are organized into clear bullet lists, and an Args section closes it out. The length is justified by the detailed check criteria, but it is slightly long relative to simpler tools.

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 is complete for a read-only check tool: it covers defaults, side effects, the missing-glyph edge case, and parameter semantics. An output schema exists, so explaining return values is unnecessary.

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?

Since schema description coverage is 0%, the description must compensate, and it does thoroughly. It explains that master_id is optional with an empty value meaning all masters, and that mark_glyphs only colors glyphs when explicitly requested. This adds significant meaning beyond the schema's type and default declarations.

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 ('Check') and resource ('punctuation consistency'), and then details the exact checks performed: mirrored pairs, width matches, and ratio checks. This clearly delineates it from sibling analysis tools like check_compatibility or check_overshoots by focusing on a distinct domain.

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 offers no guidance on when to use this tool compared to its siblings. The only usage-related note is the default behavior for master_id, but there is no mention of alternatives, exclusions, or conditions that would make this tool preferable.

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?

With no annotations present, the description carries the full behavioral burden. It does well by explicitly stating that glyph colors are not modified by default and that mark_glyphs=True is required for color marking. It also discloses the default all-masters scope, giving agents a clear picture of the tool's side effects.

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 well-organized with a clear opening, bulleted pair rules, and an Args section. There is minor redundancy: the all-masters behavior and mark_glyphs color behavior are each stated twice. Overall, it is appropriately sized for the tool's complexity and front-loads the core purpose.

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 two-parameter analysis tool with an output schema present, the description is complete. It covers purpose, parameter semantics, default scope, and mutation behavior. Return values are covered by the output schema, so no additional return-format detail is necessary.

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%, but the description fully compensates by explaining both parameters: master_id is optional with empty meaning all masters, and mark_glyphs only colors glyphs when explicitly requested. This provides meaningful semantics beyond the raw schema types and defaults.

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: 'Cross-validate related figures and letters,' immediately establishing what the tool does. It then lists precise pair rules (six ≈ nine, zero < O, etc.), which clearly differentiates it from generic sibling checks like compare_proportions or check_compatibility.

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 gives clear contextual guidance by enumerating exactly which width-ratio relationships are checked and noting that omitting master_id analyzes all masters. It does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5, but the intended use case is clear.

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?

With no annotations, the description fully carries the burden of behavioral disclosure. It clearly states that the tool does not modify glyph colors by default, and describes exactly what happens when mark_glyphs=True (verdict-based color assignments). It also explains the verdict categories and per-master aggregation behavior, leaving no ambiguities about side effects or output 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?

The description is structured front-loaded with the core purpose, then a recipe reference, then detailed behavior, then arguments, then a concrete example. No sentence is wasted; even the example adds clarity. Despite length, every part earns its place, and the structure aids quick scanning.

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?

Given the output schema exists (the tool returns per-glyph verdicts, though not detailed in the description), the description still covers all input parameters, default behaviors, side effects, and provides an example. It even references a recipe for a broader audit. Nothing an agent needs to call this 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 coverage is 0%, so the description must compensate, and it does. Each argument is explained: glyph_names (list of glyphs), master_id (optional, empty = all masters), mark_glyphs (boolean, only colors when explicitly requested). This goes beyond the schema's raw types and defaults, providing actionable meaning.

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 precise verb ('Compare') and resource ('typographic color / ink density across multiple glyphs'), and the example question clarifies its scope. It clearly differentiates from sibling tools like compare_stems (which compares stem weights) by focusing on ink density. The purpose is specific and 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?

The description provides an explicit alternative for a broader audit via the RECIPE line ('For a full consistency audit, follow get_recipe("audit_consistency")'), and explains the behavior when master_id is omitted (analyzes all masters). The example question demonstrates a typical usage case, giving the agent clear context on when to invoke 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?

With no annotations, the description carries the behavioral burden. It explicitly discloses side effects: 'Does not modify glyph colors by default' and what happens when mark_glyphs=True. It also surfaces default scope behaviors that are not visible from the schema alone.

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 well-structured and front-loaded with the core purpose. The recipe note, numbered checks, defaults, and side-effect disclosure each earn their place, and bullet-like formatting keeps it scannable.

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 moderately complex comparison tool with no annotations, the description covers scope, defaults, side effects, and the exact categories being checked. Since an output schema exists, return-value details are not required in the description.

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, and it does. All three parameters are explained with defaults and conditions: glyph_names, master_id (empty means all masters), and mark_glyphs (only colors when explicitly requested). This adds real meaning beyond the bare input 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?

States a specific verb and resource: 'Compare width proportions across glyphs within a font.' It then enumerates three concrete check categories, which clearly distinguishes it from sibling tools like compare_stems or check_related_forms even though they are not 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?

Provides clear context by pointing to get_recipe('audit_consistency') for a full audit, implying this tool is for targeted proportion checks. It also specifies default behavior for missing glyph_names and master_id, giving an agent practical invocation 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?

With no annotations, the description carries the full burden, and it delivers: it explicitly states that glyph colors are not modified by default, describes the exact color meaning of each verdict, explains per-master vs. all-master behavior, and clarifies that mark_glyphs only colorizes when explicitly requested. This is unusually transparent about side effects.

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 long but well-structured with labeled sections (RECIPE, verdicts, groups, master behavior, color behavior). Every major block earns its place for a fairly complex analysis tool; the glyph-class enumeration is detailed but useful. It is slightly longer than strictly necessary, so not a 5.

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?

Given that an output schema exists, return-value documentation is not needed. The description covers inputs, output semantics via verdicts and per-master results, side effects, and the recommended recipe path. An agent has everything needed to select and invoke this tool 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?

Schema description coverage is 0%, so the description must compensate—and it does thoroughly. It explains glyph_names as the list to compare, master_id as optional (empty = all masters), and mark_glyphs as the explicit color-marking switch. This gives agents full semantic understanding beyond the raw JSON 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 opening line states a specific verb and resource: 'Compare stem thicknesses across multiple glyphs to find inconsistencies.' This clearly differentiates it from measurement-only or single-glyph tools, and the detailed verdict/group taxonomy reinforces what the tool produces.

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 explicitly recommends get_recipe('audit_consistency') for a full font audit, giving agents a clear alternative workflow. It also explains when to use master_id vs. omitting it. It stops short of naming sibling tools like measure_stems and saying 'use this instead of that,' but the recipe pointer and mode behavior provide solid 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?

No annotations are provided, so the description carries full responsibility. It states the creation action but omits side effects such as behavior on duplicate glyph names, whether the new glyph becomes selected, reversibility, or prerequisites beyond an open font. For a mutation tool, this is a significant gap.

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 compact and well-structured with an 'Args:' list. Each parameter is on its own line with a concise explanation. The purpose is front-loaded, and there is no redundant fluff.

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 tool has no output schema, so the description should explain return values or error conditions. It does not mention what happens on success, what errors may occur (e.g., duplicate name), or if the glyph is selected after creation. While the essential creation action is covered, several operational details that an agent would benefit from are 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%, and the description compensates well. It explains each parameter with examples ('a.ss01', 'uni0041'), units ('font units'), and clarifies that 'paths' uses the same format as set_glyph_paths. This adds meaning far beyond the bare schema types and defaults.

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 clearly states the verb ('Create') and resource ('a new glyph') in the context of 'the open font', which distinguishes it from sibling operations like delete, rename, or duplicate. The purpose is unambiguous and specific.

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 for creating a glyph from scratch but does not explicitly contrast with alternatives like duplicate_glyph or set_glyph_paths. There is no 'when to use' or 'when not to use' guidance, only an implicit context of working with the open font.

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?

With no annotations, the description carries the behavioral disclosure burden. It does disclose the key destructive behavior: 'overwrite: If true, replace existing recipe with same name.' It also explains the file format. It stops short of describing what happens if the recipe already exists and overwrite is false, or whether content is validated.

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 well-organized with a clear action sentence, a template block, and an Args list. It is longer than necessary because the markdown template repeats some prose, but all content earns its place by defining the exact expected format.

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 is largely complete for a creation tool: it identifies the parameters, the required format, and the overwrite behavior. An output schema exists, so return-value details are not required. It lacks only explicit failure semantics when name conflicts occur without overwrite.

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 fully compensate. It does: name is described with a snake_case example, content is described as full markdown and illustrated with a detailed template, and overwrite's effect is explicitly stated. This is strong semantic coverage for every 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?

The description begins with a specific verb and resource: 'Create a new workflow recipe.' It also clarifies the resource type (markdown files with numbered steps), and the create action clearly distinguishes it from sibling tools like get_recipe, list_recipes, and delete_recipe.

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 intended use is clearly implied: call this tool to create a workflow recipe. However, it does not explicitly discuss when not to use it, nor does it contrast with alternatives such as get_recipe for reading existing recipes or delete_recipe for removing them.

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?

With no annotations provided, the description carries the full behavioral disclosure burden. It does disclose a critical trait—'This cannot be undone via MCP'—which is valuable for a destructive operation. However, it does not mention side effects on dependent data, required permissions, or what happens to references to the glyph.

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 two short sentences with no filler. The primary action is stated first, and the critical irreversibility warning is placed second, making the most important information immediately visible.

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 single-parameter destructive tool, the description covers the core operation and a key consequence. It is reasonably complete, though it could briefly note return behavior or effects on associated font data. These gaps are minor given the tool's simplicity.

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 the underdocumented glyph_name parameter, but it only repeats the notion of deleting 'a glyph.' It does not clarify naming conventions, whether the value is a name or ID, or any constraints on the string, leaving the agent underinformed.

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: 'Delete a glyph from the font.' This clearly distinguishes it from sibling tools like rename_glyph, create_glyph, duplicate_glyph, and delete_recipe. The added irreversibility note reinforces the purpose without ambiguity.

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 the tool is for removing a glyph when that is the desired action, but it does not explicitly state when to use it versus alternatives or provide exclusionary guidance. There is enough context to infer usage, but no direct decision support.

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?

With no annotations, the description carries the full burden of disclosing behavior. It does state the destructive action and the first-master default, but it omits what happens if the pair does not exist, whether deletion applies across all masters, or whether the operation is reversible. For a mutation tool, these gaps are significant.

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 front-loaded with the core action and then lists each argument in a compact, scannable format. Every sentence earns its place; there is no filler or repetition.

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 covers the purpose and all parameters, which is enough for a simple invocation. However, because there are no annotations and no output schema, the lack of error/edge-case behavior and master-scope semantics leaves some ambiguity. It is minimally viable but not fully complete.

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 parameters. It successfully explains left and right glyph/group names and master_id's optional/default behavior, providing meaning beyond the bare schema types. It could add more syntax detail for groups, but the current coverage is solid.

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: 'Delete a kerning pair.' It clearly identifies the operation and even explains the left/right group naming format. However, it does not explicitly distinguish itself from siblings like set_kerning_pair or get_kerning, so it stops short of full 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?

There is no guidance on when to use this tool versus alternatives such as set_kerning_pair. The only usage-related context is parameter behavior, such as the optional master_id defaulting to the first master. This is implied usage at best, but not explicit selection 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action 'Delete' but does not disclose whether deletion is permanent, whether confirmation is required, whether dependencies are affected, or what the output/return value is. The output schema exists but the description adds no behavioral context beyond the obvious mutation.

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 short and front-loaded with the core action. The Args section is minimal and directly relevant. It earns its place, though the example could be slightly more illustrative.

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 destructive tool with no annotations, the description is thin. It doesn't mention whether deletion is reversible, what happens to dependent workflows, or how to list available recipes. The output schema exists but the description doesn't clarify what the tool returns on success or failure. An agent would need to infer too much.

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 does add a concrete example ('old_workflow') and clarifies that 'name' is the recipe name to delete. However, it doesn't explain constraints like uniqueness, case sensitivity, or how to find valid names. The single parameter is simple, so the example provides adequate baseline meaning.

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: 'Delete a workflow recipe.' This clearly identifies the action and object. It is distinguishable from siblings like delete_glyph and delete_kerning_pair by the 'recipe' resource, though it doesn't explicitly contrast with them.

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 is given on when to use this tool versus alternatives. The description does not mention prerequisites, such as whether the recipe must exist, or any conditions for deletion. It also doesn't reference related tools like list_recipes or get_recipe for discovering valid names.

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?

With no annotations, the description carries the full burden and does disclose one meaningful behavior: the copy includes all layers and paths. But it says nothing about conflict behavior if new_name already exists, whether the original is left untouched beyond implication, error conditions for nonexistent glyph_name, or naming constraints — significant 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?

Two sentences, zero filler: the action is front-loaded in sentence one, and the use case in sentence two. Every word earns its place.

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 2-parameter tool the essentials are covered: what it duplicates, the copy's scope, and why you would use it. But with no annotations, no output schema, and 0% parameter coverage, the absence of name-collision and error behavior leaves an agent guessing about failure modes.

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 source/target roles (glyph is duplicated 'under a new name'), adding meaning beyond the bare titles. However, it provides no format guidance (e.g., Glyphs naming conventions), no constraint that new_name must differ from glyph_name, and no example, leaving meaningful semantics 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?

The first sentence states a specific verb (duplicate), resource (glyph), and scope ('all layers and paths' under a new name). This clearly distinguishes it from siblings like rename_glyph (which would not copy) and create_glyph (which would not duplicate existing content).

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 second sentence provides a clear use case ('creating alternates or backups before editing'), which implies when to use it. However, it never names alternatives explicitly or states when not to use this tool versus rename_glyph or create_glyph, leaving routing to inference.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It states that code runs with access to the Glyphs object and GlyphsApp API, that stdout is captured and returned, and that the endpoint is powerful and disabled by default. It does not detail potential destructive side effects or error behavior, but for an arbitrary code execution tool the provided warnings and execution model are reasonably transparent.

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 front-loaded with the core action and then adds essential context in a logical order: execution context, output behavior, warning, enablement requirement, recipe guardrails, and example. Every sentence earns its place without padding.

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?

Given the tool's complexity and absence of annotations/output schema, the description covers the key operational facts: what code runs against, what output is returned, the security gate, and which workflows should instead use recipes. It could mention error handling or the absence of a sandbox more explicitly, but the essentials for invoking the tool correctly are present.

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 schema provides only a title 'Code' with no description (0% coverage), so the description must compensate. The description explains that the parameter is Python code executed in GlyphsApp and gives a concrete example: execute_in_glyphs('print(Glyphs.font.familyName)'). This adds enough semantic meaning for an agent to construct a valid call.

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: 'Execute arbitrary Python code inside GlyphsApp.' It clearly distinguishes this from the named sibling tools by establishing it as a raw code-execution endpoint rather than a specific glyph operation. The example reinforces the purpose.

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 explicitly warns against improvising multi-step work and points to get_recipe calls for plugin/script creation and bulk cleanup, which is a clear when-not-to-use exclusion. It also notes the endpoint is disabled by default and must be enabled, giving essential prerequisite context. It could be stronger with an explicit 'use this when...' statement, but the guidance is sufficient.

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?

With no annotations, the description carries full behavioral burden and does so thoroughly. It discloses that export directories are never removed or overwritten, that the tool may ask for confirmation rather than silently saving, that both portable and ANSI log variants are always returned, and that the agent MUST show the ANSI variant when supported. This is strong, actionable behavioral context.

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 front-loaded with the core purpose, then expands into output formats, side effects, response obligations, and parameters. Every sentence adds relevant operational detail without padding or repetition, keeping the definition appropriately sized.

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?

Despite having no output schema and no annotations, the description covers what the tool produces, where it writes, its non-destructive behavior, required agent behavior for logs, and both parameters. Nothing essential for correctly invoking the tool is missing; the only minor gap is edge cases around unsaved/untitled sources, which is not critical given the level of detail provided.

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 compensate. It does: save_before_export is explained as saving pending changes, defaulting to False, and asking for confirmation when edited; timeout is clarified as the maximum seconds for each of the three export runs. This adds substantive meaning beyond the bare schema types.

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: 'Export the open font beside its saved source with glyphs-cli.' It then names the output directory pattern, formats for static vs variable instances, and non-destructive behavior, making the tool's function unmistakable and distinct from the sibling 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?

The description implies usage: call this when you need to export the currently open font after editing. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions, such as unsaved documents or other export paths. The context is inferable but not directly addressed.

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?

With no annotations, the description carries the full transparency burden and does so well: it states that the tool mutates the .glyphs source directly, affects all masters, skips existing drawings, and replaces them only when overwrite=True. It also discloses auto-detected stem behavior when stroke params are 0.

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 efficiently organized: two concise introductory paragraphs establish scope and side effects, followed by a clean Args block. No sentence is wasted, and critical behavioral caveats (skipping existing glyphs, overwrite, all-masters mutation) are front-loaded.

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 mutating generation tool with 7 parameters and no output schema, this description covers the essential operational context: target range, destination source, master scope, overwrite policy, auto-detection logic, and parameter semantics. Nothing critical is missing for an agent 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?

Schema description coverage is 0%, but the description documents every one of the 7 parameters with meaningful semantics: glyph_names formats, overwrite behavior, width auto behavior, stroke thicknesses, double gap, and color labels. This fully compensates 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?

The description specifies a concrete action—generating Unicode box drawing and block element glyphs—and pinpoints the exact codepoint range U+2500–U+259F. This clearly distinguishes the tool from siblings like create_glyph or set_glyph_paths without ambiguity.

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 explains the default behavior and key usage conditions: it processes U+2500–U+259F, skips existing glyphs unless overwrite=True, and operates across all masters. It does not explicitly name alternatives or say when not to use it, but the specialized scope makes intended use clear.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it retrieves OpenType feature code, but does not describe the return format, whether the code is returned as a string, list, or object, or any potential errors. For a getter with no parameters, this minimal disclosure is insufficient for an agent to predict the output structure.

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, concise sentence that states the tool's purpose without fluff. It is appropriately sized for a simple getter operation, though it could arguably include more detail about the output without becoming verbose.

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?

Given the tool's simplicity (no parameters, no output schema), the description provides the core purpose but lacks detail on the exact nature of the returned data. It is minimally complete for an agent to know what the tool does, but not fully comprehensive in terms of what to expect from the output.

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 has zero parameters, so the input schema is trivially fully covered. The description correctly adds no parameter information, which is appropriate. Baseline for zero-parameter tools is 4, and the description does not need to elaborate on parameters.

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 clearly states the verb 'Get' and the resource 'OpenType feature code from the font', making the tool's purpose unambiguous. It distinguishes from set_feature_code which is a write operation, though it doesn't explicitly name alternatives. The phrasing is specific enough that an agent would not confuse it with other getters like get_kerning or get_glyph.

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 provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or alternative tools for related operations. An agent is left to infer usage solely from the name and description, which is minimal.

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?

With no annotations, the description carries the full burden. It says 'Get information' which signals a read-only operation, and it lists what it returns. It does not disclose potential failure modes (e.g., no open font) or explicitly state it is non-mutating, but for a simple getter, this is adequate. There is no contradiction with annotations (none provided).

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 compact: one sentence for the purpose, a second listing the returned data. It is front-loaded and contains no redundant words. Every sentence earns its place.

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, read-only query tool, the description is complete. It enumerates all the information the tool returns (family name, units per em, glyph count, masters, axes, metrics, instances), which fully informs the agent what to expect. Without an output schema, this is sufficient.

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 has zero parameters, so the baseline is 4. The description naturally has nothing to add about parameter semantics, and the schema coverage is 100% (vacuously). No further explanation is 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 clearly states the tool's purpose: 'Get information about the currently open font in GlyphsApp.' It specifies the resource (font) and the action (get info), and it distinguishes itself from siblings like get_masters or list_glyphs by focusing on aggregated font data rather than specific subsets.

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 gives clear context by specifying 'currently open font,' implying it is used to inspect the active font. It does not explicitly mention alternatives or when not to use it, but among many sibling getters, it implicitly serves as the general overview tool. No exclusions are stated, but the scope is unambiguous.

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?

With no annotations provided, the description must carry the full behavioral disclosure. It does so by detailing the return structure: layers, paths, components, anchors, width, sidebearings, and explains node types and path direction encoding. This goes beyond the schema, which has no such details, and helps agents interpret the response.

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 well-structured, with a clear opening sentence, then a bulleted list of return details, and a separate section on node types and path direction. It is informative without excessive verbosity, and each section serves a purpose.

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?

Given the tool's moderate complexity, the description covers the key return data and educational notes on path encoding. However, it doesn't mention error handling (e.g., what happens if glyph_name is invalid) or whether the tool is read-only (though it's a 'get' tool, it could be inferred). With no output schema, this is a minor gap.

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 schema has only one parameter, glyph_name, and the description doesn't add much beyond that. It doesn't specify how to format the glyph name or what happens if it doesn't exist. With 0% schema coverage, the description could compensate, but it largely implies the name is a string. The baseline is 4 for 0 params, but here there is a param, so a 3 is fair.

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 clearly states the tool's purpose: to get complete data for a specific glyph, including paths and metrics. It names the resource (glyph) and the action (get complete data), distinguishing it from siblings like get_glyph_svg or get_font_info. The detail about paths and metrics makes it 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?

The description implies when to use this tool (when you need full glyph data, not just SVG or basic info), but it does not explicitly name alternatives or state when not to use it. For instance, it could mention that for SVG output, use get_glyph_svg, but it doesn't. It provides no exclusions or contextual routing to other tools.

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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It does disclose that the output is SVG markup with a viewBox matching the glyph's metrics, which partially addresses return behavior. However, it does not explicitly state that the operation is read-only, nor does it address error behavior for invalid glyph names or the meaning of an empty master_id, leaving gaps for a tool with no annotation support.

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 concise and front-loaded: the first sentence states the core action, and the second provides useful return details. The third sentence ('Useful for seeing the glyph shape as a vector image.') is somewhat redundant with the first, but overall there is little waste and the structure is easy to scan.

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?

Given no annotations, no output schema, and 0% schema description coverage, the description needs to explain not only the return format but also parameter semantics and safety/error behavior. It does explain the return format, but it omits the purpose of master_id, the consequences of an invalid glyph_name, and an explicit read-only confirmation. For a simple 2-parameter tool, this is incomplete.

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 by explaining parameter meaning, but it mentions neither glyph_name nor master_id. The schema's bare property titles ('Master Id', 'Glyph Name') and default value for master_id are the only clues; the description adds zero semantic value for parameters. This is a significant failure given the low coverage.

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 'Get a glyph rendered as SVG markup', a specific verb+resource statement that clearly identifies the function. The added detail 'Returns SVG with viewBox matching the glyph's metrics' further clarifies the output, but it does not explicitly differentiate this from sibling tools like get_glyph, 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?

The phrase 'Useful for seeing the glyph shape as a vector image' implies a valid use case, but the description provides no explicit guidance on when to use this tool versus alternatives such as get_glyph or list_glyphs. No exclusions, prerequisites, or when-not-to-use scenarios are mentioned, so usage guidance is only implicit.

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?

With no annotations, the description carries the behavioral disclosure burden. It transparently documents defaults (empty master_id = first master, left = all, limit 0 = all), the left-glyph filtering behavior, and provides a performance hint for large fonts. It does not describe the return format, but the core query behavior is clear.

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 compact, front-loaded with the main purpose, and uses a clean Args block where each line adds value. No redundant or filler content is present.

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 three optional parameters and no output schema, the description covers all invocation-relevant details: defaults, filtering, and performance behavior. A brief note on the return shape would make it fully complete, but nothing needed to call the tool 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 fully explain parameters. It does: master_id selects the master, left filters by glyph/group name, and limit caps results with meaningful defaults and a concrete usage recommendation. This fully compensates for the absent 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?

The description states a specific verb and resource: 'Get kerning pairs for a specific master'. It also clarifies default behavior (first master if not specified) and is clearly distinguishable from sibling tools like set_kerning_pair, delete_kerning_pair, and auto_kern.

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 through its parameter guidance, such as 'Use limit=50 for large fonts', but it does not explicitly state when to prefer this tool over alternatives like analyze_kerning or get_font_info. The intended context is inferable but not directly articulated.

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?

No annotations are provided, so the description carries the behavioral transparency burden. 'Get' signals a read-only query, and the description explicitly lists the returned fields, making the tool's behavior predictable. It does not mention ordering, empty-result behavior, or potential data volume, but these are minor for a zero-parameter getter.

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 compact: a one-sentence summary followed by a clear list of return fields. Every sentence earns its place, and the core purpose is front-loaded.

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 input parameters, no annotations, and no output schema, the description provides the necessary return contract: master ID, name, vertical metrics, and axis values. An agent can invoke and interpret the result without requiring additional context.

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 has zero parameters and an empty input schema, so there are no parameter semantics to clarify. The baseline of 4 applies because the description is not required to compensate for any schema 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?

The description states a specific verb ('Get') and a specific resource ('all font masters'), and clarifies the relevant data (metrics and axis positions). This distinguishes it from sibling getters like get_font_info or get_glyph, which target different font objects.

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 when-to-use or when-not-to-use guidance, and no sibling alternative is mentioned. However, the description clearly implies that the tool is for retrieving master-level metrics and axis data, so the usage context is inferable.

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?

With no annotations provided, the description carries the burden of explaining behavior. It clearly states that the tool returns the full recipe plus totalSteps count but does not mention error handling, permissions, or side effects. For a simple read operation, this is adequate but not rich.

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 compact and front-loaded with the core purpose, followed by return-value behavior and a clear parameter explanation. Every sentence contributes value, and the Args section is clearly structured.

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?

This is a simple one-parameter getter with an output schema, and the description covers the essential context: what the tool returns, how to use the parameter, and when to choose the sibling tool. Nothing needed for correct invocation 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 0%, but the description fully compensates by explaining that 'name' is a recipe name from list_recipes and providing the example 'scale_proportions'. This gives the agent everything it needs to construct a valid invocation.

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 'Get a specific workflow recipe by name', using a specific verb and resource. It also differentiates itself from get_recipe_step by noting it returns the full recipe, and from list_recipes by focusing on a single named recipe.

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 explicitly points to get_recipe_step() for reading and executing one step at a time, implying that get_recipe is for retrieving the full recipe at once. It also directs the agent to list_recipes as the source for valid recipe names, which is practical usage 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?

No annotations are provided, so the description carries the full burden. It transparently discloses that the response includes a MANDATORY directive field that must be followed, and that all tools in the content must be executed before proceeding. This goes beyond a simple read operation and prepares the agent for side effects (tool invocations), which is valuable behavioral context.

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 well-structured with clear sections and bullet points, front-loading the mandatory directive and step execution requirements. It is somewhat verbose but every sentence adds value, such as the return fields and the warning against skipping steps. Minor redundancy in repeating 'do not skip steps' and 'do not combine steps' could be trimmed.

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?

Given an output schema exists (though not shown fully), the description doesn't need to detail return types, and it does list the expected fields. It covers key behaviors (mandatory directive, sequential execution) and handles the 0% schema coverage for parameters. It could mention error handling or edge cases (e.g., out-of-range step), but overall it is sufficient for correct usage.

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 explains that 'name' is the recipe name and 'step' is a 1-based step number, adding meaning beyond the schema. However, it doesn't provide details on valid recipe names or step bounds beyond the example, so it partially compensates but not fully.

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 clearly states it retrieves a single step from a recipe for sequential execution, specifying the resource (recipe step) and the action. It also distinguishes itself from get_recipe (which likely retrieves the whole recipe) and list_recipes, making its purpose 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?

The description explicitly instructs to execute all tools in the step content, not skip or combine steps, and to follow the directive field. This provides clear when-to-use guidance, though it does not explicitly state when NOT to use this tool (e.g., when you need the entire recipe). The absence of explicit exclusions is a minor gap.

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?

With no annotations, the description carries the full behavioral burden. It discloses the return contents (active glyph name, layer, selected paths/nodes), the null edge case, and implicitly indicates a read-only operation through the verb 'Get'. It does not explicitly state that no side effects occur, but this is strongly implied and the key edge case is covered.

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 short sentences with no filler. The primary action is front-loaded, followed by return details and the null condition. Every sentence earns its place.

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 getter with no output schema, the description covers what an agent needs: what it returns and when it returns null. No missing prerequisites, options, or edge cases are relevant. The lack of an output schema is compensated by naming the returned fields directly.

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 has zero parameters, so the schema is trivially complete. There is nothing for the description to add about parameter meaning or formats. Baseline of 4 for a parameterless tool is appropriate.

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 ('Get') with a clear resource ('the user's current selection in GlyphsApp's editor') and specifies what is returned (glyph name, layer, selected paths/nodes). This cleanly distinguishes it from sibling tools like get_glyph or get_font_info, which fetch stored data rather than the live editor selection.

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 context is implied rather than explicit: an agent would use this when it needs the current selection. However, the description does not name alternatives or state when not to use it. The null-return condition ('if no tab or layer is active') provides some situational context but no direct comparison with sibling tools.

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?

The description details what the tool generates (canonical test strings based on five named methods), which is useful behavioral context. But with no annotations provided, the description carries the full burden and does not explicitly state whether the tool is read-only, modifies anything, or has preconditions. The imperative 'Get' implies read-only, but this is not 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?

The description is well-structured: a clear purpose statement in the first line, followed by a scannable bullet list of methods and a practical usage note. Each bullet adds meaningful detail about the generated strings, and the RECIPE pointer is useful. It is slightly longer than necessary but every section earns its place.

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 presence of an output schema covers return-value expectations, and the description provides strong context about the tool's purpose and output methods. However, missing annotations and the absence of any statement about preconditions (e.g., glyph must exist) or error behavior leave gaps. It is adequate but not fully complete for an agent to invoke with full confidence.

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 compensate for the single parameter. The 'Args' section simply says 'Name of the glyph to generate test strings for,' which adds minimal meaning beyond the parameter name. It provides no examples, allowed formats, constraints, or guidance on what constitutes a valid glyph 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 states a specific verb ('Get'), a concrete resource ('spacing test strings'), and the precise purpose ('visually evaluating a glyph's spacing'). It distinguishes itself from sibling analysis tools like analyze_spacing by listing canonical test string methods (e.g., three-at-a-time, systematic pairs), making the tool's unique role clear.

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 provides a clear usage context: 'for visually evaluating a glyph's spacing' and explicitly directs systematic work to get_recipe('spacing_workflow'). It also explains where the strings are applied ('GlyphsApp's Edit view'). However, it doesn't explicitly name alternative tools or state when not to use this tool, so it falls short of perfect 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates a read operation ('Get'), describes the data sources ('custom parameters AND measured values from reference glyphs'), and explains the semantic role of the returned values. It stops short of explicitly stating that it performs no mutations, but the 'Get' verb and the overall context make that clear. A slightly stronger statement about side-effect-free behavior would push this to 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?

The description is tightly written, with the core purpose in the first sentence, followed by a concise explanation of what the returned values are and a usage directive. Every sentence adds value, and the structure front-loads the most critical information. No filler or redundancy.

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 explains the tool's purpose, return content, and relation to siblings, which covers most operational needs for a simple getter. However, the complete omission of the master_id parameter is a notable gap—an agent would not know whether passing a value is necessary or what it controls. Given the tool's low complexity, this missing piece prevents a higher score.

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 schema has one parameter, master_id, with 0% schema description coverage (no descriptions in the schema). The tool description completely omits any mention of this parameter, leaving its purpose and acceptable values entirely undocumented. Since the description is the only source of parameter semantics and it fails to address it, the score is minimal.

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 clear verb+resource: 'Get the designer's intended stem values from the Dimensions palette.' It specifies exactly what the tool retrieves (stem snap values and measured values from reference glyphs) and explicitly differentiates its purpose from siblings like compare_stems and measure_stems by labeling these as 'TARGET values'.

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 explicitly states when to use this tool: 'Use this as baseline for compare_stems' and clarifies the intended comparison ('to check if glyphs hit the designer's intended values, not just if they're consistent with each other'). This directly addresses the alternative tool and the decision context, leaving no ambiguity about its role.

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?

No annotations exist, so the description carries full burden. It discloses return fields, explicitly excludes path data, and explains filter defaults. Does not mention ordering or pagination beyond limit, but for a list tool this is adequately transparent.

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?

Compact, front-loaded purpose, followed by return summary, exclusion note, and arg meanings. Every sentence earns its place.

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?

Despite no output schema, description states exact return fields and the one major behavioral caveat (no path data). Parameters are fully documented. Only minor omissions like ordering or error behavior, which are non-critical for a simple list endpoint.

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%, but description compensates fully by explaining category values including 'Empty = all' and limit semantics '0 = all' — meaning beyond the parameter names.

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?

Clear verb 'List' with resource 'glyphs in the open font' and scope 'with basic metadata'. Explicitly contrasts with get_glyph by excluding path data, distinguishing it from sibling 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?

States 'Does NOT include path data — use get_glyph() for full details,' explicitly routing when full glyph details are needed. Also explains category filter behavior, making when-to-use unambiguous.

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 are absent, so the description carries the full burden, and it discloses meaningful context: recipes encode expert knowledge and dependency ordering, and this tool is a mandatory gateway for multi-step workflows. It does not describe the output list's format or ordering, but the presence of an output schema covers return shape, making this a minor gap rather than a critical one.

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 primary action is front-loaded in the first sentence. Every subsequent sentence earns its place: the recipe definition clarifies what the listing returns, and the IMPORTANT directive adds critical workflow context without bloat.

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 list tool with an output schema present, the description covers everything an agent needs: what the tool does, what recipes are, when calling it is mandatory, and what to do next (get_recipe). Nothing material 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?

The tool has zero parameters (empty input schema), which sets the baseline at 4. There is nothing to document, and the description appropriately avoids inventing parameter details. No semantic gap exists.

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 first sentence, 'List available workflow recipes', pairs a specific verb with a defined resource. The description then defines what recipes are, and by framing this tool as the entry point before get_recipe/get_recipe_step, it is clearly distinguished from retrieval and management siblings (create_recipe, delete_recipe).

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?

Explicit when-to-use guidance is given: 'You MUST call this before starting any multi-step type design task' with concrete examples (scaling, auditing, spacing, kerning, compatibility checks). It also names the alternative and next step: 'call get_recipe(name) and follow its steps in order'. This is textbook when/when-not/alternative 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?

With no annotations provided, the description carries the behavioral transparency burden. It explains the calculation, the normalization by zone height, the expected output range, and the interpretation of higher vs. lower values. It does not explicitly state that the tool has no side effects, but 'measure' plus 'Returns a value' strongly implies a read-only operation.

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 compact, front-loaded with the primary purpose, and each sentence adds meaningful detail: formula, normalization, output range, and interpretation. There is no filler or repetition.

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 measurement tool with no output schema, the description adequately covers what is returned and how to interpret it. However, the missing parameter semantics and lack of differentiation from sibling measurement tools leave an agent with some uncertainty about optional inputs and alternative tool selection.

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, but it never mentions glyph_name or master_id. 'Single glyph' weakly maps to glyph_name, yet master_id is entirely unexplained, including its optional role and default-empty behavior.

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: 'Measure the ink density (typographic color) of a single glyph.' It defines the metric precisely with a formula and normalization rule, and distinguishes this from sibling tools like compare_color or audit_font_color by emphasizing a single glyph measurement.

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: call this whenever you need the ink density of one glyph. However, it gives no explicit guidance about when to prefer this over alternatives such as compare_color or audit_font_color, and no exclusions or prerequisites are stated.

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?

With no annotations, the description carries the full burden. It usefully discloses the ray-casting technique and the returned measurement categories, but it never explicitly states that the operation is read-only/non-destructive or how it behaves for missing glyphs, invalid master_id, or unusual outlines.

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 compact and well-structured: purpose, algorithm, returned values, workflow guidance, and examples are all present without fluff. The extra detail is justified by the absence of a schema description and output 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?

It is sufficient for a basic call with just glyph_name, and it outlines the return categories despite having no output schema. However, optional parameters like samples and master_id remain undefined, and units or exact output formatting are not disclosed, leaving gaps for more nuanced usage.

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 only clarifies glyph_name through examples. samples and master_id are not explained at all beyond their schema types and defaults, so the agent must guess their meaning and impact on the results.

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 begins with a specific verb and resource: 'Measure stem thicknesses in a glyph using ray-casting,' and it clarifies vertical versus horizontal stems. It is clearly a measurement tool distinct from compare-focused siblings like compare_stems, though it never explicitly names alternatives.

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 a concrete workflow instruction: use this BEFORE and AFTER applying RMX filters to verify the effect. It also provides natural-language examples, but it does not explain when to prefer compare_stems or other stem-analysis tools 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?

With no annotations, the description carries the behavioral transparency burden. It does disclose one concrete behavior, the uniqueness failure condition, but it does not mention side effects, whether references are updated, permissions, or return behavior.

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 two short sentences with no filler. The core action is front-loaded, and the important failure condition is presented as a separate, easily parsed 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 simple two-string rename operation, the description covers the core action and one key failure case. However, because there are no annotations or output schema, it leaves unanswered what happens if glyph_name is missing and what the tool returns on success or failure.

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 supply parameter meaning. It clarifies that new_name must not already exist and implies that glyph_name identifies the glyph to rename, but it omits naming rules and behavior for a nonexistent glyph_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 opens with a specific verb and resource ('Rename a glyph') and adds a behavioral discriminator ('Fails if new_name already exists'). It is clearly distinct from sibling tools like create_glyph, duplicate_glyph, and delete_glyph, so an agent can identify its intended role.

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 when-to-use guidance or comparison with alternatives. The description only states the operation and one failure condition, leaving the agent to infer when rename_glyph should be chosen over related glyph tools.

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?

No annotations are provided, so the description must carry the full burden. While it explicitly describes the output ('Returns a formatted markdown report with pass/fail status and details for failures'), it does not explicitly state that the tool is read-only and does not modify the font. Given that many siblings are mutating (e.g., set_glyph_width, create_glyph), clarifying this would be valuable. The name and 'review' wording imply non-destructiveness, but it is not explicitly 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?

The description is long but well-organized, with a clear hierarchy: purpose sentence, severity categories with bullet items, and return format. Every sentence contributes useful information—the listing of all 44 checks is detailed but serves to set expectations. It is not wasteful, though it could be condensed by grouping checks, but the structure makes it easy to digest.

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 tool with no parameters and an existing output schema, the description is exceptionally complete. It specifies the exact scope (44 checks across three severities), lists the items, and states the output format. There is no missing information an agent would need to decide whether to invoke it or to interpret its results. The output schema likely covers the exact return structure, so the description's mention of a markdown report suffices.

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 has zero parameters and the schema is empty. With no parameters, the description does not need to document any, and the baseline is 4. The description adds no parameter-related information because there is none to add, which is appropriate and sufficient.

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 clearly states a specific verb ('Run') and a concrete resource ('comprehensive production readiness review on the open font'). It enumerates 44 checks across severity levels, which unambiguously distinguishes it from sibling tools that each address a single concern (e.g., check_font_name, check_overshoots). No other tool aggregates such a broad 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?

The description does not explicitly state when to use this tool versus the more granular sibling tools. It implies this is a full review by calling it 'comprehensive', but it never says 'use this when you need to run all checks at once, or use check_font_name for a single check'. The agent is left to infer usage context from the word 'comprehensive' and the list of checks.

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?

No annotations are present, so the description carries the burden. It adds useful non-obvious context: a get_recipe prerequisite for scaling, optional master_id, and the relationship to individual tool params. Still, it does not disclose mutation/undo behavior, return values, or failure handling for a potentially destructive batch operation.

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 well structured: a one-line definition, a recipe tip, labeled args, and two relevant examples. It is slightly longer than necessary, but every section contributes actionable 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?

An agent can likely construct a valid batch call from this description because it covers the top-level arguments and gives examples. However, without annotations or an output schema, important context is missing: exact per-filter parameter schemas, return format, error behavior, and whether the operation is reversible.

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, the description compensates by listing allowed filter_name values, explaining glyph_names, defining params as filter-specific, and marking master_id optional. The examples with params keys like mode and width add concrete meaning beyond the bare 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?

Describes a specific action: apply one of four named RMX filters to multiple glyphs at once. The batch semantics clearly distinguish it from the individual rmx_harmonize, rmx_scale, rmx_tune, and rmx_monospace siblings, and the examples reinforce the exact call pattern.

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 when to use this tool by focusing on multiple glyphs and gives a workflow hint for multi-glyph scaling with get_recipe. However, it does not explicitly contrast it with the individual RMX tools or state when not to use batch processing, so the decision guidance is incomplete.

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?

With no annotations, the description carries the burden of explaining behavior, and it does explain the main transformations: modes include 'dekink', 'extract handles', and 'supersmooth all'. However, it never states that the glyph's paths are modified in place, whether the operation is reversible, or what the tool returns, which leaves safety-relevant behavior undisclosed.

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 well organized: one purpose sentence, a scannable mode list, and a short usage note. It is reasonably compact, but the final sentence about multi-master support could be integrated more tightly with parameter semantics, and the purpose sentence is slightly restated by the usage note.

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 mutating tool with no annotations, no output schema, and 0% schema coverage, the description should cover return values, side effects, and the meaning of master_id. It provides good mode detail but omits these essentials, so an agent cannot fully predict the consequences of invoking 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 explain the parameters, but it only does so partially. The mode list gives possible values for the 'mode' property, though it never explicitly says these strings map to that parameter, and 'master_id' is never explained except indirectly by the no-multi-master note. 'glyph_name' is inferable from the purpose but not documented as an accepted value.

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 names a specific operation and resource: 'Optimize bezier curves on a glyph using RMX Harmonizer.' It is clear that this tool operates on glyph curve data, and the mode list adds precision. It does not explicitly distinguish itself from sibling tools like rmx_tune, so it misses the top score for 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?

The description states when to use it: 'Use after drawing or modifying paths to ensure clean curves.' It also gives a recommended default mode and notes that it works on any glyph without a multi-master requirement. It does not spell out when to prefer a sibling tool or when not to use this tool, so no exclusions are provided.

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?

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: it 'intelligently distributes width change between outline scaling and spacing adjustment' and requires 2+ masters. It does not explicitly mention side effects, reversibility, or failure behavior, but the main mutation behavior and a key precondition are clearly communicated.

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 front-loaded with the core purpose and uses compact, purposeful sections for args and an example. No sentence is wasted, and the required prerequisite is included without unnecessary elaboration.

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 5-parameter tool with no annotations and no output schema, the description covers purpose, all parameter meanings, an example, and the 2+ masters prerequisite. It could be more complete by describing return values or error conditions, but an agent has enough information to invoke the tool 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?

The schema has 0% description coverage, so the description's Args section is essential and does explain all five parameters meaningfully, including defaults and ranges. The example is also helpful, but it introduces a consistency issue by using 'monoWidth' while the schema and Args list use 'mono_width', which could mislead the agent.

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 action ('Adjust a glyph to a fixed width') and names the mechanism ('RMX Monospacer'), which clearly conveys the primary purpose. The second sentence about distributing width change between outline scaling and spacing helps differentiate it from simpler width-setting tools, though it does not explicitly name or contrast with sibling tools like set_glyph_width.

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 a useful example and a clear prerequisite ('Requires 2+ masters'), which implies when the tool can be used. However, it does not explicitly state when to prefer this over alternatives such as set_glyph_width or rmx_scale, nor does it mention when not to use it.

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?

No annotations exist, so the description carries the full burden. It discloses the use of RMX Scaler with stroke-weight compensation, the opt-in native affine fallback and its limitation, the fact that RMX processes all masters even when master_id is set, and the response's method field. It does not state whether the operation modifies in place or returns a new glyph, which prevents 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?

Despite its length, the description is well-structured: a one-sentence purpose, a highlighted usage directive, a recipe hint, a concise behavior note, a bulleted Args section, and examples. Every sentence conveys necessary information with no filler, appropriate for a tool with 8 parameters.

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?

Given 8 parameters, no annotations, and no output schema, the description is nearly complete: it explains all params, the method field, fallback semantics, and provides examples. It lacks only explicit statement of whether the glyph is edited in place or returned as a new object, and how errors are surfaced, which would make it fully complete.

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 entirely. It does: every one of the 8 parameters is documented with meaning and, for width/height, concrete percentages (100 = no change, 130 = 30% wider). It also explains list semantics for per-master control and provides example invocations. This is exemplary compensation.

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 clearly states a specific verb, resource, and scope: 'Scale a glyph by percentage in width and/or height.' It also gives canonical examples. However, it does not explicitly differentiate itself from the sibling smart_scale, which could plausibly perform scaling too, 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?

The description gives explicit when-to-use guidance: 'USE THIS for percentage-based scaling requests like "make 30% wider"'. It also provides a recipe instruction for multi-glyph tasks and explains the fallback behavior. It does not name alternatives or exclusions, so it is not a full 5.

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?

With no annotations provided, the description carries the full behavioral burden, and it delivers: it discloses that width/height/weight/slant are deltas not percentages, that blend is normalized 0-1, that values above 1 extrapolate and 'can produce extreme outlines', and that the tool calls the real Tuner rather than approximating. This is exactly the safety-relevant behavior an agent needs.

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?

Well structured: the essential delegation behavior is front-loaded, parameter documentation is cleanly formatted, and a concrete example closes the description. It is somewhat long, but every section earns its place for a 9-parameter tool, so this is warranted length rather than padding.

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?

Comprehensive for a 9-parameter tool with no output schema: all parameters documented with semantics and ranges, behavioral caveats (delta interpretation, extrapolation risk) explained, and a usage example given. Nothing an agent needs to call this 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 compensate, and it fully does. Every parameter is documented with its meaning and direction (weight '+ = heavier, - = lighter', width, height, slant) plus semantics for blend, fixed_width, master_id, and all_masters. Ranges are given where it matters.

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 ('Adjust a glyph by delegating directly to the installed RMX Tuner') and draws a sharp contrast with native interpolation ('does NOT approximate Tuner with native interpolation'). The purpose is unambiguous and distinguishable from siblings like rmx_scale and rmx_harmonize.

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?

Explains the delegation model and the condition under which it applies (when the real RMXTuner instance is needed rather than native interpolation). It provides useful range guidance for typical values. However, it never names sibling tools or states when one should choose rmx_tune over rmx_scale, rmx_harmonize, or rmx_batch, leaving some routing implicit.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create or update' usefully reveals upsert semantics (the tool won't fail if the feature already exists), but nothing is said about validation of AFDKO syntax, whether changes are applied immediately or reversibly, what happens on malformed code, or what the response contains. For a mutating tool with zero annotation coverage, this is a significant gap.

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 tight docstring: one purpose sentence followed by three parameter lines, with the purpose front-loaded. Every sentence adds information and there is no filler. It's slightly mechanical in format but appropriately sized for a three-parameter tool.

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 three parameters are explained, so basic invocation is fully covered even with a bare schema. However, there is no output schema, no annotations, and the description omits behavioral context: what the tool returns, how errors in AFDKO syntax surface, and how this fits the broader feature/kerning workflow among 54 siblings. Adequate for a first call, but with clear gaps for a mutation 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 compensate — and it does. It supplies concrete feature tag examples ('liga', 'kern', 'ss01'), clarifies that code is in AFDKO syntax, and explains the meaning of active ('whether the feature is enabled'). This adds genuine meaning beyond the bare schema titles (Code, Active, Feature Name). It loses a point because the default value for active is duplicated from the schema and no format constraints for code 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?

The description opens with 'Create or update an OpenType feature,' which pairs a specific verb (create/update) with a concrete resource (OpenType feature). This is clear about what the tool does and implies write/upsert semantics that distinguish it from read siblings like get_features. However, it doesn't explicitly name or contrast with overlapping siblings such as auto_kern, which also manipulates feature-related data, so it stops just short of full 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?

There is no guidance on when to invoke this tool versus alternatives. No mention that get_features should be used to read current feature code, or how this relates to auto_kern-generated features. An agent is left to infer the tool's role from its name and the sibling list, with no explicit conditions or exclusions.

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?

With no annotations, the description carries the behavioral burden. It explains the color index mapping (0-11) and the boundary behavior of clearing the color with out-of-range values. This goes beyond a bare 'set color' statement, though it does not discuss error handling for invalid glyph names or mutation side effects.

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 compact and well-structured. The purpose is front-loaded in the first sentence, followed by a necessary color-index table and one clear usage note. Every sentence earns its place without padding.

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 setter with no output schema, the description provides the essential semantics: the action, the target, the valid values, and the clearing behavior. It stops short of stating what happens if the glyph does not exist or whether the change is persisted, but these are not critical for a basic 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?

The schema provides only types and titles for the two parameters, with 0% schema description coverage. The description compensates richly for the 'color' parameter by enumerating the valid indices and their meanings. The 'glyph_name' parameter is left to inference, but its purpose is clear from the name and the tool's function.

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: 'Set the color label of a glyph in the font view.' This clearly identifies the action and target, and differentiates it from sibling tools like set_glyph_width, set_glyph_unicode, and set_glyph_paths. The focused phrasing leaves no ambiguity about what the tool does.

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 stating the core action, and it provides one explicit usage instruction: 'Use None/no color by setting any value outside this range.' However, it does not mention when to prefer this tool over alternatives such as measure_color or audit_font_color, nor does it state exclusions.

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?

Since no annotations are provided, the description carries the full burden. It clearly discloses the destructive nature ('This OVERWRITES existing paths'), the automatic call to correctPathDirection(), and the prerequisite that the glyph must exist. It does not cover error handling or reversibility, but the core side effects are transparent, warranting a 4.

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 fairly long but every sentence adds essential information: the main action, overwrite warning, path structure, node types, direction, and master_id behavior. It is front-loaded with the key statement and organized logically. Not overly verbose for the complexity involved, so a 4.

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 covers prerequisites (glyph existence), the data structure, node semantics, and the master_id default. It lacks explicit mention of return values or error behavior, but for a setter that might be acceptable. The complexity is high, and the description addresses most key aspects, but a note on validation or failure modes would make it complete.

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 compensate. It thoroughly explains the 'paths' parameter structure, including the closed flag, nodes array, and each node's x/y/type/smooth fields. It also details node types (line, curve, offcurve) and path direction rules. This goes well beyond the schema, which only has a generic array type, making it a 5.

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 clearly states a specific action: 'Replace ALL paths on a glyph's layer in GlyphsApp.' It identifies the resource (glyph) and the operation (replacing paths), and it distinguishes itself from sibling tools like set_glyph_width or set_glyph_color because it's the only one dealing with path geometry.

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 provides clear context: the glyph must already exist, and it explains the master_id behavior. However, it does not explicitly mention when to use this tool versus alternatives or when not to use it, though no direct alternative exists among siblings. The prerequisite and default behavior give enough usage guidance for a 4.

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