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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which cover the safety profile. The description adds useful behavioral context by revealing the return value (spec_id) and constraining response format ('include JSON only on request'), without contradicting any annotation.

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 very concise with two tight clauses and no filler. It front-loads the action and output, earning its place, though the brevity contributes to semantic gaps in other dimensions.

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?

Even with an output schema present, the description is incomplete for a tool with seven parameters and no schema descriptions. It omits parameter semantics, usage context, and any explanation of what 'patches' means, leaving too much to inference.

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 fails to define any of the seven parameters, including the required 'spec' and 'operations'. It only vaguely references 'patches', leaving the agent to infer parameter meanings entirely from bare schema titles and 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 uses a specific verb ('Apply patches') and an output ('return a spec_id'), which conveys the core function and distinguishes it from siblings like get_spec or compile_spec. However, it does not explicitly state that patches are applied to a spec, leaving a slight ambiguity about the target resource.

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 such as compile_spec or evaluate_visual_patch. The only additional instruction ('include JSON only on request') is about response formatting, not usage context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value beyond those by clarifying that the tool returns a resolved view and overlay metadata, implying an in-memory compilation step rather than a render or persistent mutation. No contradiction exists between the description and 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 a single sentence with no filler and front-loads the primary action and output. It is concise, though it could earn a higher score by briefly addressing data_bindings or the relationship to sibling tools without adding 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?

