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

No annotations are provided, so the description carries the behavioral burden. It discloses the analysis dimensions (color contrast, text sizes, touch targets, semantic structure) and states that it produces actionable recommendations. The word 'Analyzes' implies a read-only operation, which is transparent enough for an analysis tool.

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

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

A single, information-dense sentence that front-loads the core action and then enumerates the checks. There is no filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should clarify what the caller receives; it only says 'provides actionable recommendations' without detailing result structure or how level/includeRecommendations affect output. Invocation is feasible because required parameters are in the schema, but output semantics remain vague.

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

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

Schema description coverage is 100%, so the schema already documents all parameters clearly. The description does not add parameter-specific meaning, but it does align with the intent of parameters like includeRecommendations and level by describing WCAG checks and recommendations.

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 ('Analyzes') with a clear resource ('a screen') and domain ('WCAG 2.1 accessibility compliance'), then lists concrete checks. It is distinct from all sibling tools, none of which target accessibility analysis.

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 establishes a clear context: use this tool when you need WCAG compliance analysis of a screen. It does not explicitly state when not to use it, but there are no sibling tools offering the same capability, so the purpose alone provides adequate 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 full behavioral burden, but it only restates the core operation already visible in the schema ('Generates a new screen') and adds minimal context ('for visual consistency'). It does not disclose side effects, output format, failure behavior, or any constraints such as whether an existing screen is modified or a new project must exist.

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, focused sentence that is front-loaded and contains no filler. Every word supports the tool's purpose and key constraint.

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 annotations and no output schema, the description is too thin. It omits what the function returns, any required sequencing beyond 'previously extracted', and how it differs operationally from similar generation tools. An agent would need to open the schema or infer from the name to fully understand 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 100%, so the schema already documents all parameters. The description adds little beyond the schema, though it does reinforce that designContext should come from a previous extraction step. Baseline 3 is appropriate given the high schema 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 states a specific verb ('Generates') and resource ('a new screen') and clearly ties the tool to a design context, distinguishing it from generic generation tools like generate_screen_from_text. It does not name the sibling tool directly, but the phrase 'previously extracted design context' is a strong differentiator.

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 'previously extracted design context' implies a prerequisite and suggests the tool is for visual consistency, but there is no explicit statement of when to use this tool versus alternatives like generate_screen_from_text or apply_design_system. Usage context is implied rather than 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?

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds that it modifies appearance and applies foundational design tokens, which gives some context. However, it does not disclose potential side effects (e.g., overriding existing styles) or reversibility, so it stays at a baseline level given the 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 two sentences long and front-loads the core purpose. The first sentence is a clear action statement; the second adds context about design tokens. No filler or rephrasing of the name, making it efficient and well-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?

Given the annotations (destructive profile), a 100% schema-coverage, and an output schema, the description sufficiently explains the tool's role and behavior. It could mention potential irreversibility, but that is already flagged by destructiveHint. The description is adequate for an agent to select and 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?

Input schema covers all three parameters with detailed descriptions, achieving 100% coverage. The description does not add parameter-level details beyond saying it applies the selected design system to chosen screens, which is already implied. Baseline 3 is appropriate when schema handles the heavy lifting.

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

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

The first sentence clearly states the action: 'Applies a design system to a list of screens.' This distinguishes it from sibling tools like create_design_system and update_design_system, which deal with design systems themselves. The second sentence elaborates the scope (modifying appearance via design tokens), reinforcing a specific and unambiguous 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 says 'Use this tool when the user wants to update one or more screens to match the style of a design system.' This provides clear when-to-use guidance. It does not mention exclusions or alternatives, but the context is specific enough to avoid confusion 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that generation happens in a single operation and maintains design consistency, but it does not mention side effects such as whether screens are newly created or overwrite existing ones, whether partial failures can occur, or what permissions are required.

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 with no redundant content. It front-loads the core purpose and includes the key differentiator of batch generation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, no annotations, and the tool involves nested objects and side effects. The description does not explain what the operation returns, whether the batch is atomic, or how existing screens are affected. More behavioral context is needed for an agent to invoke this safely.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds the notion of 'consistent design language,' which relates to sharedDesignContext but does not explicitly map to it. Baseline 3 is appropriate because the schema carries the semantic weight.

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: 'Generates multiple related screens in a single operation.' This clearly distinguishes it from single-screen generation tools like generate_screen_from_text, though it does not explicitly name a sibling alternative.

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 'multiple related screens' implies when this tool should be used, and 'consistent design language' hints at a use case around design coherence. However, it does not explicitly state when to prefer this over generate_screen_from_text, edit_screens, or generate_variants.

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. It states the output (design HTML) but does not say whether building the site mutates the project, persists routes, creates artifacts, or has side effects—important for a 'build' action.

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 with no filler: the first states the action and mechanism, the second states the return value and intended use. The most decision-relevant information 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?

The description covers the tool's purpose and return value at a high level, but with no output schema, no annotations, and no stated prerequisites or side-effect behavior, an agent is left guessing about persistence, output shape, and whether the build is safe/idempotent. It is adequate but has 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 100%, so both required parameters are already documented in the input schema. The description's 'mapping screens to routes' phrase reinforces the routes parameter's meaning but does not add meaningful new semantics beyond the schema.

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

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

The description uses a specific verb-resource pair ('Builds a site') and explains the core mechanism (mapping screens to routes), which makes the tool's purpose clear. It also hints at differentiation from code-generation siblings by stating it returns design HTML as context for code generation, though it does not explicitly name 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?

The description communicates a clear usage context: invoking this tool produces design HTML meant to feed code generation. It does not explicitly state when to avoid this tool or list sibling alternatives, but the downstream-purpose phrasing gives the agent enough context to choose it appropriately.

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. It transparently states that the operation removes an association rather than deleting the project, which is useful nuance. However, it does not disclose whether the action is reversible, whether it affects other workspace state, or whether confirmation is needed.

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. It immediately conveys the verb, target, and scope, which is ideal for a tool of this 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?

For a zero-parameter tool with no output schema and no annotations, the description is largely complete: it names the action and the exact thing being removed. A short note on reversibility or side effects would improve completeness, but given the low complexity, the current description is adequate.

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 for this dimension is 4. The description adds meaningful implicit context by identifying the current workspace/folder as the operation target, which is the only relevant input. No parameter-level clarification 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 states a specific action ('removes') and a specific target ('Stitch project association from the current workspace/folder'), which is clear and scoped. It does not explicitly name or differentiate from sibling tools like delete_project or set_workspace_project, but the word 'association' signals it is not deleting the project itself.

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 clearly implies when to use the tool: when the current workspace/folder has a Stitch project association that should be removed. It does not mention alternatives or exclusions, but the scope ('current workspace/folder') gives enough context for an agent to distinguish it from project-level operations.

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. It states that the tool 'compares' and 'suggests,' but it does not clarify whether the operation is read-only, whether screens are modified, or what the output/return format looks like.

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

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

