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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It fails to mention whether the tool is read-only, what the output format is, or any side effects. While 'audit' suggests non-mutating, not stating this and lacking return value details leaves significant gaps.

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, well-structured sentence that front-loads the purpose and lists specific audit criteria. Every word adds value, with no redundancy 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?

The tool has one parameter and no output schema, so the description should at least hint at the result format or what the agent can expect as a deliverable. It does not mention the return value, any limitations, or follow-up actions. Given the absence of annotations, this is a notable 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% with the page_text parameter well-described in the schema itself. The description adds context about what the audit examines but does not clarify the parameter's format or constraints beyond the schema. Meets the baseline expectation.

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 audits content quality, enumerating specific dimensions (headlines, structure, copywriting principles, scannability, value proposition clarity). This distinguishes it from sibling audit tools like audit_conversion and audit_visual, which focus on other aspects.

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 a content quality assessment is needed, but does not explicitly state when to use this tool over alternatives or provide exclusions. Given sibling tools like audit_conversion and audit_visual, explicit guidance on selection criteria would improve clarity.

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

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

With no annotations, the description carries the full behavioral burden. It explicitly states 'Returns scored feedback with specific improvements,' which discloses the output nature. The audit framing implies non-destructive read-only behavior, but it does not explicitly confirm this or address any permissions or side effects. Still, it provides enough for a simple audit 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 two sentences, each earning its place. The first sentence leads with the verb, target, and evaluation criteria; the second states the output. There is no filler, repetition, 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 single-parameter tool with no output schema, the description is complete. It covers purpose, evaluation framework, and return type. It could mention that only text is audited, but 'page text/description' already conveys that. Slight room for improvement in noting limitations, but it's 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?

Schema coverage is 100% for the single parameter page_text, so the baseline is 3. The description reinforces the parameter's purpose by using the same phrase 'page text/description' and adds context about the 4 pillars, but it does not add any new format or constraint information 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 the specific verb 'Audit' with a precise target ('page text/description') and names the exact evaluation framework ('4 psychological pillars of conversion'). It clearly distinguishes from sibling tools like audit_visual or check_accessibility by focusing on text and conversion-specific criteria.

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 use for auditing text content against conversion pillars, which is clear context. However, it does not explicitly mention when to prefer this over audit_content or audit_visual, nor does it list exclusions or alternatives. The lack of exclusions makes it a 4 rather than a 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 carries the full burden for behavioral disclosure. It only states the purpose and source of principles, without describing return format, side effects, or any restrictions. This is a significant gap given the lack of 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?

A single, concise sentence that efficiently conveys the tool's purpose and basis. No filler or redundancy. Every word 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?

The tool is simple (one parameter, no output schema), yet the description lacks explicit usage differentiation among siblings and any mention of output format. Given the low complexity, the description is minimally adequate but leaves gaps in contextual guidance.

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 parameter is well-defined in the schema. The description adds no unique parameter semantics beyond what the schema already provides, though it does reference the relevant design principles. Baseline 3 applies per the rubric.

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: 'Get visual design feedback' with a specific scope (layout, color, typography, imagery). It differentiates from sibling audit tools like audit_conversion and audit_content by focusing on visual design aspects, satisfying the specific verb+resource+scope criterion.

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 use for visual design review but provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or recommend other tools for different audit types, so the guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions the output will include HSL values and CSS variables, which is useful, but it doesn't specify the exact return format (e.g., JSON structure, number of colors, or how the palette is delivered). This is a notable gap for an unannotated 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, short sentence (17 words) that immediately states the verb and resource. It avoids unnecessary details and is well-structured, with all key information front-loaded.

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

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

For a simple tool with two parameters and no output schema, the description covers the purpose and inputs but lacks clarity on the exact return structure. Since there is no output schema, the agent must infer the response format from 'HSL values and CSS variables', which is insufficient for reliable invocation. 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 the baseline is 3. The schema already provides clear descriptions for both 'mood' and 'brand_keywords', and the description adds no extra semantics beyond restating these inputs. No compensation needed, but no added value either.

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 ('Generate') and resource ('color palette'), and includes the key inputs (mood, brand keywords) and outputs (HSL values, CSS variables). It is easily distinguishable from sibling tools, none of which focus on palette generation.

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: when a color palette matching a mood and brand keywords is needed. There are no explicit exclusions or alternatives mentioned, but the context is clear because no sibling tool overlaps with this functionality. This fits 'clear context, no exclusions'.

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

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