An output schema exists, so return-value details do not need to be repeated, and annotations cover the safety profile. However, the description is incomplete for agent decision-making because it omits data_bindings semantics and any guidance on when compiling is the right step relative to validation or rendering. It is adequate but leaves clear gaps.

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 only contextualizes 'spec' as a FigureSpec. The data_bindings parameter is entirely unexplained, and the valid forms for spec (object vs string) are left to the agent to infer. This is insufficient for a schema that provides no field-level 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 uses a specific verb ('Compile') and resource ('FigureSpec') and names the output ('resolved view and overlay metadata'), so an agent gets a clear sense of what the tool does. It does not explicitly distinguish itself from sibling tools like render_spec or validate_spec, but the wording is specific enough to avoid being generic.

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 about when to use compile_spec versus the sibling alternatives such as render_spec, observe_spec, or validate_spec. The description states the operation but does not indicate whether compile should precede rendering, how it differs from validation, or when it would be the wrong choice.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the description is not contradictory. However, it adds almost no behavioral context: it does not disclose whether the tool writes to output_dir, executes operations, or mutates state, leaving the agent to infer side effects from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short, but this is under-specification rather than effective conciseness. The single sentence does not convey the tool's function or parameter meaning, so it fails to earn its place as a usable definition.

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 a 9-parameter schema, no parameter descriptions, a rich sibling set, and no output-format explanation, this description is far too incomplete. Even though an output schema exists, the tool's core behavior and required parameters remain opaque.

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 explains none of the 9 parameters. Terms like 'operations', 'data_bindings', 'visual_criteria', and 'max_operations' are completely undocumented, so an agent cannot know how to set them correctly.

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 reads as an instruction about response style ('Compare compact evidence') rather than a clear statement of what the tool does. It never names the resource being evaluated or mentions a visual patch, and it does not help distinguish this tool from siblings such as render_spec or apply_patch.

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 call this tool versus any of the 12 siblings. The only clause, 'include full specs/manifests only on request,' addresses output verbosity, not tool selection or invocation context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the precondition that the spec must be validated, which is useful, but 'preserving intent' is too ambiguous to convey what behavior actually occurs. No contradiction with 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 a single sentence with no wasted words, but it is severely under-specified for a tool with 11 parameters. The phrase 'preserving intent' adds ambiguity rather than clarity, and the structure does not front-load important usage details. This reads as under-specification, not 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 has 11 parameters, a required spec, and an output schema, the description fails to explain what a spec is, how validation relates to this operation, what 'preserving intent' means, or how the other parameters affect the fitting. The output schema may cover return values, but the behavioral and semantic context is far too thin 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% across 11 parameters, yet the description only mentions 'spec_id' (which maps to the 'spec' parameter). It provides no meaning for fov, margin, backend, projection, direction, resolution, or data_bindings, leaving the agent to guess at their roles from names and defaults alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action (fit) and resource (scene.camera), and states the input source (a validated spec_id). This differentiates it from siblings like render_spec or observe_spec, though the phrase 'preserving intent' is vague and does not clarify what the tool does beyond fitting a camera.

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, no prerequisites beyond 'validated spec_id' (which is not elaborated), and no mention of situations where it should not be used. The description leaves the agent to infer context solely from the name and schema.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the nuance that it returns *declared* (rather than measured or inferred) features and limitations, which is useful context. However, it does not disclose any other behavioral traits such as ordering, completeness guarantees, or potential cost, so it adds only modest value beyond 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 a single, information-dense sentence with no filler. It front-loads the action ('Return') and immediately specifies the resource and scope ('declared features and limitations for every rendering backend'), making every word earn 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 tool with a provided output schema and annotations covering safety, the description is fully sufficient. It states exactly what is returned and the scope ('every rendering backend'), so an agent can invoke it correctly without missing information. The presence of an output schema covers return-value details, and the safety annotations cover side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so there is nothing for the description to add to the input schema. The baseline of 4 applies because no parameter documentation is needed; the description correctly stays silent on parameters rather than inventing unnecessary detail.

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 ('Return') and a specific resource ('declared features and limitations for every rendering backend'). It clearly differentiates from sibling get_* tools (get_schema, get_spec, get_spec_template) by naming the exact subject matter – rendering backends – leaving no ambiguity about what the tool delivers.

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 explicit when-to-use or when-not-to-use guidance is provided, and no alternative tools are mentioned. The usage context is implied by the tool's purpose – an agent would call this when it needs to know what features or limitations rendering backends declare – but the description does not state exclusions or conditions, so it stops short of strong guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a behavioral trait: the tool returns compact guidance by default and 'full' is a last resort, which hints at output size/performance trade-offs. However, it does not explain what 'compact guidance' means, what the output structure is, or why 'full' is a last resort (e.g., expensive, verbose). The description does not contradict 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 extremely short, which is concise, but it is under-specified rather than efficiently informative. The single sentence is front-loaded with the main guidance, but it lacks the substance needed to be useful. It earns a 3 because it is not bloated, but it sacrifices clarity for brevity.

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 an output schema, which may explain return values, but the description still fails to explain the tool's core purpose, the meaning of the fragment parameter, or the role of include_dependencies. With 0% schema description coverage and no parameter documentation, the description is incomplete for an agent to select and invoke the tool correctly. The output schema presence lowers the burden for return values, but the input semantics remain unclear.

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 two parameters, but it only mentions fragment='full' without explaining the fragment parameter's purpose or valid values. It does not mention include_dependencies at all. The schema provides only types and defaults, leaving the agent to guess what fragment and include_dependencies control. This is a significant 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 'Return compact guidance; use fragment='full' only as a last resort' is vague about what the tool actually does. It mentions returning guidance and a fragment parameter, but does not state the resource (schema) or a clear verb like 'get' or 'retrieve'. It does not distinguish itself from siblings like get_spec or get_spec_template, and the purpose is only inferable from the tool name.

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 a weak usage hint: use fragment='full' only as a last resort. This implies a preference for compact output but does not explain when to use this tool versus alternatives like get_spec or get_spec_template. There is no explicit when-to-use or when-not-to-use guidance, and no mention of what fragment values are available or what 'full' means.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful behavioral context beyond annotations: the handle is session-local and content-addressed, implying scoped validity and deterministic resolution. It does not detail error behavior, but the output schema and simple nature reduce the need.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler, front-loading the core action and resource. Every word earns its place, and the description is appropriately sized for a simple one-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?