The description is a single focused sentence that front-loads the verb and scope with no filler. It is appropriately concise, though the brevity sacrifices useful context about usage and behavior.

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 annotations and no output schema, the description is too thin to fully support correct invocation. It omits the result format, whether the comparison is read-only, and how the optional compareAspects parameter affects the output or suggestions.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds no additional parameter-level meaning beyond what is already in the schema, making the baseline 3 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 identifies the operation ('compares two screens'), the subject ('two screens'), and the outcomes (differences, inconsistencies, harmonization opportunities), which clearly conveys the tool's core function. However, it does not differentiate compare_designs from the sibling tool design_diff, which appears to have a very similar 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 implies the tool is used when comparing two screens, but it gives no explicit guidance about when to choose this tool over alternatives such as design_diff. There are no mention of exclusions, prerequisites, or scenarios where another tool would be more appropriate.

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 indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context: the tool establishes foundational design tokens that apply across all screens, and it requires a follow-up call to update_design_system to actually apply the system. This goes beyond the annotations without contradicting them.

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 purpose statement, a bulleted list of configuration areas, and a bolded instruction section. It is slightly verbose but every part earns its place, and the most important operational detail (call update_design_system after) is highlighted.

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 (nested DesignSystem object, many theme properties) and the presence of an output schema, the description covers the essential user-facing behavior and the critical follow-up workflow. It does not need to explain return values, and parameter details are in the schema. Missing only a note about global vs. project-level creation, which is present in the schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description provides a high-level grouping of parameters (Color Palette, Typography, Shape, Appearance, Design MD) but does not add syntax, formats, or field-specific details beyond what the schema already documents. It's helpful for conceptual understanding but not necessary for correct 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 clearly states 'Creates a new design system for a project' with a specific verb and resource. It lists the types of configuration (color, typography, shape, etc.), but does not explicitly distinguish from sibling tools like update_design_system or create_design_system_from_design_md, and the phrase 'set or update' could imply an update capability.

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 says when to use it: 'when the user wants to set or update the overall visual theme, style, or branding of the application.' It also provides a crucial sequencing guideline: call update_design_system immediately after. However, it does not explicitly state when not to use it or name alternatives like create_design_system_from_design_md.

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 indicate destructiveHint=true, so the mutation risk is known. The description adds that it 'displays the design system in the UI', a useful behavioral detail, but doesn't disclose what specifically might be destroyed or other side effects. This adds some value beyond annotations without contradicting them, warranting a 3.

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 the first clearly stating purpose and the second providing a critical instruction. Every word earns its place, and it is appropriately 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?

The tool has an output schema, so return values are covered elsewhere. The description gives the essential workflow instruction (call upload_design_md first) and states the UI display side effect. It is complete for a create-like tool with moderate complexity, though it could mention error scenarios or what happens on conflict.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description mentions 'user uploaded DESIGN.md file' and links selectedScreenInstance to UploadDesignMd RPC, but this repeats schema information. With high coverage, the baseline is 3, and the description adds marginal 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 clearly states the tool 'Creates a design system for a project, with user uploaded DESIGN.md file, and displays the design system in the UI.' This specific verb+resource combination ('creates a design system') and the qualifier 'from DESIGN.md' distinguishes it from siblings like create_design_system. The instruction to call upload_design_md first further clarifies the workflow.

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 call upload_design_md first, providing clear sequential context. However, it does not mention alternatives or when not to use this tool, so it lacks explicit exclusions. This fits 'clear context, no exclusions' at level 4.

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 (readOnlyHint=false, destructiveHint=true) already indicate this is a mutating operation, and the description aligns with that by saying 'Creates'. It adds minimal behavioral context beyond the annotations, only clarifying the conceptual nature of a project. No additional details about permissions, side effects, or edge cases are provided, but the simple create operation is reasonably transparent given 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 two sentences: the first states the core action, and the second defines the domain concept. Both sentences earn their place and no redundant information is included. It is front-loaded with the action verb, making it 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?

For a simple create tool with one optional parameter, an output schema, and annotations, the description provides sufficient context. It explains what a project is, which helps the agent understand the effect of the operation. However, it omits any mention of what happens upon creation (e.g., whether the project is immediately available) or any prerequisites, though these may be covered by the output schema. Given the low complexity, this is nearly 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?

The input schema has 100% coverage: the single optional parameter 'title' has a clear description ('Optional. The title of the project.'). The tool description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 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 clearly states the action ('Creates') and the resource ('a new Stitch project'), while also defining what a project is (a container for UI designs and frontend code). This distinguishes it from sibling tools like create_design_system and delete_project. The verb+resource combination 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 does not explicitly state when to use this tool relative to alternatives. It implies the agent should use it to create a project, but there is no guidance on when not to use it or how it differs from create_design_system. The definition of a project provides some context, but no actionable usage instructions.

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 destructiveHint=true, and the description adds critical context: 'This action cannot be undone' and requires confirmation before proceeding. This goes beyond the binary destructive flag, clarifying the irreversibility and the need for explicit consent, which is valuable for an agent.

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 brief and front-loaded with the core purpose, followed by a clearly separated instruction block. Every word earns its place; there is no filler or repetition. The structure is clean 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?

For a simple, single-parameter delete operation, the description covers the essential action and irreversibility, and the output schema supplies return-value details. It could mention side effects on associated resources, but given the low complexity and strong annotations/schema, the description is sufficiently 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?