With no annotations provided, the description bears the full burden of disclosing behavioral traits. It states what is checked but does not explain what the tool returns, whether it is read-only, any side effects, or how the input parameters are processed. This leaves significant ambiguity 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 a single, concise sentence that immediately communicates the tool's purpose. It avoids redundancy and includes no filler, making it highly 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?

The tool has three optional parameters, no output schema, and no annotations. The description covers the core purpose but lacks details on expected return values, usage examples, or how to frame inputs. For a simple check tool, it is minimally viable but leaves gaps in behavioral expectations.

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 provides clear descriptions for all three parameters (colors, layout, typography), achieving 100% coverage. The description adds some context by linking these parameters to accessibility aspects (e.g., color contrast, readability), but it does not clarify how the parameters are interpreted or combined, so it only meets 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 clearly states the tool's function with a specific verb ('Check') and resource ('design accessibility'), and enumerates specific aspects: color contrast, typography readability, and inclusive design principles. While it doesn't explicitly differentiate from sibling tools like audit_visual, the scope is well-defined and understandable.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or context for choosing check_accessibility over sibling audit tools. The only implied usage is from the tool's name and description, which is insufficient.

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. It only mentions the framework used, but fails to disclose output format, number of results, or side effects, leaving the agent without key behavioral context.

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

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

The description is a single, front-loaded sentence with no wasted words, efficiently stating the action and context.

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 generator, the description is adequate but leaves gaps: no mention of return behavior or usage context. Given no output schema and no annotations, more detail would improve completeness.

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 describes both parameters clearly (100% coverage). The description adds no additional meaning beyond noting the emotional trigger basis, so it doesn't improve on schema.

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

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

The description clearly states the tool's function: generating headline formulas, and specifies the basis (emotional triggers from Paul Boag's framework). This distinguishes it from sibling audit and recommendation 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?

No explicit usage guidance is provided. The description implies the tool is for creating headlines, but doesn't state when to prefer it over other tools or any 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?

No annotations are present, so the description carries the full burden. It discloses that the output includes checklist and deliverables, which indicates informational content, but it does not explicitly state whether the operation is read-only, requires permissions, or describes any side effects. For a 'get' tool, this is serviceable 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 two sentences, efficient and front-loaded with the core purpose. It lists phases and inclusions with zero waste 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 simple tool with one enum parameter and no output schema, the description adequately explains both purpose and content (checklist and deliverables). It does not specify the exact format of the checklist/deliverables, but this is acceptable given the tool's simplicity.

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

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

Schema coverage is 100%, and the schema already describes the parameter as 'Design process phase to get guidance for' with an enum listing all values. The tool description repeats the phases but adds no new semantic meaning beyond what the schema 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 verb 'Get guidance' and the resource 'design process phase', enumerating the specific phases (discovery, prototyping, build, live). It distinguishes itself from sibling tools like get_principles or get_testing_plan by focusing on process phases rather than other design concepts.

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 phase-specific guidance is needed, but it offers no explicit when-to-use, when-not-to-use, or comparison to alternatives like get_testing_plan. The context is clear but no exclusions are provided.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states a high-level purpose. It does not describe the output format, how the 'tasks' parameter affects results, or whether this is a read-only advisory 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?

A single sentence that is front-loaded with the purpose and includes a concise list of supported guidance types. No redundant or filler content.

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 output schema and no annotations, the description is thin on behavioral expectations (what does 'guidance' look like?). It also does not explain how to interpret or apply the recommendations, and the optional 'tasks' parameter is not mentioned in the description.

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

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

The input schema documents the 'tasks' parameter with a clear example (100% schema coverage), so the baseline applies. The description does not add any additional meaning or usage context for the 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 clearly states the tool provides information architecture guidance and lists specific sub-services (top task analysis, card sorting, tree testing, navigation best practices). This distinguishes it from sibling tools like get_principles or audit_conversion, though the verb 'Get' is somewhat generic.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies usage for IA-related questions but does not mention exclusions or when another tool (e.g., recommend_layout) 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?