The tool is simple, has one required parameter, a rich annotation set, and an output schema, so the description does not need to explain return values. It is complete enough for invocation, though it could strengthen context by clarifying how this differs from sibling tools like get_spec_template.

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 must compensate, and it does by defining spec_id as a 'session-local content-addressed FigureSpec handle.' This adds meaning beyond the bare string type in the schema, though it stops short of explaining format or how to obtain the handle.

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 ('Resolve') and a specific resource ('session-local content-addressed FigureSpec handle'), making the tool's function clear. It is distinguishable from siblings like get_schema and get_spec_template by the 'handle' focus, though it does not 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?

The description implies the tool should be used when the agent has a session-local content-addressed FigureSpec handle to resolve, but it provides no explicit guidance on when to prefer this tool over alternatives like get_schema or get_spec_template. No exclusions or alternative routing are mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no further behavioral context, such as what 'minimal canonical' means in practice or whether these templates are empty scaffolds. It is consistent with the annotations but provides no extra transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. Both the action and the resource are placed prominently, making it 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?

Despite having an output schema and safety annotations, the tool has five parameters and zero schema coverage. The description provides no parameter semantics, no usage guidance, and no behavioral context, leaving the tool underspecified for an agent to call 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%, and the description does not mention any of the five parameters (name, data_id, attribute, categories, label_value). An agent cannot infer what these parameters control or how they affect the returned template from the description alone.

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 identifies the resource ('minimal canonical FigureSpec templates') and the action ('List or return'). It is specific and distinguishable from sibling tools like get_spec or get_schema, but the dual verb 'List or return' leaves the selection logic between modes slightly implicit.

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 no explicit guidance on when to use this tool versus alternatives. 'List or return' implies that providing a name returns one template while omitting it lists all, but this is not stated, and there are no exclusion criteria or references to 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?

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds a small amount of context about the purpose (inspecting a mesh before attribute selection) but does not describe return behavior, side effects, or any caveats. With annotations covering safety, a score of 3 is appropriate as the description adds minimal behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that is front-loaded with the action and resource. There is no wasted wording, and it is easy to read. It is appropriately sized for the tool's simplicity.

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?

While the tool is simple (one parameter) and an output schema exists, the description lacks critical details such as what 'source' should be, what the inspection returns, and when to use it compared to siblings. The missing parameter semantics and usage guidance make it incomplete for an agent to confidently call 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 input schema has a single required parameter 'source' with no description, and schema description coverage is 0%. The description does not explain what 'source' refers to (e.g., whether it is the mesh identifier or a path). Since the description does not compensate for the missing parameter documentation, this dimension is weak.

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 clear action ('Inspect') on a specific resource ('workspace mesh') and adds a purpose ('before selecting attributes'). It is specific enough to understand the tool's function, but it does not distinguish it from sibling tools like get_schema or observe_spec, which might also inspect data.

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 no guidance on when to use this tool versus alternatives. It mentions 'before selecting attributes' as a context, but does not explain when not to use it or point to any sibling tool that might be more appropriate. No exclusions or alternatives are listed.

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

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

Annotations already provide idempotentHint=true and destructiveHint=false; the description adds that the tool produces PNG output and compact visual evidence, implying file output. It does not contradict annotations, but it does not disclose side effects such as whether output_dir is created or overwritten, or how strict/visual_criteria affect 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 a single sentence with no filler and is front-loaded with the verb and object. However, it is so terse that it omits essential context for a 9-parameter tool, so it is concise but not optimally informative.

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 9 parameters, 0% schema coverage, and no parameter explanations, the description is far from complete. It does not define the required spec/output_dir semantics, what views/passes/strict/resolution/visual_criteria control, or what 'compact visual evidence' means. The output schema covers return values, but the operational context 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%, and the description does not explain any of the 9 parameters, including required spec and output_dir, or optional views, passes, strict, resolution, data_bindings, visual_criteria, and include_manifest. The phrase 'from a FigureSpec' only hints at the spec parameter, leaving all other parameters semantically opaque.

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 ('Capture') and names the resource ('PNG output and compact visual evidence from a FigureSpec'), so an agent can tell this is an observation/render-capture tool. It does not explicitly distinguish it from sibling tools like render_spec or evaluate_visual_patch, and 'compact visual evidence' is somewhat vague.

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 provided on when to use observe_spec versus render_spec, compile_spec, or evaluate_visual_patch. There are no conditions, exclusions, or alternative tool mentions, leaving tool selection entirely 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?