The input schema has 100% description coverage for the only parameter, including format and example. The description itself adds no additional parameter semantics, so the baseline of 3 applies per calibration. The slight mismatch between 'project name' and 'resource name' is a minor redundancy but does not reduce reliability.

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 action ('Deletes') and the target resource ('a specific Stitch project'), distinguishing it from siblings like get_project or create_project. The use of 'using its project name' aligns with the required parameter, though the schema more precisely calls it a resource name; this is a minor terminology nuance that does not obscure 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 gives no explicit guidance on when to use this tool versus alternatives (e.g., update_project, list_projects), nor does it mention prerequisites or scenarios where deletion should be avoided. The confirmation instruction is a procedural call-time guideline, not usage-context guidance, so it does not address this dimension.

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 what the tool returns (a structured diff with added, removed, style, and text changes), which is useful, but it does not clarify whether the operation is read-only, how the diff is structured, or any limitations. The mention of 'by name' is also potentially misleading given the schema uses IDs.

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 with no filler. The primary action is stated first, and the use case is added in a single brief second sentence. Every part 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 description explains the main output categories and use case, but without an output schema it does not fully specify the shape or structure of the diff. It also leaves ambiguity about the 'by name' phrasing versus the ID-based parameters, and does not address how this tool differs from the similar compare_designs sibling.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description's mention of style and text changes maps to the includeStyleDiff and includeTextDiff parameters, but it does not add meaningful detail beyond what the schema already provides.

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 tool's function: comparing two screens and producing a structured diff with added/removed elements, style changes, and text changes. However, it does not differentiate this tool from the sibling tool compare_designs, and the phrase 'by name' conflicts with the actual parameters, which use screen IDs.

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 a clear intended context: 'Useful for tracking design iterations.' It does not explicitly state when to use this tool versus compare_designs or other siblings, nor does it mention any exclusions or alternatives.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a mutation operation ('Edits') but does not disclose side effects, reversibility, permission requirements, or what happens to existing screen content. This is a significant gap for a write 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 a single, short, front-loaded sentence with no wasted words. It is concise, though it omits behavioral and usage details that would make it more 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?

For a simple three-parameter tool with no output schema, the description and schema are sufficient to construct a basic call. However, the lack of behavioral transparency and usage guidance leaves clear gaps for a mutation tool that edits existing content.

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

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

Schema description coverage is 100%, so the schema already documents the three parameters and their basic meanings. The description adds no meaningful parameter-level semantics beyond restating that editing is text-instruction-driven, which aligns with the baseline.

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 action ('Edits'), a clear resource ('existing screens'), and the input mode ('based on text instructions'). It differentiates from siblings like generate_screen_from_text by targeting existing screens, though it does not explicitly name 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?

No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives, prerequisites, or exclusions; the 'existing screens' wording only weakly implies when this tool should be selected.

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 burden. It discloses that the tool fetches each screen's HTML code and screenshot and returns structured data, which is useful, but it does not mention potential performance/cost implications of exporting all screens, output size, or that maxScreens=0 exports everything. 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?

Two sentences contain no filler. The core action is stated first, followed by the output behavior and concrete use cases. 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 tool with full parameter documentation, the description supplies the key missing context: it returns both HTML and screenshots as structured data and is intended for backup/migration. There is no output schema, but the description gives enough shape to set expectations. It could mention the 'all screens' scalability caveat, but that 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?

Schema description coverage is 100%, so the input schema already documents projectId, maxScreens, includeHtml, and includeScreenshots clearly. The description adds no parameter-specific detail beyond the general idea of exporting all screens, so the baseline score of 3 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 states a specific verb and resource: 'Exports all screens from a Stitch project.' It clearly distinguishes this bulk-export tool from sibling tools like list_screens, get_screen, get_screen_code, or get_screen_image by covering all screens with HTML and screenshots.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: 'Useful for backing up or migrating designs.' It does not explicitly name alternatives or when not to use it, but the use cases are strong enough to guide an agent to select this tool for full-project export.

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 of behavioral disclosure. It does not state what the operation returns (ZIP file, JSON bundle, path?), whether it is read-only, whether it triggers generation, or how long/complex the export can be. 'Exports' implies generation, but the exact observable behavior is 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?

Two short sentences, front-loaded with the verb and object, and the second sentence adds a concrete purpose. There is 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?

For a tool with seven parameters, no annotations, and no output schema, the description is minimally viable: it names the artifact and contents. However, it omits return format, output destination, and any performance or limitation caveats, which the agent would need for a confident call.

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

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

Schema description coverage is 100%, so the baseline is 3 even without parameter details in the description. The description does add useful conceptual grouping by naming tokens, components, documentation, and assets, which maps to includeTokens, includeComponents, and includeDocumentation. Still, it does not explain enums or defaults beyond what the schema already states.

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 a specific action — 'Exports a complete design system package from project screens' — and names the composed contents (tokens, components, documentation, assets). It does not explicitly differentiate from direct siblings like export_all_screens or generate_style_guide, but the package-level framing suggests a distinct deliverable.

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 'Ready for developer handoff' implies a meaningful use case, so this is not without guidance. However, it provides no explicit when-to-use versus alternatives, no prerequisites (e.g., that project screens exist), and no mention of when a lighter-weight sibling such as export_all_screens might be preferred.

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. It implies a read-only extraction operation, but it never explicitly states that the screen is not modified, whether permissions are needed, what the output shape is, or what 'variants' means in terms of side effects or generated artifacts.

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 repetition, filler, or low-value detail. The core action, resource, and output emphasis are front-loaded and fit the tool's scope well.

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, all covered by the schema, the description is minimally enough for an agent to attempt a basic call. However, the absence of output-shape context, safety/behavioral details, and usage routing becomes noticeable given there are no annotations and many closely related sibling tools.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds a useful conceptual frame around the componentTypes enum by listing buttons, cards, forms, and inputs, and it hints at output content with 'styles and variants,' but it does not materially clarify the parameters or their relationships beyond what the schema already provides.

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 that this tool extracts reusable UI component patterns from a screen and includes styles and variants as part of the output. The parenthetical examples help identify the domain, but the description does not explicitly contrast itself with sibling tools such as extract_design_context or generate_variants.

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 instead of one of its many siblings, such as extract_design_context, generate_variants, screen_to_react, or get_screen_code. It gives no 'use this when...' statement, no prerequisites, and no exclusion criteria.

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 must carry the behavioral burden. It clarifies the scope of extraction and the intended downstream purpose, but it never explicitly states whether the operation is read-only, whether it modifies the screen, or what the output shape is. 'Extracts' suggests a read operation, but that is implicit rather than 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?

