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 the tool 'audits' color pairs, but does not state whether it is read-only, what criteria it uses, what the result format is, 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?

The description is two short, purposeful sentences with no filler or repetition. The batch behavior and high-level use case are front-loaded clearly.

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 output schema and no annotations, the description should explain what an 'audit' produces and by what criteria, but it does not. It is minimally adequate for selecting the tool, but lacks critical return-value and acceptance-criteria information.

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 documents the nested fg, bg, and label properties clearly. The description adds the batch aspect ('múltiplos pares') but no additional parameter-level meaning beyond what the schema provides, so 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 uses a specific action ('Audita múltiplos pares de cor') and clearly identifies the resource: multiple color pairs. It distinguishes itself from sibling tools like check_contrast by emphasizing batch/palette-level auditing.

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 concrete usage context: 'Útil para verificar toda a paleta do tema antes de entregar.' This implies when to use it but does not explicitly mention when not to use it or name 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?

With no annotations, the description carries the full behavioral load. It discloses the output (score, grade, issues with fixes, approved items), implying read-only analysis. However, it does not mention any side effects, authorization, or error handling, though it does provide main behavioral expectations.

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

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

Three concise, front-loaded sentences: purpose, output, and usage. Each sentence adds distinct value without unnecessary detail. The structure is clear and scannable.

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

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

The description comprehensively explains what the tool returns (score, grade, issues, fixes, approved items) and gives a usage context. Given no output schema, this adequately explains the output. It lacks details on edge cases, but for a simple audit tool it is sufficient.

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

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

Schema description coverage is 100% ('Código JSX ou TSX do componente para analisar'), which is adequate. The tool description adds context by explaining what the analysis does with the input, but it does not introduce new parameter-level meaning beyond what's 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?

The description clearly states it analyzes JSX/TSX code to detect AI-generated patterns, distinguishing it from siblings focused on themes and contrast. The verb 'Analisa' plus a specific resource makes the tool's purpose unambiguous.

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

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

It explicitly instructs to use the tool 'antes de entregar qualquer componente React' (before delivering any React component), giving a clear when-to-use. It does not explicitly mention when not to use it, 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses the return values (ratio, WCAG level, correction suggestion) and conditional behavior when contrast fails, which is sufficient for a read-only check tool. However, it does not mention error handling or color-format validation.

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

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

The description is concise and front-loaded: three short sentences each add value, with no fluff or repetition. It communicates purpose, usage context, and return behavior 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?

For a simple 3-parameter tool with no output schema and no annotations, the description covers the essential context: purpose, use case, and return semantics. It does not explicitly describe the role of the optional largeText parameter, but the schema already explains it, so the description is largely complete.

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

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

Schema description coverage is 100%, so the input schema already documents all parameters. The description adds no additional meaning beyond what the schema provides, such as how largeText affects thresholds or format constraints, 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 a specific action ('Verifica se um par de cores tem contraste adequado') targeting a concrete resource (color pairs) with an explicit standard (WCAG AA/AAA). It also distinguishes itself through the text-on-background use case, separating it from sibling tools like audit_color_pairs.

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 explicit guidance on when to use the tool: 'Use sempre que definir cor de texto sobre fundo.' This gives clear context but does not mention when not to use it or name specific alternatives, so it falls short of 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 burden. It implies a read-only retrieval via 'Retorna' and lists available presets, but it does not disclose output format, error behavior, or side effects. For a simple getter this is acceptable but not rich.

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

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

The description is two short sentences with no filler. The first sentence states the core function, and the second lists the valid options. 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 single-parameter retrieval tool, the description is mostly complete: it explains the purpose and enumerates valid inputs. It lacks usage context and return structure, but the simplicity of the tool makes this 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 already fully documents the preset parameter with an enum and a description ('Nome do preset'). The description repeats the enum values, adding no new parameter-level meaning beyond the schema. Baseline 3 applies due to 100% 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 clearly states the tool's function: 'Retorna tokens completos de um preset específico' (returns complete tokens for a specific preset). It also lists the valid presets, which helps distinguish it from siblings like list_presets or suggest_theme.

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 list_presets or suggest_theme. The description only states what the tool does, not when it should 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 transparency burden. The verb 'Lista' strongly implies a read-only operation, and 'com suas descrições' discloses the content of the return value. However, it does not mention output structure, ordering, or any potential limitations.

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 in Portuguese. Every word contributes meaningful information: the action ('Lista'), the scope ('todos os presets de tema'), and the output detail ('com suas descrições'). 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 zero-parameter listing tool with no output schema, the description is sufficiently complete: it states what is listed and what the descriptions include. It could add more about the return format or sorting, but this is a simple tool and the description covers the essential context.

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

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