Annotations reveal idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds little behavioral context beyond the hint of rendering; it doesn't explain potential side effects, output format specifics, or interaction with data_bindings. Since annotations partially cover the behavioral profile, the low added value is acceptable. No contradiction.

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 front-loads the action and scope. Every word serves a purpose, conveying both what it does and when to use it. It is efficient and to the point.

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 (6 parameters, no schema descriptions) and lack of annotation coverage for key behavioral aspects, the description is insufficient. The output schema exists, so return values are likely covered, but the lack of parameter guidance and usage details makes it incomplete. An agent would struggle to know how to correctly configure the tool for a given task.

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%, meaning the schema provides no descriptions for parameters. The description does not elaborate on any parameters, leaving the agent to infer the meaning of 'spec', 'output', 'backend', 'strict', 'offline', and 'data_bindings'. The only hint is 'backend-native' which might relate to 'backend', but this is insufficient. With zero coverage, the description must compensate, and it doesn't.

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 action (render) and the target (an artifact), and specifies when it should be used ('when explicitly requested'). While it doesn't name sibling tools like compile_spec or observe_spec, the phrase 'interactive or backend-native artifact' helps distinguish it from potentially similar tools. It is specific enough to convey the core 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 provides clear context: it should be used only when explicitly requested, which helps an agent decide when not to use it. However, it doesn't explicitly mention alternatives or conditions for choosing this over siblings like compile_spec or observe_spec. The guidance is adequate for basic selection but lacks exclusions or comparisons.

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 annotations already declare this tool read-only, idempotent, and non-destructive. The description adds useful behavioral nuance: searches cover local and published recipes, and unavailable recipes produce no matches rather than an error or alternative behavior. It does not address limits or result details, but those are partially covered by the output schema and 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 one tight sentence with two clauses, no filler, and the verb and scope appear immediately. 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 tool with four parameters and zero parameter documentation, this description is too thin to support fully correct invocation. The output schema and annotations mitigate return-shape and safety concerns, but the meaning of `features` and `include_spec` remains unexplained, and 'unavailable' is not defined.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not compensate: it never explains `query`, `limit`, `features`, or `include_spec`. Only the generic term 'Search' hints at the `query` parameter. An agent cannot infer the semantics of `features` or `include_spec` from this definition.

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 the specific verb 'Search', names the resource 'recipes', and delimits the scope as 'local or published'. No sibling tool is a search operation, so it does not need a comparative caveat to be clearly distinguishable.

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 it should be used to find recipes and states an availability-related outcome, but it never explicitly says when to prefer it over alternatives or when not to use it. Since no sibling tool provides a comparable search, the ambiguity is modest but still present.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds that canonical JSON is only included on request, but it does not disclose validation failure behavior, strict vs. non-strict effects, or the impact of compile_check.

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 one short, front-loaded sentence with no filler or repetition. It could contain more detail, but what is included is efficiently written and easy to parse.

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 six parameters and zero schema descriptions, the description should compensate, but it covers only the return spec_id and optional canonical JSON. The output schema helps with return values, but agents still lack guidance on the meaning and interaction of the other five parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden for explaining parameters, but it only hints at the include_spec behavior ('canonical JSON only on request'). The meanings of strict, backend, compile_check, and data_bindings are left unexplained, making correct invocation harder.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Validate'), a resource (spec), and the output (spec_id), and notes that canonical JSON is optional. This distinguishes it from sibling tools like compile_spec or render_spec, though it does not 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 choose validate_spec over compile_spec, get_spec, or other siblings. It lacks preconditions, exclusions, or a recommended use case, so an agent must infer when this tool is appropriate.

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