Two tight sentences with no filler. The first sentence front-loads the verb, resource, and a concrete list of extracted elements; the second gives the practical purpose. 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 read-style extraction tool with two required IDs and four optional boolean toggles, the description plus 100% schema coverage is nearly sufficient. The main gap is the absence of any statement about return format or side effects, which would matter more given there is no output schema.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters. The description adds a high-level mapping to the extraction dimensions, but does not provide additional parameter-level detail beyond what the schema already states, which matches the baseline for full 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 uses a specific verb ('Extracts') and a clear resource ('design DNA from an existing screen'), then enumerates concrete dimensions such as colors, typography, spacing, layout patterns, and component styles. It is unambiguous on its own, though it does not explicitly differentiate itself from closely related siblings like extract_components or generate_design_tokens.

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 use case: 'Use this to maintain visual consistency across multiple screens.' This is clear context for when an agent should select the tool, though it does not mention exclusions or directly compare against alternatives such as apply_design_context or generate_design_tokens.

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 is the only source of behavioral information. It transparently states that the tool analyzes an existing screen and generates new separate screens, but it does not disclose whether the original screen is modified, whether the variants are persisted or merely returned, or any side effects beyond generation.

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 sentences with no filler. It front-loads the core action and output, then adds legitimate usage context. Every clause 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 tool is moderately complex with six parameters, no output schema, and no annotations. The description covers purpose and use cases, but it omits important invocation context such as whether generated variants are saved to the project, whether the source screen is left untouched, and what the tool returns. The schema covers parameter details, but behavioral/return expectations are 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 100%, so the schema already documents every parameter. The description adds only a general sense of visual variants and a partial list of component types, which provides minimal additional semantic value beyond the structured fields.

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 specific verbs ('Analyses', 'generates'), identifies the resource (a screen and a target component), and states the output (multiple visual variants as separate screens). It is clear, though it does not explicitly differentiate itself from sibling tools like generate_variants or generate_responsive_variant.

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 use cases: 'Useful for A/B testing or building component libraries.' This gives clear context for when to invoke the tool, though it does not provide exclusions or mention alternative 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?

No annotations are provided, so the description carries the burden. It discloses the behavior: analyzes the color palette, instructs Stitch to regenerate with inverted brightness, adjusted contrast, and preserved brand accents. This gives insight into the transformation logic. However, it doesn't disclose side effects (e.g., whether it modifies the original screen or creates a new one), output format, or failure modes. The description adds some behavioral context but not comprehensive 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 two sentences, front-loaded with the core purpose. The second sentence adds useful behavioral detail about the transformation logic. It's concise and every sentence earns its place, though the second sentence could be slightly more specific about the output.

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 5 parameters and no output schema, the description covers the core purpose and transformation logic but doesn't explain what the output looks like (e.g., whether it returns a new screen ID, modifies in place, or returns an image). It also doesn't clarify the relationship between deviceType and the generated variant. The description is adequate but has 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 100%, so the schema already documents all 5 parameters. The description adds context about the overall behavior (inverted brightness, adjusted contrast, preserved brand accents) which maps to the preserveAccents parameter, but it doesn't add specific parameter-level meaning beyond the schema. Baseline 3 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 clearly states the tool's function: it takes a light-mode screen and generates a dark-mode variant. It specifies the resource (screen) and the action (generate dark-mode variant), and it distinguishes itself from siblings like generate_responsive_variant and generate_variants by focusing on dark mode from a light-mode source.

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 have a light-mode screen and want a dark-mode variant. It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select it over siblings like generate_responsive_variant. A clear exclusion or alternative mention would push it to 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the tool generates tokens, but it does not disclose whether the operation writes files, returns a string, modifies project state, or requires any existing design context. This is a significant gap for a generation tool with no 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 a single, front-loaded sentence with no filler. Every word contributes meaning: action, output formats, and source are all conveyed clearly and efficiently.

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 annotationsa and no output schema, the tool relies entirely on the description for behavioral context. The description omits return format/delivery mechanism, side effects, and selection guidance among many similar sibling tools. Although the schema fully documents parameters, the surrounding context is insufficiently covered.

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

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

Schema description coverage is 100%, so the parameters are already documented. The description adds a little context by naming the formats and the source ('screen's design'), but it does not elaborate on includeSemanticNames, format-specific behavior, or the relationship between projectId and screenId. A baseline 3 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 clearly identifies the action ('Generates design tokens'), the resource ('from a screen's design'), and the output formats (CSS variables, Tailwind config, SCSS, or JSON). It is specific and informative, though it does not explicitly distinguish itself from siblings like screen_to_css_variables or screen_to_tailwind_config.

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 choose this tool over alternatives such as screen_to_css_variables, screen_to_tailwind_config, or export_design_system. The description implies usage when tokens are needed from a screen, but it provides no exclusions, prerequisites, or comparison 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?

No annotations are provided, so the description must carry behavioral disclosure. It explains that templates are a base prompt layered with custom instructions, which is useful, but does not disclose side effects, permissions, or limitations of the generated screen.

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 concise sentences with no redundancy. The purpose is stated first, and the template list is useful. Well-structured for quick consumption.

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 5 parameters and 3 enums, the description is reasonably complete but lacks usage guidance and behavioral context. It explains the core concept well, but an agent would need to infer when to use it versus alternatives.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds context by listing the 10 templates and explaining the customization param, but does not significantly extend beyond the schema's own 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 clearly states the tool 'Generates a screen from a predefined UI template with user customizations,' giving a specific verb and resource. It distinguishes from text-based generation by explicitly mentioning templates, but does not name alternatives like generate_screen_from_text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings such as generate_screen_from_text or batch_generate_screens. It implies usage for faster generation but does not state 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 to fall back on, the description carries the entire disclosure burden. It says the tool 'creates' a variant, which implies non-destructive creation, but it does not state whether the source is preserved, whether design assets are regenerated, what outputs are returned, or any constraints on how the design language is maintained. A simple mutation/creation operation needs more behavioral detail when annotations disclose none.

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?

One sentence, front-loaded with the verb and main outcome, with no filler. Every word contributes to describing the tool's 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?

The schema fully documents inputs, which helps a lot, and the description covers the core purpose. But there is no output schema, no annotations, and no clear differentiation from the overlapping sibling generate_variants. An agent would still have to guess at the practical result of invoking the 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 100% and each parameter, including targetDevice and adaptationStrategy, is thoroughly described with enums and defaults. The description itself adds no parameter-level meaning, so the baseline of 3 is appropriate; the schema already does the heavy lifting.

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

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