The description adds value by stating that the tool 'Returns structured knowledge' and can retrieve from a 'specific domain or all domains', which are behavioral traits. However, it does not elaborate on the nature of the structured knowledge, possible output size, or any limitations. Since no annotations are provided, more detail would be beneficial.

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 that efficiently communicates the tool's purpose and output scope. Every word contributes meaning, with no unnecessary elaboration.

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

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

Given the tool's simplicity—one optional parameter, no output schema, and no annotations—the description is mostly complete. It covers the source (12 courses), the type of knowledge (design, UX, conversion), and the domain selection. However, it could clarify what 'structured knowledge' means as a return format, which is a minor gap.

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

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

The schema fully describes the 'domain' parameter with an enum and a default value, achieving 100% schema description coverage. The description only reinforces that retrieval can be from 'a specific domain or all domains', adding little beyond the schema, so a 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 tool retrieves design, UX, and conversion principles from a specific set of courses, using the verb 'Get' and a specific resource ('principles'). It distinguishes itself from sibling tools like audit_conversion or get_testing_plan by focusing on principles rather than audits or test plans.

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 explicit guidance on when to use this tool versus alternatives such as get_design_process or get_ia_recommendations. It only implies a use case for obtaining principles, without any context, 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 or output schema, the description must convey behavioral traits. It indicates the tool returns advice, but does not specify the format (e.g., list, paragraphs) or whether it is generative or static. This is a minor gap for a simple advice tool, but not misleading.

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 that immediately names the tool's purpose and key scenarios. No wasted words.

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 one enum parameter and no output schema, the description covers the essential context: what it does and when to use it. It could mention the output format, but it is not necessary for basic usage.

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

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

Schema coverage is 100%, and the only parameter 'situation' has a detailed enum and description. The tool description itself does not add extra parameter context, so the baseline 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 a specific verb ('Get') and resource ('advice for handling stakeholders'), listing four concrete scenarios. This distinguishes it from sibling tools like audit_conversion or build_color_palette, which target different design/UX tasks.

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

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

The description provides clear context by enumerating when to use the tool (presenting, feedback, objections, scope creep). It does not explicitly exclude alternatives, but the listed scenarios strongly imply its domain, and the sibling tools are obviously different in scope.

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 available, the description carries the full burden. It transparently states the tool returns 'specific methods, tools, and how-to guidance', disclosing the output format and scope. Since this is a read-only informational tool, no further behavioral caveats 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 two sentences with the main action front-loaded. It wastes no words and both sentences provide distinct value: the first states the core operation, the second details 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?

The tool is simple with one parameter and no output schema, so the description must explain what is returned, which it does. It mentions the input condition (phase) and the output (methods, tools, guidance), covering all essential context for an agent to invoke it correctly.

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

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

The schema fully covers the required 'phase' parameter with an enum and description, so the schema does the heavy lifting. The description only repeats 'project phase' without adding extra nuance about each enum value or parameter usage rules.

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

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

The description uses a specific verb 'Get' and resource 'recommended testing methods', further clarifying output as 'specific methods, tools, and how-to guidance'. This distinguishes it from sibling tools that focus on audits or recommendations for design, layout, or content.

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

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

The description explicitly ties usage to 'project phase', giving a clear condition for when to call the tool. It does not mention alternatives or exclusions, but the phase-based context is unambiguous and differentiates it from the audit tools that target specific areas.

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 convey behavioral traits. It discloses the scope of recommendations (grid system, CSS approach, etc.) but does not explicitly state read-only behavior, output format, or any side effects, leaving some gaps.

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 that front-loads the primary action and then elaborates with specific examples. Every word contributes value; 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?

This is a simple tool with one parameter, no output schema, and no annotations. The description covers purpose, input basis, and the topics of recommendations, which is sufficient for this complexity level.

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 fully documents the single parameter (content_type) with an enum and description, so the description adds no new parameter semantics. It simply references 'content type' without expanding on the allowed values or formatting.

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 ('Get layout recommendations') and the basis ('based on content type'), and lists the areas covered, making it distinct from generic advice. However, it doesn't explicitly differentiate from sibling tools like get_ia_recommendations, so it lacks sibling differentiation.

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

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

The description implies when to use it (when you have a content type and need layout advice) but provides no explicit guidance on when not to use it or which alternatives exist. It establishes a clear trigger condition but no exclusions.

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