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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering the safety profile. The description adds useful context about what fields are searched (nome, código, descrição) and the return format, but doesn't mention rate limits, authentication needs, or pagination behavior beyond the offset parameter. With good annotation coverage, this earns a baseline 3 for adding some 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?

Well-structured with purpose statement, detailed Args section, Returns explanation, and Examples. Every section earns its place. Could be slightly more concise by integrating the purpose more tightly with the Args, but overall efficient and well-organized.

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

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

Given the tool's moderate complexity (search with multiple filters), the description provides complete guidance: clear purpose, detailed parameter documentation with examples, return format explanation, and usage examples. With annotations covering safety aspects and the description handling parameter semantics thoroughly, this is complete enough for an agent to use the tool effectively.

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

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

With 0% schema description coverage (the schema has no descriptions at the top level, only within nested definitions), the description carries the full burden. It provides comprehensive parameter documentation in the Args section with clear explanations, examples, and defaults for all 7 parameters. This fully compensates for the schema coverage gap and adds significant value beyond what the nested schema definitions provide.

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

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

The description clearly states the tool's purpose: 'Busca peças na base AutoPeças por texto livre (nome, código ou descrição)' - specific verb ('Busca') and resource ('peças na base AutoPeças') with scope ('texto livre'). It distinguishes from siblings like autopecas_listar_pecas (which likely lists all parts without search) and autopecas_obter_detalhes (which gets details for a specific part).

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 for when to use this tool: for free-text search across name, code, or description. It doesn't explicitly state when NOT to use it or name alternatives, but the context is sufficiently clear given the sibling tools. The examples help illustrate appropriate usage scenarios.

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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds context about the output including counts (total and in-stock), which is useful behavioral information not in the annotations. However, it doesn't mention rate limits, authentication needs, or pagination behavior. With annotations handling core traits, the description adds some value but not comprehensive behavioral details.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by parameter details in a structured 'Args:' section. It avoids redundancy and wastes no words. However, the parameter explanation could be slightly more integrated rather than a separate block, but overall it's efficient and well-organized.

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 low complexity (one parameter, read-only operation), annotations cover safety and idempotency, and an output schema exists (so return values needn't be explained), the description is reasonably complete. It specifies the resource (categories), the data included (counts), and the parameter. The main gap is lack of usage guidelines, but overall it provides sufficient context for the agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description carries the burden. It documents the single parameter 'formato' with values 'markdown' or 'json', which matches the schema's enum. This adds meaning beyond the bare schema. However, it doesn't explain the default value (markdown) or the implications of choosing each format. Since there's only one parameter and it's fully described, this meets the baseline for adequate 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 verb 'Lista' (lists) and the resource 'todas as categorias de peças' (all categories of parts), including what information is provided (total count and in-stock count per category). It distinguishes from sibling tools like 'autopecas_listar_marcas' (list brands) and 'autopecas_listar_pecas' (list parts) by specifying categories rather than brands or individual parts. However, it doesn't explicitly differentiate from other category-related tools if they existed, but none are present in the sibling list.

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 doesn't mention prerequisites, context for usage, or compare it to other tools like 'autopecas_buscar_peca' (search part) or 'autopecas_verificar_estoque' (check stock). The agent must infer usage based on the purpose alone, which is insufficient for clear decision-making.

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

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

The annotations already provide excellent behavioral information (read-only, non-destructive, idempotent, closed-world), but the description adds valuable context about the output format options ('markdown' or 'json') and the part-count feature. It doesn't contradict annotations and provides additional implementation details that help the agent understand what to expect.

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 perfectly structured with a clear purpose statement, organized parameter documentation, and practical examples. Every sentence earns its place, and information is front-loaded with the core functionality stated first. The formatting with sections (Args, Exemplos) enhances readability without unnecessary verbosity.

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 (list operation with filtering), the presence of comprehensive annotations, and an output schema (implied by 'Has output schema: true'), the description provides complete context. It covers purpose, parameters with examples, and behavioral aspects, making it fully adequate for an agent to understand and use this tool correctly.

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

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

With 0% schema description coverage, the description carries the full burden of parameter documentation. It clearly explains both parameters: 'categoria' for filtering by category with an example, and 'formato' for output format with valid values. The examples demonstrate practical usage, though it could provide more detail about the 'categoria' parameter's behavior.

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

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

The description clearly states the specific verb ('Lista todas') and resource ('marcas/fabricantes') with additional context about counting parts per brand. It distinguishes from sibling tools like 'autopecas_listar_categorias' and 'autopecas_listar_pecas' by focusing specifically on brands/manufacturers rather than categories or parts.

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 about when to use this tool (to list all brands with part counts) and includes examples showing both filtered and unfiltered usage. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'autopecas_buscar_peca' for searching specific parts instead of listing brands.

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, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context about pagination support and optional filtering capabilities, though it doesn't mention rate limits or authentication requirements. No contradiction with annotations exists.

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 perfectly structured: a clear purpose statement upfront, followed by organized parameter documentation with examples. Every sentence earns its place, with no redundant information. The bilingual presentation (Portuguese description with Portuguese parameter names) maintains consistency.

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 this is a read-only listing tool with comprehensive annotations (readOnlyHint, destructiveHint, idempotentHint) and an output schema exists, the description provides complete context. It covers purpose, parameters with examples, and behavioral aspects like pagination and filtering, making it fully adequate for agent usage.

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

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

Schema description coverage is 0%, so the description carries full burden for parameter documentation. It provides clear explanations for all 6 parameters with examples, but doesn't add semantic context beyond what's already explicitly listed in the Args section. The examples help illustrate usage but don't deepen understanding of parameter interactions.

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 ('Lista') and resource ('todas as peças cadastradas na base AutoPeças'), specifying it's a comprehensive listing operation. It distinguishes from siblings like 'autopecas_buscar_peca' (search specific) and 'autopecas_listar_categorias'/'autopecas_listar_marcas' (list metadata rather than parts).

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 for usage ('com paginação e filtros opcionais') and includes practical examples that illustrate when to apply specific filters. However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'autopecas_buscar_peca' for targeted searches.

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, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds minimal behavioral context beyond this, such as the output format options, but doesn't detail error handling, rate limits, or authentication needs. With annotations providing core traits, the description adds some value but not rich behavioral disclosure.

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 purpose statement, args section, and examples, all in a compact format. Every sentence adds value, but the example could be more informative (e.g., showing format usage). It's front-loaded and efficient with minimal waste.

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 low complexity (1 parameter), rich annotations, and presence of an output schema, the description is reasonably complete. It covers purpose, parameters, and examples, though it could benefit from more usage context or error details. The output schema reduces the need to explain return values, making this 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 description coverage is 0%, so the description carries full burden. It clearly explains both parameters: 'codigo' as the unique part code with an example, and 'formato' as 'markdown' or 'json' options. This adds essential meaning beyond the bare schema, though it could elaborate on default values or constraints.

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 specific action ('Retorna todos os dados') and resource ('uma peça específica'), distinguishing it from siblings like 'autopecas_listar_pecas' (list all) and 'autopecas_buscar_peca' (search). It specifies retrieval by unique code, making the purpose unambiguous and differentiated.

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 detailed data for a specific part is needed, but lacks explicit guidance on when to use this versus alternatives like 'autopecas_buscar_peca' or 'autopecas_verificar_estoque'. No exclusions or prerequisites are mentioned, leaving usage context partially inferred.

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, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it explains the two distinct return modes (detailed vs. summary), mentions alert symbols (⚠️) in detailed mode, and specifies output formats ('markdown' or 'json'). However, it doesn't mention rate limits or authentication requirements.

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 perfectly structured: a clear opening sentence stating the dual functionality, followed by conditional logic explanation, parameter documentation with bullet points, and practical examples. Every sentence adds value with zero redundancy, making it easy to scan and understand.

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

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

Given the tool's moderate complexity (conditional behavior based on parameters), rich annotations covering safety and idempotency, and the existence of an output schema (which handles return value documentation), the description is complete. It explains all key behaviors, parameter interactions, and provides usage examples without needing to duplicate what's in structured fields.

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

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

With 0% schema description coverage (the schema has no descriptions at the top level), the description carries the full burden. It provides excellent parameter semantics: explains that 'codigos' triggers detailed stock checks with alerts, omitting it triggers category summaries, 'categoria' filters summaries, and 'formato' controls output format. The examples further clarify parameter usage with concrete scenarios.

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

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

The description clearly states the tool's purpose with specific verbs ('verifica estoque', 'exibe resumo geral') and distinguishes it from siblings by focusing on inventory checking rather than searching, listing, or obtaining details. It explicitly describes two distinct behaviors based on parameter input.

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 each mode: use with 'codigos' for specific part stock checks, omit 'codigos' for category summaries, and use 'categoria' to filter summaries. It distinguishes this from sibling tools like 'autopecas_listar_pecas' or 'autopecas_obter_detalhes' by focusing on stock verification rather than listing or detailed information retrieval.

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 this is a non-destructive, idempotent write operation. The description adds valuable context beyond annotations: it specifies this is a WRITE operation, requires EDITOR permissions for the Service Account, and only updates the Status_Limpeza field while locating by ID_Leito. It doesn't mention rate limits or error handling specifics.

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

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

Well-structured with purpose statement, operational context, requirements, parameters, returns, and examples. The description is appropriately sized but could be slightly more concise in the operational context section. Every section 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?

Given this is a write operation with 1 parameter object containing 2 fields, 0% schema coverage, no output schema, and annotations covering safety aspects, the description is complete. It explains what the tool does, when to use it, permission requirements, parameter meanings with examples, and return 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?

With 0% schema description coverage, the description fully compensates by clearly explaining both parameters in the Args section with examples. It defines leito_id as the bed ID to update and status_limpeza as the new cleaning status value, providing concrete examples like 'Concluído', 'Pendente', 'Em Andamento'.

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 specific action ('Atualiza o campo Status_Limpeza'), the resource ('de um leito na planilha Google Sheets'), and distinguishes from siblings by focusing on updating only the cleaning status field rather than listing, notifying, or checking availability like other leitos_* 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 provides clear context about when to use this tool (to update cleaning status of a specific bed) and mentions it's equivalent to a specific N8N node, but doesn't explicitly state when NOT to use it or compare with alternatives like leitos_obter_detalhes_leito for read 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?

The description adds valuable context beyond annotations by specifying authentication requirements (GMAIL_USER and GMAIL_APP_PASSWORD in .env), pointing to app password creation, and mentioning it's equivalent to a specific node. Annotations already indicate it's not read-only, not destructive, not idempotent, and open-world, but the description provides practical implementation details.

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

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

The description is well-structured with clear sections (overview, requirements, parameters, examples) and appropriately sized. Every sentence adds value, though the equivalence statement could be slightly more concise. The information is front-loaded with the core purpose first.

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

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

Given the tool's complexity (email sending with authentication requirements), the description provides complete context including purpose, requirements, parameters with examples, and practical usage guidance. With an output schema present, the description appropriately focuses on input and behavioral aspects rather than return values.

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

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

With 0% schema description coverage, the description fully compensates by clearly documenting all three parameters (destinatario, assunto, mensagem) with their purposes and providing concrete examples. The description adds essential meaning that the bare schema lacks, making parameter usage clear.

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 specific action ('Envia notificação por e-mail via Gmail SMTP') and distinguishes it from sibling tools like 'leitos_enviar_sms' by specifying the email transport method. It identifies the exact resource (email notifications) and mechanism (Gmail SMTP).

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 about when to use this tool (sending email notifications via Gmail SMTP) and mentions it's equivalent to a node available to all agents. It doesn't explicitly state when NOT to use it or name specific alternatives, though the sibling tool 'leitos_enviar_sms' suggests an alternative notification channel.

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 provide basic hints (readOnlyHint=false, destructiveHint=false, etc.), but the description adds valuable behavioral context: it specifies the external API dependency (Twilio), mentions the 160-character limit for simple SMS (though schema also covers this), and provides a concrete use case example ('Avisar por SMS que UTI-05 foi liberada'). This goes beyond what annotations convey about the tool's operational characteristics.

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

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

The description is well-structured with clear sections (purpose, prerequisites, args, examples) and uses bullet points for readability. Every sentence adds value, though it could be slightly more concise by integrating the example more tightly with the parameter explanations.

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 (external API integration, environment dependencies) and the presence of an output schema (which handles return values), the description is complete. It covers purpose, prerequisites, parameters with examples, and behavioral context, leaving no significant gaps for agent understanding.

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

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

With 0% schema description coverage (schema properties have descriptions but the overall param object doesn't), the description carries the full burden. It clearly explains both parameters (destinatario and mensagem) with format examples and constraints, effectively compensating for the schema gap. The example further illustrates proper parameter usage.

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 specific action ('Envia SMS via Twilio REST API') and resource (SMS messages), distinguishing it from sibling tools like 'leitos_enviar_notificacao' which might use different notification channels. The description explicitly names the equivalent node in another system, further clarifying its purpose.

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

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

The description provides clear context about when to use this tool (for sending SMS via Twilio) and mentions specific environment variable prerequisites (TWILIO_ACCOUNT_SID, TWILIO_AUTH_TOKEN, TWILIO_FROM_NUMBER). However, it doesn't explicitly state when NOT to use it or name alternatives among sibling tools, though the context suggests it's for SMS specifically versus other notification methods.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context beyond this: it explains the tool's equivalence to an N8N agent, details three specific report types with parameter mappings, and provides usage examples. However, it doesn't mention rate limits or authentication needs, keeping it from a perfect score.

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, usage guidelines, parameter details, and examples. It's appropriately sized for the tool's complexity, but the 'Args' section could be integrated more seamlessly into the flow. Every sentence adds value, though minor redundancy exists in listing parameter values.

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

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

Given the tool's moderate complexity, rich annotations, and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage scenarios, parameter semantics, and examples, leaving no gaps for an AI agent to understand and invoke the tool correctly in context with its siblings.

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

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

With schema description coverage at 0%, the description fully compensates by detailing all parameters in the 'Args' section with clear explanations, default values, and allowed values. It maps parameters to specific use cases (e.g., status_ocupacao for availability reports) and provides practical examples, adding significant meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Lista apenas os leitos do tipo Enfermaria (Tipo_Quarto = 'Enfermaria')'. It specifies the exact resource (beds of type Enfermaria) and distinguishes it from siblings like 'leitos_listar_leitos' (all beds) and 'leitos_listar_uti' (UTI beds), making the scope explicit and differentiated.

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 this tool versus alternatives. It mentions 'Equivale ao Agent Enfermaria do N8N' for context, lists three specific report scenarios with parameter mappings, and references 'leitos_resumo_ocupacao' as an alternative for occupancy reports without filters. This clearly defines use cases and 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, destructiveHint=false, and idempotentHint=true, covering safety aspects. The description adds valuable behavioral context: it specifies the output columns, mentions pagination behavior, and indicates the tool provides a 'complete view' without restrictions. However, it doesn't mention rate limits or authentication requirements.

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

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

The description is well-structured with clear sections: purpose statement, scope clarification, output columns, parameters with details, and usage examples. Every sentence adds value, though the parameter listing is somewhat verbose. The information is front-loaded with the most important details first.

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

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

Given the tool's complexity (multiple filters, pagination, output format options) and the presence of both comprehensive annotations and an output schema, the description is complete. It covers purpose, differentiation from siblings, parameter semantics, output structure, and usage examples. The output schema will handle return value documentation, so the description appropriately focuses on usage 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 description coverage is 0%, but the description compensates by listing all parameters with their purposes, allowed values, and defaults. It provides concrete examples of how to use each filter parameter. However, it doesn't explain parameter interactions or edge cases beyond what's implied by the examples.

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

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

The description clearly states the tool's purpose: 'Lista todos os leitos hospitalares com paginação e filtros combinados.' It specifies the verb (list), resource (hospital beds), and scope (with pagination and combined filters). It distinguishes from siblings like 'leitos_listar_enfermaria' and 'leitos_listar_uti' by noting it's a 'complete view' without room type restrictions.

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 this tool versus alternatives. It states it's the 'complete view equivalent to Agent Diretoria do N8N — without room type restriction,' implying it's more comprehensive than filtered siblings. It also gives specific examples of filter combinations, helping the agent understand appropriate use cases.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable context beyond this: it explains the tool's equivalence to 'Agent UTI do N8N', describes the two report types it supports, and provides concrete examples of how to use it. While it doesn't mention rate limits or authentication needs, it adds meaningful behavioral context that helps an agent understand what this tool does in practice.

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 efficiently organized. It starts with the core purpose, provides equivalence context, lists supported reports, then presents parameters and examples. Every sentence adds value: the first states purpose, second provides system context, third explains report types, and the examples demonstrate practical usage. No wasted words or redundant 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?

Given the tool's complexity (filtered listing with multiple parameters), the description is remarkably complete. It explains what the tool does, when to use it, provides parameter semantics (compensating for 0% schema coverage), and includes practical examples. With annotations covering safety aspects and an output schema presumably handling return values, this description provides excellent contextual completeness for agent usage.

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

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

Schema description coverage is 0%, so the description carries the full burden. It provides a clear 'Args' section with all 5 parameters, their types, and brief explanations. The examples demonstrate how to use key parameters like 'status_ocupacao'. While it doesn't explain every detail (like the 1-100 range for 'limit'), it provides substantial semantic information that compensates well for the lack of schema descriptions.

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

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

The description clearly states the tool's purpose: 'Lista apenas os leitos do tipo UTI (Tipo_Quarto = "UTI")' - specific verb (listar/lista) and resource (leitos UTI). It explicitly distinguishes from sibling tools like 'leitos_listar_leitos' (all beds) and 'leitos_listar_enfermaria' (different bed type). The equivalence to 'Agent UTI do N8N' provides additional context about its role.

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

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

The description provides explicit guidance on when to use this tool versus alternatives. It mentions two specific report types from a menu ('Relatório de Dias Internados' and 'Quantidade de Pacientes Internados') and gives three concrete examples with parameter configurations. The examples show different use cases: 'Pacientes na UTI', 'Leitos de UTI disponíveis', and 'Dias de internação na UTI'.

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 excellent coverage (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false), so the bar is lower. The description adds useful context about the output format options ('markdown' or 'json') and provides concrete examples of parameter usage, which helps the agent understand how to invoke it correctly. No contradictions with annotations.

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

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

Perfectly structured and front-loaded: purpose statement first, then Args section with parameters, then Exemplos with concrete usage. Every sentence earns its place - no fluff, all actionable information. The bilingual presentation (Portuguese description with clear structure) is 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?

Given the tool's simple read-only nature, excellent annotation coverage, clear parameters, existence of an output schema (so return values don't need description), and comprehensive sibling context, this description is complete. It provides everything needed to select and invoke this tool correctly among the available bed management tools.

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

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

Schema description coverage is 0%, so the description carries full burden. It documents both parameters (leito_id and formato) with examples for leito_id and enum values for formato, which adds meaningful semantics. However, it doesn't explain the 'params' wrapper object structure or provide deeper context about parameter constraints beyond what's evident from examples.

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 specific action ('Retorna todos os dados' - returns all data) and resource ('de um leito específico' - of a specific bed), distinguishing it from sibling tools like 'leitos_listar_leitos' (list beds) or 'leitos_verificar_disponibilidade' (check availability). It precisely identifies the lookup mechanism ('pelo campo ID_Leito' - by the ID_Leito field).

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 for when to use this tool: when detailed information about a specific bed is needed, identified by its ID. It doesn't explicitly state when NOT to use it or name alternatives, but the context is sufficiently clear given the sibling tools (e.g., use list tools for overviews, this for details).

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 valuable behavioral context beyond what annotations provide. While annotations indicate read-only, non-destructive, idempotent operations, the description explains this is a 'dashboard' view with two specific panels (occupancy and cleaning), shows what counts are displayed, and mentions it supports specific agent reports. This gives the agent a clear understanding of what data will be returned and how it's organized.

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

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

The description is well-structured and front-loaded: it immediately states the tool's purpose, then details the two panels, provides context about agent views, documents parameters with clear formatting, and includes practical examples. Every sentence adds value 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?

Given the tool's complexity (aggregated dashboard with filtering), the description provides complete context. It explains what data is returned (occupancy and cleaning counts), documents both parameters thoroughly despite 0% schema coverage, provides usage examples, and mentions agent context. With an output schema present, the description appropriately focuses on what the tool does rather than return value details.

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

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

With 0% schema description coverage, the description carries the full burden of explaining parameters. It successfully documents both parameters: 'tipo_quarto' as an optional filter by room type with examples, and 'formato' as either 'markdown' or 'json' with the default implied. The examples provide practical usage guidance, though it could be more explicit about the default 'markdown' format.

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

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

The description clearly states the tool's purpose: it provides a dashboard of occupancy and cleaning status grouped by room type, with specific counts for Status_Ocupacao and Status_Limpeza. It distinguishes itself from siblings like leitos_listar_leitos or leitos_verificar_disponibilidade by focusing on aggregated summary views rather than detailed listings or availability checks.

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 for when to use this tool: it's equivalent to the 'Agent Diretoria' view and supports reports for 'Agent Enfermaria'. It doesn't explicitly state when not to use it or name specific alternatives, but the context implies it's for summary reporting rather than detailed 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?

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating this is a safe, read-only operation. The description adds valuable context about its role in patient admission workflows and immediate availability checking, which goes beyond what annotations convey. No contradiction with annotations exists.

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 efficient: purpose statement first, usage context second, then parameter documentation with examples. Every sentence adds value with no redundancy. The Portuguese language doesn't affect conciseness scoring.

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 this is a read-only query tool with comprehensive annotations and an output schema (implied by 'Has output schema: true'), the description provides complete context. It covers purpose, usage guidelines, parameter semantics with examples, and behavioral context about its role in patient admission workflows.

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

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

Schema description coverage is 0%, so the description carries full burden. It documents both parameters: tipo_quarto for filtering by room type with examples ('UTI', 'Enfermaria') and formato for output format ('markdown' or 'json'). The description provides practical examples showing how to use these parameters, adding significant value beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Exibe leitos com Status_Ocupacao = 'Disponível', com resumo por tipo de quarto' (Displays beds with Status_Occupation = 'Available', with summary by room type). It specifies the exact filtering condition and distinguishes it from siblings like leitos_listar_leitos or leitos_resumo_ocupacao by focusing only on available beds for immediate patient admission.

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 usage guidance: 'Ferramenta central para admissão de pacientes: identifica quais leitos estão livres para ocupação imediata' (Central tool for patient admission: identifies which beds are free for immediate occupancy). It clearly states when to use this tool (for patient admission) and distinguishes it from other bed-related tools that might show all beds or occupancy summaries.

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