The description states a specific verb and resource ('Creates a responsive variant of an existing screen for a different device type') and adds a distinguishing design-language constraint. It is not as explicit as naming alternatives like generate_variants, but the purpose is clearly separable from text-based generation and dark-mode 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 when to use the tool: when you need a device-specific variant of an existing screen. However, it gives no explicit guidance on when not to use it, prerequisites, or how it differs from plausible siblings such as generate_variants and generate_component_variants.

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, but it only states the basic outcome of generating a new screen. It does not reveal whether the screen is persisted, whether it replaces an existing screen, whether it is asynchronous, or what side effects occur in the project.

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, putting the verb and outcome first. It is appropriately concise, though slightly under-specified for the number of sibling tools and lack of annotations.

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 generation tool with no annotations and no output schema, the description is too thin to fully guide an agent. It omits behavioral context, expected output, and any caveats about the generation process, leaving the agent to infer important details from the schema alone.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description adds minimal value by clarifying the prompt is a 'text description of the desired UI,' but it does not explain deviceType or projectId beyond what the schema already provides.

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 ('Generates') and resource ('a new screen') with a specific method ('from a text prompt'). It is understandable and distinguishable from list/get/edit screens, though it does not explicitly contrast with sibling generation tools like batch_generate_screens or generate_from_template.

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 about when to use this tool versus the many related siblings such as generate_from_template, batch_generate_screens, or edit_screens. There are no exclusions, prerequisites, or alternative conditions 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?

With no annotations provided, the description carries the full burden of disclosing side effects and limitations. It only says it 'generates' and 'creates' a visual reference, which implies a non-destructive read-like operation, but does not state whether it modifies the source design, requires specific permissions, or returns any artifact. The lack of an output schema compounds this gap. It offers minimal behavioral context beyond the basic purpose.

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

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

Two sentences, front-loaded with the core purpose, followed by a compact enumeration of content categories. No filler or redundancy. Each 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 generation tool that presumably produces a sizable artifact, the description is thin. It does not explain the output format (though 'format' parameter exists), what the generated style guide includes beyond the generic list, or any constraints on the input design. With no output schema and no annotations, an agent lacks critical details to know what the tool will return or how to interpret success. This is incomplete for the tool's apparent complexity.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds only a conceptual summary (colors, typography, etc.) that roughly maps to the 'sections' parameter but doesn't explain parameter interplay or defaults beyond what the schema states. It slightly misleads by implying 'usage guidelines' is a default when the default sections are actually colors, typography, spacing, and components. This is a net-zero addition over the schema.

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

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

The description states a clear verb ('generates') and resource ('style guide / design documentation screen'), and enumerates content categories (colors, typography, components, usage guidelines). This is unambiguous, though it does not explicitly differentiate from closely related siblings like generate_design_tokens or export_design_system.

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 used when a design already exists and a visual reference is needed. However, it gives no explicit when-to-use guidance versus alternatives, no prerequisites (e.g., that the design must be in a certain state), and does not mention exclusions. The context signal of 'from an existing design' implicitly scopes it but leaves selection reasoning to the agent.

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 indicates a generation operation but does not state whether the source screen is modified, how many outputs are created, what the return value looks like, or whether there are 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 one short sentence with no filler, and the verb is front-loaded. It is efficient, though the brevity leaves gaps that are better handled in usage guidelines and behavioral transparency.

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 annotations, no output schema, and many generation-related siblings, this description is too sparse. It does not explain how count is used, what 'design variants' means concretely, or how this tool differs from related generation tools.

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

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

Schema description coverage is 100%, so the parameters are already well documented and the description does not need to repeat them. The phrase 'existing screen' aligns with screenId, but the description adds no extra semantic detail beyond the schema.

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

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

The description states a specific verb ('Generates') and resource ('design variants of an existing screen'), making the core operation clear. However, it does not differentiate from sibling tools like generate_component_variants or generate_responsive_variant, so the distinction is left to the agent.

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 about when to use this tool versus alternatives such as batch_generate_screens, generate_from_template, or generate_component_variants. The phrase 'existing screen' implies a prerequisite, but there are no explicit conditions, exclusions, or 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, the description carries the full burden of behavioral disclosure, but it only restates what the name already implies. It does not describe the return format, error behavior for missing or invalid IDs, or any read-only guarantee beyond the verb.

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 eight words with no filler and is appropriately front-loaded. Every word earns its place for a simple getter 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?

Adequate for a simple one-parameter fetch, but with no output schema the agent is not told what 'details' actually includes. Given the large sibling list, the lack of any usage context is a clear 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?

Schema coverage is 100% and the single parameter has its own description, so the baseline is 3. The tool description adds no parameter-level meaning, but the schema already documents projectId adequately.

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 ('Gets'), resource ('project'), and singular scope ('a specific Stitch project'), which clearly separates it from list_projects. However, it does not distinguish it from siblings like get_workspace_project or project_summary, so it falls short of full 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?

No guidance is given on when to use this tool versus alternatives such as get_workspace_project or project_summary. The word 'specific' implies by-ID access, but no exclusions or alternative-selection conditions 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. It signals a read operation ('Gets') and notes that the result includes download URLs, hinting at the return payload. It does not mention authentication, URL expiration, or caching, but no mutation or side effect needs to be warned about.

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 crisp sentence, front-loaded with the action and target. Every word earns its place and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read operation with no output schema, the description conveys the key return content ('download URLs') and sufficient context to invoke correctly. A note on the exact response shape would improve it, but nothing essential is missing.

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

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

Schema coverage is 100% – both projectId and screenId are already documented in the input schema. The description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

The description names a specific verb ('Gets'), a precise resource ('a specific screen'), and a distinctive output element ('download URLs'). This clearly separates it from siblings such as list_screens, get_screen_code, and get_screen_image without needing to open any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance is provided. The description does not contrast with get_screen_code or get_screen_image, and there are no conditions or exclusions stated. Usage is only implied by the generic verb 'Gets'.

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 states the return type (raw HTML) and implies read-only behavior via 'Retrieves'. With no annotations, this is adequate but minimal – it doesn't disclose potential limitations like whether the HTML is full document or fragment, or any 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?

Two sentences with no wasted words. The core action and return value are front-loaded, making it immediately scannable and efficient.

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 retrieval tool, the description covers purpose, resource, and return value. It lacks usage guidance and edge-case behavior, but the schema fully documents parameters and the tool's simplicity reduces the need for extensive 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?

Schema description coverage is 100% for both parameters, so the schema carries the parameter meaning. The description adds no additional context about parameter semantics beyond what is already in the schema.

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

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

Description uses a specific verb ('Retrieves') and resource ('HTML code content of a screen'), and clarifies the output is 'raw HTML'. This distinguishes it from sibling tools like get_screen_image or screen_to_react 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?