The tool has zero parameters, so the input schema has nothing to document. Per the baseline for zero-parameter tools, a score of 4 is appropriate; the description does not need to explain parameter meanings that do not exist.

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 ('Lista') and a specific resource ('todos os presets de tema disponíveis'), and it adds what the output includes ('com suas descrições'). This clearly differentiates it from sibling tools like get_theme or suggest_theme, which perform different 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?

There is no explicit guidance on when to use this tool versus alternatives such as get_theme or suggest_theme. The use case is only implicit from the action 'Lista', with no mention of when it should or should not be used.

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 transparency burden and does disclose core behavior: it removes generic patterns and makes text sound human/contextual. It gives concrete examples of patterns removed, which helps set expectations, although it doesn't state output shape or edge-case behavior.

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

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

Three short sentences front-load the main action, then give concrete examples and target UI contexts. Every sentence adds value and the structure is easy to scan.

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

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

For a text-refinement tool with 5 params and no output schema, the description covers purpose, target contexts, and expected transformations. It could mention the returned value or limitations (e.g., not for long-form copy), but the description is sufficient for basic selection and 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 baseline is 3. The description adds broader context about intended inputs (generic UI text and examples), but does not add parameter-specific 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?

Description uses a specific verb ('Melhora'/improves) and identifiable resource ('textos genéricos de UI'), then explicitly names the transformation ('Remove padrões como...'). It clearly distinguishes refine_copy from sibling tools by focusing on improving existing UI text rather than suggesting or auditing.

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 concrete contexts: 'labels de botões, placeholders, mensagens de erro e empty states.' It does not mention exclusions or alternative sibling tools, but the stated use cases are clear enough for selection.

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?

Não há anotações, então a descrição assume o ônus. Ela informa que retorna um placeholder contextualizado (exemplo), mas não detalha o comportamento de fallback para campos não listados na enum, nem o formato exato da resposta. Há menção de idioma padrão, mas isso também está no schema.

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

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

A descrição é curta e direta, contém um exemplo e instrução de uso. Apenas duas frases, sem redundância, mas poderia ser mais clara sobre o retorno em caso de campo não suportado.

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?

Ferramenta simples com 2 parâmetros cobertos pelo schema, mas sem anotações e sem output schema. A descrição cobre o essencial, mas não discute casos limite (ex: campo inválido, comportamento multi-idioma). Suficiente para uso básico.

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?

Embora o schema cubra 100% dos parâmetros, a descrição contextualiza o uso do placeholder (exemplo concreto 'pedro@empresa.com' para email) e menciona o idioma padrão. Isso adiciona um pouco além do schema, que lista os valores possíveis de fieldName mas não o propósito prático.

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?

O description identifica claramente o propósito: sugerir placeholders contextuais para formulários, com um exemplo concreto. Distingue-se dos irmãos ao focar em 'inputs, textareas ou selects', mas não menciona explicitamente como difere de outras ferramentas de copy como refine_copy.

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?

A descrição instrui 'Use sempre que criar inputs, textareas ou selects', fornecendo um contexto claro de uso. No entanto, não menciona quando NÃO usar ou alternativas específicas, como refine_copy para copy mais ampla.

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 format: complete tokens, CSS variables, and Tailwind config, giving the agent a clear expectation of what will be returned. It does not explicitly state side-effect-free behavior, but the constructive nature of 'suggest' implies it, and the output details add valuable 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 concise sentences that state the purpose and output format without unnecessary detail. It is front-loaded with the main action and delivers the essential information in a compact manner.

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, the description adequately conveys what the agent will receive: tokens, CSS variables, and Tailwind config. It does not explain how parameters affect the output, but given all parameters are optional and the schema descriptions are clear, this is sufficient. A minor gap is not specifying default behavior when no parameters are provided, but this is not critical.

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

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

The schema has descriptions for all four parameters (100% coverage), so the description does not need to repeat them. The description only mentions 'based on the type of app,' which aligns with the appType parameter but does not add relationships or usage details beyond the schema. Thus, it adds marginal value 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 clearly states the tool suggests a visual theme preset based on the app type, and specifies the output includes tokens (colors, fonts, radii, shadows, spacings) and CSS/Tailwind config. This distinguishes it from siblings like get_theme (retrieving a specific theme) and list_presets (listing existing presets), making the purpose unambiguous.

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

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

The description implies usage by mentioning 'based on the type of app,' giving context that this tool generates a suggestion when an app type is known. However, it does not explicitly mention when to use it over alternatives like get_theme or list_presets, nor does it provide any exclusions or alternative recommendations.

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