No guidance on when to use this tool versus alternatives. The phrase 'for code generation or analysis' hints at context but doesn't compare against siblings like screen_to_react or get_screen, nor states 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It does state the output encoding (base64 PNG) and implies a read-only retrieval, but it does not mention permissions, error behavior, or whether the image is a cached preview versus a live screenshot.

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

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

The description is a single, short sentence that states the core action and output format with no filler or redundancy. It is appropriately front-loaded 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?

For a simple two-parameter read tool, the description is nearly complete: the schema documents parameters, and the description covers the return format since there is no output schema. It lacks only some guidance around when to prefer this over sibling tools, which keeps it from a 5.

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

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

Schema description coverage is 100%, so the parameters are already documented. The description adds no extra meaning about how projectId and screenId relate or are used beyond what the schema already states.

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 (retrieves), a specific resource (screenshot/preview image of a screen), and the output form (base64-encoded PNG). This clearly distinguishes it from sibling tools like get_screen or get_screen_code.

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 purpose implies when to use it (when the screen image is needed), but it gives no explicit guidance about alternatives or when not to use it. Compared to siblings such as get_screen or get_screen_code, there is no direct comparison or selection hint.

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 the return behavior (project info or null) and implies a read-only check, but does not explicitly state side effects (or lack thereof) or error conditions. It's transparent about the main outcome but lacks explicit non-mutating confirmation.

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 sentences: the first defines the action and return value, the second provides usage guidance. It is front-loaded, concise, and every word earns its place. No redundancy or 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?

For a simple getter with no parameters, no output schema, and a clear return behavior, the description is complete. It covers what it does, what it returns, and when to use it. There are no missing pieces that would prevent an agent from calling 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?

The tool has zero parameters, so the schema is empty. With no parameters, there is nothing for the description to add beyond what's already obvious. The baseline for 0-param tools is 4, and the description doesn't need to explain missing 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 states a specific verb 'checks' and resource 'existing Stitch project associated with the current workspace/folder', and clarifies the return value (project info or null). It clearly differentiates from siblings like get_project (which likely requires an ID) and list_projects (which lists all) by focusing on the workspace-level association.

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 explicitly says 'Use this at the start of a session to check for existing projects', giving a clear when-to-use context. However, it does not mention alternatives or when not to use it (e.g., when you need a specific project by ID vs. the current one). It's good but not fully explicit about 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?

Annotations already declare readOnlyHint=true, and the description is consistent. The description adds the project scope but does not disclose additional behavior such as falling back to global design systems when projectId is empty; this is covered in the parameter schema instead of the tool description.

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, front-loaded with the action and resource, and contains no redundant or unnecessary information. It is appropriately concise for a simple list 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?

Given the tool's simplicity (one optional parameter, output schema present, readOnly annotation), the description sufficiently captures the core purpose. Additional details like return format are covered by the output schema, and parameter behavior by the schema, so the description is complete for its 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 schema description fully covers the single parameter projectId, including its optionality and behavior when empty. The tool description does not add extra parameter information, so the schema coverage baseline applies.

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

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

The description uses the specific verb 'Lists' and the resource 'design systems' with a scope ('for a given project'), making it clear what the tool does. It differentiates from sibling list tools like list_projects and list_screens by naming the exact 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 implies usage when needing design systems for a project, but it does not explicitly state when to use this over alternatives or provide exclusions. No sibling tool comparisons are made, so guidance is only implied from the purpose.

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 disclosure burden. 'Lists' implies a read-only operation and 'accessible to the authenticated user' clarifies the authorization scope, but it does not mention pagination, ordering, or response format. 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?

A single, well-constructed sentence that states the action and scope with no filler. 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 low-complexity, zero-parameter list tool, the description is essentially complete: it identifies the resource, scope, and auth context. It could add output-shape or pagination details, but these are not necessary 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?

The input schema has zero parameters, so there is nothing to document. The schema coverage is 100% and the description needs no parameter detail; baseline 4 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 the specific verb 'Lists' and names the resource ('all Stitch projects'), adding the scope 'accessible to the authenticated user.' This clearly differentiates it from sibling tools like get_project, create_project, and delete_project.

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 'Lists all Stitch projects' gives a clear context for when to call it: when the agent needs an enumeration of projects available to the user. It does not explicitly name alternatives or exclusions, but the usage context is clear for a zero-parameter list operation.

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. 'Lists all screens' clearly signals a read-only enumeration, but it does not mention return format, pagination, ordering, or any access prerequisites. This is adequate for a simple list tool but not richly 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 one short sentence with no filler or repetition. It front-loads the action and resource and earns every word.

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, low-complexity tool, the description covers the core behavior. However, there is no output schema and no annotation context, so an agent cannot tell what fields a listed screen contains or whether the result is paginated. This is a real but modest 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?

Schema coverage is 100% and the single projectId parameter is already described as 'The Stitch project ID.' The description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

The description states a specific action ('Lists') and resource ('all screens in a Stitch project'), which is clear and distinct from list_projects and get_screen. It doesn't explicitly call out sibling differentiation, but the plural 'screens' versus 'screen' makes the scope reasonably apparent.

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 about when to use this tool instead of get_screen, list_projects, or edit_screens. The description only states what it does, leaving the agent to infer appropriate use from sibling 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly states the output includes descriptions and input schemas, which is useful. However, it does not mention whether the list is sorted, whether it includes only currently available tools, or any performance implications, though these are minor for a listing 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 a single, concise sentence that front-loads the action and resource, then specifies the included content. Every word earns its place with no 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?

For a zero-parameter listing tool, the description is nearly complete. It tells the agent what the tool does and what the output contains. It does not describe the exact return format (e.g., array vs. object), but no output schema is provided, so a bit more detail could help. Still, the core information needed to invoke the tool correctly is 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 tool has zero parameters, so there is no parameter semantics burden. The description correctly implies no inputs are needed. A baseline of 4 is appropriate for a no-parameter tool.

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 ('Lists') and resource ('all available tools') and explicitly mentions what is included ('descriptions and input schemas'). It is unambiguous and clearly distinct from sibling tools like list_projects or list_screens, which target different resources.

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 discovering available tools and their schemas, which is a clear context for use. It does not explicitly state when not to use it or name alternatives, but given the tool's self-referential nature, the usage context is evident and no exclusions are necessary.

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 introduces some behavioral detail: it explains the design consistency score is 'based on color/font overlap across screens,' implying the analysis also crosses screens. But it does not mention side effects, error behavior, or the fact that it may fetch remote HTML (though that is in the schema). The transparency is adequate but not heavy.

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, tightly packed sentence with the main outcome front-loaded ('Returns a high-level summary') followed by a comma-separated enumeration of what that summary covers. There is no filler, repetition, or tangential detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that only fetches summary data and has no output schema, the description is quite complete: it lists what the agent can expect to receive. It does not specify error cases or ordering of the screen list, but those are not critical for correct invocation. The missing output-schema risk is largely mitigated by the explicit return-field enumeration.

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 already covers 100% of parameters with descriptions, so the baseline is 3. The prose goes beyond the schema by linking analyzeConsistency and maxScreensToAnalyze to the definition of design consistency (color/font overlap), effectively explaining why those parameters matter. It adds context that helps an agent set them appropriately, earning one point above the baseline.

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?

Description opens with a concrete verb ('Returns') and a specific resource ('a high-level summary of a Stitch project'), then enumerates the summary's contents (screen count, screen names, common patterns, design consistency score, device type distribution). This clearly distinguishes the tool from siblings like get_project, which likely returns detailed project info, or list_screens, which lists screens only.

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 makes it clear the tool is for high-level summaries, so an agent can infer when to use it. However, it does not explicitly state when to choose it over comparable tools (e.g., get_project, list_screens) nor mention any exclusions, prereqissism, or alternative-recommended 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 provided, the description carries the full burden. It discloses the output structure (a :root block) and the optional dark-mode override, but it does not state whether the operation is read-only, whether it modifies any project state, or what happens if the screen does not exist or lacks design data. The disclosed behavior is accurate but not comprehensive.

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 three sentences, each earning its place: it states the action, the output format, and the optional dark-mode capability. No filler or redundancy, 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?

The tool has no output schema, so the description's mention of 'a complete :root block' partially addresses return value. However, it lacks usage context relative to alternatives, any mention of prerequisites (e.g., screen must exist), and does not clarify whether the returned block is a string, file, or structured object. The complexity is moderate, so the gaps are noticeable but not severe.

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

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

Schema description coverage is 100%, so each parameter is already documented. The description adds context about semantic naming and the categories of variables extracted, which helps understand the output, but it does not add meaning beyond the schema for the parameters themselves. Baseline 3 applies.

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

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

The description opens with a specific verb and resource: 'Extracts CSS custom properties (variables) from a screen's design.' It further specifies the output (a complete :root block with semantic naming for colors, typography, spacing, shadows, and border radii) and mentions optional dark-mode overrides. This clearly differentiates it from siblings like screen_to_react or screen_to_tailwind_config, which target different output formats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives. Overlapping siblings like generate_design_tokens, extract_design_context, and screen_to_tailwind_config exist, but the description does not mention any exclusions or selection criteria. An agent would have to infer from the name and description alone.

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

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

With no annotations, the description carries the full behavioral transparency burden. It discloses the output structure and that it is 'structured output' rather than a direct Plane API call, but it does not explicitly state whether this tool has side effects, requires authentication, or only reads the screen.

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 informative: purpose first, followed by core output constituents, then workflow context. The final sentence is slightly promotional but still clarifies the overall intent, so no sentence feels wasted.

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 output schema, it needs to describe its returns, and it does with title, base64 preview, checklist, and labels. The absence of a precise output contract and clarification about whether the issue is actually created kept it just short of a 5.

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 covers all 7 parameters with descriptions, so the parameter baseline is 3. The description adds that screenName becomes the issue title and that HTML components become the checklist, but it delegates most parameter meaning to the schema rather than adding additional 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 names a specific verb ('Creates'), a specific resource ('Stitch screen'), and a specific deliverable ('structured output ... suitable for creating a Plane issue'). It also enumerates what the output contains—title, base64 image, checklist, labels—which clearly distinguishes it from sibling conversion tools like screen_to_react or get_screen.

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 makes the intended workflow explicit: converting a Stitch screen into a PM-tool-ready issue. However, it does not explicitly name alternatives to avoid, such as get_screen or screen_to_react, so an agent must infer the use case rather than receive an explicit routing rule.

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 accurately describes the transformation (reads HTML, produces React code) but doesn't disclose whether it's read-only, side effects, limitations, or error behavior. The term 'Converts' implies non-destructive, but this isn't explicit.

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. It front-loads the action and object, then specifies outputs and benefits without unnecessary fluff. Every clause adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should clarify return value. It states 'Returns usable React code' but doesn't specify the format (e.g., string, file), error handling, or prerequisites like project/screen existence. Given the tool's simplicity, this is adequate but not comprehensive, especially without annotations to cover safety or 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?

Schema description coverage is 100%, so the baseline is 3. The description doesn't add meaning to any parameter; it only describes output behavior (e.g., Tailwind extraction) rather than parameter details. It doesn't enhance understanding of projectId, screenId, componentName, or includeResponsive beyond what the schema already provides.

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 'Converts' and the specific resource (Stitch screen's HTML) and output (clean React/TSX function component), with distinct details like 'typed props interface' and 'Tailwind CSS classes extracted from inline styles' that differentiate it from sibling tools like screen_to_tailwind_config or screen_to_css_variables.

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 guidance on when to use this tool versus alternatives. The description mentions 'ready to drop into a project' but doesn't compare with other screen conversion tools or state conditions for selection. Siblings like screen_to_plane_issue or screen_to_tailwind_config exist, but no differentiation is 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 present, the description carries the transparency burden and does a solid job: 'Extracts' signals a non-mutating, read-only operation, and the enumeration of analyzed tokens plus the output artifact gives agents a concrete behavioral model. It doesn't mention potential side effects or failure conditions, but not much is hidden for a generation tool.

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

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

A single sentence that front-loads the core action and output and then adds a compact list of analyzed design tokens. Every clause earns its place with no fluff 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 conveys purpose, input, output, and the scope of analysis, which is decent given the simple parameter set. However, without an output schema it stops short of specifying the exact return format (e.g., JSON string vs. code block) or any constraints on the generated config, leaving a notable gap for an agent to resolve.

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 already documents all four parameters with 100% coverage, so the baseline is 3. The description adds no extra explanation of how 'prefix' alters generated classes or what 'includePlugins' recommends, so it does not push above the baseline.

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 ('Extracts'), a specific resource ('a complete tailwind.config.ts'), and the source ('a screen's design'), then lists the analyzed design tokens. This clearly sets it apart from sibling tools like screen_to_css_variables or generate_design_tokens, which target different outputs.

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 intended scenario—deriving a Tailwind config from a screen—but does not explicitly state when to prefer it over similar token-generation tools such as export_design_system or generate_design_tokens. No exclusions or alternative guidance are provided, leaving the choice 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?

No annotations are provided, so the description carries the full burden. It does disclose a key side effect: project info is stored in .stitch-project.json in the current directory. However, it does not mention whether an existing file is overwritten, whether the project must already exist, or any other effects on the workspace.

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 sentences with no filler. It front-loads the operation and adds the storage detail in the second sentence, with every part contributing useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter setter with full schema coverage, the description plus schema provides enough information to invoke the tool correctly: what action to perform, where the data is stored, and the required projectId. The main omission is overwrite behavior, but it is not blocking 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 100%, with both projectId and projectName already described in the input schema. The description adds no additional parameter-level meaning, so the baseline score of 3 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, 'Associates', with a clear resource ('Stitch project') and target context ('current workspace/folder'). This clearly indicates a distinct operation from create_project or clear_workspace_project, though it does not explicitly name any sibling alternative.

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 use case: you want to associate an existing Stitch project with the current workspace/folder. However, it does not explicitly state when to use this tool versus clear_workspace_project or get_workspace_project, nor does it mention prerequisites like whether the project must already exist.

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. It only says 'suggests and applies,' which is ambiguous about whether it modifies an existing screen, generates a new one, or has destructive side effects. It also does not mention any permissions, reversibility, or what happens to the projectId.

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, efficient sentence that front-loads the verb and resource, then adds concrete examples without any fluff. Every word earns its place, and it is neither over- nor under-specified for the information it conveys.

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 too sparse for a tool with no output schema and no annotations. It does not explain what 'applies' means, what the function returns, or how the tool interacts with the provided prompt and projectId. Given the large sibling set, this leaves a noticeable ambiguity that could lead to incorrect 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 100%, so the baseline for this dimension is 3. The description adds a small amount of value by naming example trends, but the schema already documents all parameters with descriptions, enums, and defaults. There is no additional parameter meaning provided in the description.

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 function with a specific verb and resource: 'suggests and applies modern UI/UX design trends to a screen prompt.' It also lists concrete example trends (glassmorphism, bento-grid), which helps the agent form a mental model. However, it does not explicitly distinguish itself from closely related siblings like apply_design_context or generate_dark_mode.

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 a screen prompt needs modern design trends applied, but it offers no explicit guidance on when to choose this over alternatives or when not to use it. There are many design-related sibling tools, and without exclusions or contexts, the agent may find it hard to disambiguate.

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 destructiveHint=true, so the destructive nature is known. The description adds that the tool 'establishes the foundational design tokens that apply across all screens in the project,' explaining the broad scope of the change. It does not detail overwrite semantics, but the annotation covers the destructive aspect, and the added context about cross-screen impact is valuable.

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, a 'Use this tool when...' statement, and a concise bullet list of features. Every sentence adds useful context without fluff or redundancy, making it efficient and 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 the tool's complexity (nested designSystem object) and the presence of an output schema, the description covers the core 'what', 'when', and 'scope' (applies across all screens). It includes the key configurable categories, and the schema fills in the detailed parameter definitions. The description is complete enough for an agent to decide when to invoke the tool and what to include.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description adds high-level conceptual categories (Color Palette, Typography, Shape, Appearance, Design MD) that help an agent map user intent to the relevant fields in the nested designSystem object, going beyond the raw schema by grouping related parameters into thematic areas.

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 'Updates a design system for a project' and specifies the exact use case: 'when the user wants to change the overall visual theme, style, or branding of the application.' It enumerates the configurable aspects (color, typography, shape, appearance, design MD), making the tool's purpose unambiguous and distinct from creation or other operations.

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 says 'Use this tool when the user wants to change the overall visual theme, style, or branding,' which is clear when-to-use guidance. It does not explicitly mention when not to use or name alternative sibling tools like create_design_system, so it lacks explicit exclusions or alternatives, but the context 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the write/destructive nature is known. The description reinforces the upload action but does not disclose additional behavioral traits such as overwrite behavior, prerequisites, or side effects beyond the workflow instruction. Since annotations cover the core safety profile, the description adds only modest 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 two sentences plus one bullet point. It front-loads the core action, then provides usage context and a required follow-up instruction. Every sentence earns its place with no redundant or fluffy text.

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 upload tool with clear purpose, an output schema exists, and annotations cover the destructive hint. The description includes a critical workflow instruction (calling create_design_system_from_design_md immediately after), making the overall interaction complete for an agent. No return-value explanation is needed due to the output schema.

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 100% description coverage for both parameters. The description adds a practical hint for the base64 parameter ('Run `base64 -w 0 `') and reminds about the projectId format ('without the `projects/` prefix'), which slightly elevates it above the schema-only baseline.

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 action: 'Uploads DESIGN.md to a Stitch project.' It uses a specific verb and resource, and distinguishes from siblings by emphasizing the upload step, while explicitly naming the follow-up sibling tool create_design_system_from_design_md. No tautology.

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 the tool: 'Use this tool when the user wants to create a design system from a DESIGN.md file.' It also provides a required sequencing instruction to call create_design_system_from_design_md immediately after, which is valuable. However, it does not mention when not to use the tool or name alternative tools, so it lacks full 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 full burden of behavioral disclosure. It explains what the tool checks and what it reports (violations, compliance percentage, suggestions), but it does not explicitly state side-effect behavior, such as whether the screen is modified, or any prerequisites like requiring a design system to exist in the project.

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 focused sentence that leads with the action and purpose, then lists the checked categories and the outputs. Every phrase earns its place; there is no repetition of schema details or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a moderately complex tool with 7 parameters and no output schema, the description plus fully documented parameters provide enough for an agent to invoke it correctly. It describes the return-style outputs in prose, though it could be more complete by noting whether validation is read-only or what happens when optional approved arrays are omitted.

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

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

Schema description coverage is 100%, so the parameter baseline is 3. The description adds a high-level mapping between 'colors, fonts, spacing, and border-radii' and the approved-array parameters, but it does not add meaningful detail beyond what the schema already provides for each 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 names a specific action ('Validates'), a specific object ('a screen'), and the specific basis ('a given design token set'). It also enumerates the checked dimensions and report outputs, making the tool's purpose unambiguous and distinguishable from siblings like analyze_accessibility or apply_design_system.

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 the tool—when checking a screen's compliance against approved design tokens—but it does not explicitly state when not to use it or mention alternative tools such as apply_design_system or analyze_accessibility. Usage context is present but left to inference.

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