Contazz AutoPilot

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

The annotations already declare destructiveHint=true, so the agent knows this operation has destructive potential. The description adds useful context about automatic future generation and reliance on the Heartbeat system, but it does not clarify what the destructive aspect entails (e.g., whether charges are irreversible, what permissions are needed, or side effects on customer billing).

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

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

The description is two sentences, front-loaded with the main action and scope, and every phrase adds value. No filler or repetition of schema field names. It is highly concise and well-structured.

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

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

Given the tool's complexity (scheduling, recurrence, 7 parameters, no output schema), the description adequately explains the core behavior but misses details like return value/confirmation, how to manage or cancel schedules, or edge cases. The Heartbeat mention is useful but does not fully compensate for the lack of output/behavioral detail.

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 all seven parameters already have meaningful descriptions in the schema. The tool description itself does not add additional parameter-level semantics beyond mentioning cron/recurrence, which is already captured by the 'recorrencia' enum. Baseline 3 is appropriate.

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

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

The description clearly identifies the action ('Agenda uma cobrança') and the resource ('cobrança'), and distinguishes it from siblings like criar_cobranca by specifying future or recurring execution via cron/Heartbeat. This is a specific verb+resource+scope that immediately differentiates it from immediate charge creation 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 states when to use it: for charges to be generated automatically in the future or on a recurring schedule. It does not explicitly exclude alternatives such as criar_cobranca for immediate charges, but the context is clear enough given sibling names. No explicit 'when not to use' is provided.

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

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

The readOnlyHint annotation already indicates a safe read operation, and the description aligns by saying 'Retorna' (returns). However, the description adds no additional behavioral context such as response format, pagination, or scoping behavior, so it only meets the baseline.

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

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

The description is a single, concise sentence that front-loads the primary purpose. Every word adds value, with 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?

The description provides a high-level summary of the output but lacks details on the exact response structure, possible statuses, and how the optional 'empresaId' parameter affects results. For a simple read-only tool this is adequate, but gaps remain.

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 'empresaId' with a description. The tool description does not add any extra meaning beyond the schema, 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 it returns the overall AutoPilot score and status of each automation module, using a specific verb ('Retorna') and resource. It is distinct from sibling tools via the AutoPilot focus, though it does not explicitly differentiate itself.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of context, exclusions, or scenarios, leaving the agent to infer usage from the description alone.

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

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

The annotation readOnlyHint=true already declares this as a safe read operation. The description adds some context about the exact counters returned, but does not disclose other behaviors (e.g., behavior without empresaId, response format, or performance characteristics). No contradiction with annotations.

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

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

The description is a single, efficient sentence that directly states the tool's output. It is front-loaded and contains no filler or repetition.

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, read-only tool with one optional parameter and no output schema, the description covers the core purpose and output list. However, it could be slightly more complete by indicating what happens when no empresaId is provided (e.g., default behavior) or how the response is structured, but the default in the schema mitigates this.

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 100% coverage for the single parameter empresaId, including a default and description. The tool description adds no additional parameter-specific information, so the baseline score of 3 applies.

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

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

The description clearly states the tool returns a specific set of counters (a receber hoje, a pagar hoje, tarefas pendentes) with a clear verb 'retorna'. It is distinct from most siblings which are broader dashboards or actions, but it doesn't explicitly name an alternative tool.

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?

Usage context is implied by the title 'Sidebar' and the list of counters, suggesting it's for quick-reference badges. However, there is no explicit statement of when to use it over similar dashboard or metrics tools (e.g., dashboard_executivo, metricas_escritorio), nor 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?

The annotations already declare readOnlyHint=true, and the description's 'Consulta' aligns with this safe read behavior. The addition that messages are classified by priority and type adds some context beyond annotations, but it does not disclose authentication needs, pagination, or response format, so it is adequate but not rich.

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

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

A single, front-loaded sentence that directly states the tool's purpose with no redundancy. It is appropriately concise for a simple read operation.

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

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

For a read-only tool with one optional parameter and no output schema, the description provides sufficient context about what the tool does. It mentions the content (messages) and classification, though it does not detail return fields. However, given the low complexity, this is nearly complete.

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

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

The schema covers the single parameter empresaId with a description ('ID da empresa') at 100% coverage. The tool description adds no parameter-specific meaning, so the schema already carries the full burden.

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 'Consulta' (query) and identifies the resource 'Caixa Postal do e-CAC' (e-CAC mailbox), adding that messages are classified by priority and type. This clearly distinguishes it from sibling tools like procuracoes_ecac, which deals with powers of attorney.

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

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

No guidance is provided on when to use this tool versus alternatives. There are no explicit exclusions, prerequisites, or reference to sibling tools, leaving the agent to infer usage solely from the description.

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 readOnlyHint annotation already indicates a safe read operation, and the description adds context about using the official Receita Federal API. However, it does not disclose limitations, rate limits, or what 'calcular' involves beyond querying rates, so it adds only modest behavioral context beyond the annotation.

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

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

The description is two short sentences, front-loaded with the core action and resource, and every word adds relevant information. No filler or redundancy.

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

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

For a tool with 6 parameters and no output schema, the description provides only high-level intent and data source. It does not clarify expected return values, how to choose between NCM and service code, or the role of origin/destination fields. While the schema covers parameter names, the operational context is incomplete.

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

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

Schema coverage is 100%, so each parameter has a description. The tool description adds slight nuance by mentioning 'produto (NCM) ou serviço', which clarifies the ncm and codigoServico parameters, but it does not explain parameter interactions or optionality beyond the schema. 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 ('Calcula') and resource ('alíquotas CBS e IBS'), narrowing to product (NCM) or service, and distinguishes itself from sibling tools like 'consultar_aliquota_cbs_ibs' by using 'calcular' instead of 'consultar'. It also mentions the legal basis (LC 214/2025) and the official API source.

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

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

The description implies use for calculating tax rates but provides no explicit guidance on when to choose this tool over similar siblings such as 'consultar_aliquota_cbs_ibs' or 'simular_imposto_reforma'. No exclusions or alternative recommendations are given, leaving usage context vague.

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 readOnlyHint annotation already indicates a safe read operation, so the description only needs to add extra behavioral context. It adds the legal basis and NCM-based scope, but does not disclose the return format or behavior when optional parameters like dataDoFato or quantidade are omitted.

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 directly states the tool's purpose. No unnecessary words 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?

Given the moderate complexity of a tax calculation tool with four parameters and no output schema, the description is somewhat minimal. It does not explicitly state the return value or the significance of optional parameters, but the read-only annotation and clear purpose make it adequate for basic 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?

Schema coverage is 100%, so the schema already documents all parameters. The description adds minimal value beyond 'com base no NCM', which is largely redundant with the schema's ncm description. It does not explain the purpose of optional parameters like quantidade or dataDoFato.

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: 'Calcula o Imposto Seletivo (IS) sobre um produto com base no NCM'. It uses a specific verb ('Calcula') and resource ('Imposto Seletivo'), and includes legal references (EC 132/2023 + LC 214/2025) that distinguish it from sibling tax tools like calcular_cbs_ibs and simular_imposto_reforma.

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 that this is for IS specifically while other tools handle CBS/IBS or regime simulation, nor does it state any prerequisites 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?

The annotation destructiveHint=true already signals destructive behavior. The description adds the critical detail 'Ação irreversível' (irreversible action) and the justification requirement, going beyond the generic annotation without contradicting it.

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

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

The description is two sentences with no unnecessary words. It front-loads the action and includes all essential information (requirements and irreversibility) 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 cancellation tool with a complete schema and destructive annotation, the description adequately covers purpose, prerequisites, and consequences. It could mention the success outcome, but this is not critical given the tool's straightforward nature.

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 describes all parameters with 100% coverage, including examples and minLength. The description reiterates the reference and justification but does not add new semantic 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 clearly states the action ('Cancela uma NFS-e') with a specific resource and scope ('emitida anteriormente'). This distinguishes it from sibling tools like emitir_nfse and cancelar_webhook by focusing on NFS-e cancellation.

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 provides clear prerequisites (reference and mandatory justification) and implies usage context (previously issued NFS-e). However, it does not explicitly state when not to use the tool or mention alternatives, though the context is sufficient for an agent.

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

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

The annotation destructiveHint=true already signals the destructive nature. The description adds that it disables a webhook already registered, implying an existing resource, but does not detail reversibility or other 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?

A single concise sentence that is front-loaded with the verb and resource. It contains no filler and efficiently communicates the core function.

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 one-parameter destructive tool, the description is minimal but adequate. However, it does not mention expected return values or failure modes, which would be useful given no output schema exists. The simplicity of the operation reduces the need for extensive documentation, but there is still a 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 parameter description 'ID do webhook a desativar'. The tool description restates 'pelo ID', providing no additional semantic value beyond what the schema already documents.

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 'Desativa' (deactivates) with the resource 'webhook' and specifies 'pelo ID', clearly distinguishing it from sibling tools like subscribe_webhook (creation) and listar_webhooks (listing).

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

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

No guidance is provided about when to use this tool versus alternatives, nor are prerequisites (e.g., the webhook must exist) or conditions for non-use mentioned. The only implicit context is the tool name itself.

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, and the description adds the fact that classification is automatic and uses AI, and that it produces an accounting category. However, it does not disclose return format, error behavior, or whether the classification is persisted. With annotations covering safety, a 3 is appropriate.

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

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

The description is a single, focused sentence that conveys purpose and outcome without any filler. Every word earns its place.

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

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

For a simple 2-param tool with readOnlyHint and no output schema, the description is mostly adequate but lacks any mention of return value format, potential limitations, or context like whether it can handle various currencies or date formats. It is not misleading but leaves some 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 coverage is 100% with descriptions for both `descricao` and `valor`. The description adds no additional parameter meaning beyond the schema, 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 verb 'Classifica' with resource 'transação financeira' and outcome 'categoria contábil' via AI. It clearly distinguishes from sibling tools like listar_transacoes and importar_transacoes which do not classify.

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

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

No guidance on when to use this tool vs alternatives. There is no mention of prerequisites, when classification is appropriate, or that this is for single transactions only. Sibling tools exist for listing and importing, but no differentiation is provided.

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

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

Annotations declare readOnlyHint=true, and the description adds useful context about the specific areas covered (ancillary obligations, certificates, pending issues), which is beyond the annotation. No contradiction, but it does not disclose return format or additional 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 a single, front-loaded sentence with no filler or redundant phrasing. Every word contributes to the meaning.

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 read-only query with one optional parameter and no output schema, the description provides a good overview of what is checked. It could be more specific about the return value, but the listed components offer sufficient context. The existence of overlapping sibling tools suggests a bit more guidance would help, yet overall it is complete enough.

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 parameter 'empresaId' described as 'ID da empresa'. The description adds no further meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly states the verb 'Verifica' (checks) and the resource: fiscal compliance status of the company, with specific components listed (ancillary obligations, certificates, pending issues). It distinguishes from 'listar_obrigacoes_acessorias' by being a broader status check, but does not explicitly differentiate from similar 'consultar_status_fiscal'.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'consultar_status_fiscal' or 'listar_obrigacoes_acessorias'. The description only explains what it does, not the appropriate context 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?

The annotations declare readOnlyHint=true, which the description does not contradict. The description adds that the reconciliation is 'automática' and uses IA, but it does not disclose whether results are persisted, whether a session is created, or any performance characteristics. Since annotations cover the read-only safety profile, the description provides minimal extra 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 sentence that immediately states the core purpose without filler. It is concise and front-loaded, earning full marks for conciseness and structure.

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 high-level AI reconciliation tool with no output schema and many sibling tools. The description does not explain what the tool returns, how it fits into the broader reconciliation workflow, or what side effects (if any) occur. For a tool of this complexity, the description is under-specified.

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

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

The input schema has 100% description coverage across all three parameters (usarLLM, empresaId, limiteTransacoes), so the schema already explains each parameter. The description adds no further parameter meaning, matching the baseline for high schema coverage.

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

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

The description clearly states the verb 'Executa' (executes) and the resource 'conciliação entre extrato bancário e lançamentos internos' (reconciliation between bank statement and internal entries), including the method 'usando IA' (using AI). However, it does not explicitly distinguish from sibling reconciliation tools like reconciliation_execute, 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?

There is no guidance on when to use this tool versus the many reconciliation_* siblings or other related tools like classificar_transacao. No exclusions, prerequisites, or alternative recommendations are provided, leaving the agent unsure of the tool's specific role in the reconciliation workflow.

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, so the read-only nature is covered. The description adds the legal reference and 'vigentes' (current), which implies time-sensitive data, but it does not disclose parameter combination behavior, output format, or any constraints. Minimal additional context beyond annotations.

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

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

The description is a single, well-structured sentence front-loaded with the verb 'Consulta'. Every word is purposeful, and it includes the legal reference without bloat.

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 4 optional parameters and no output schema. The description does not explain what inputs are needed for product vs service queries, what the return data looks like, or what happens when no parameters are provided. This leaves significant gaps for an agent to invoke the tool correctly.

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

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

Schema descriptions cover all 4 parameters (100% coverage), so baseline is 3. The description mentions product vs service but does not explain which parameters apply to each scenario or how they interact (e.g., ncm with ufDestino vs codigoServico with codigoMunicipio). No extra semantic value over schema.

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

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

The description states a specific verb ('Consulta') and resource (CBS/IBS rates) for a specific service or product, with legal reference LC 214/2025. It clearly identifies the operation but does not explicitly distinguish this from sibling tools like 'calcular_cbs_ibs' or 'simular_imposto_reforma'.

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

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

The description provides no guidance on when to use this tool versus alternatives such as 'calcular_cbs_ibs' or 'simular_imposto_reforma'. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent to infer usage.

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, so the safety profile is covered. The description adds that it generates a report for a period, but does not disclose return format, pagination, or any constraints, which is acceptable given the low risk read-only nature.

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, front-loaded sentence that efficiently conveys the tool's purpose without filler. It is appropriately concise.

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?

Though the tool is simple and read-only, the description does not explicitly state what the tool returns; the output schema is absent. However, the phrase 'gera o DRE' implies the DRE is the return value, and with schema coverage and annotations, it is minimally 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 descriptions cover all three parameters (dataInicio, dataFim, empresaId) with clear formats and IDs. The description only mentions 'período', which maps to the date range, adding no extra meaning 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 clearly states the tool generates a company's income statement (DRE) for a given period, using the specific verb 'Gera' and naming the resource. It is distinctive among siblings, which include other consultar_* tools but none for DRE.

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 DRE report is needed for a period, but it does not provide when-to-use vs alternatives or exclusions. No sibling with similar functionality is named, so guidance is minimal.

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 annotation readOnlyHint=true already covers the safety profile. The description adds useful scope context ('all accounts'), but does not disclose any additional behavioral traits such as default behavior when no empresaId is provided, return format, or potential limitations. This is consistent with annotations.

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

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

The description is a single, clear sentence that is perfectly sized for the tool's simplicity. It conveys the purpose without any wasted words, and the key information is front-loaded.

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

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

The tool is simple, but there are gaps: the empresaId parameter is optional, yet the description doesn't clarify what happens when it's omitted (e.g., which company's balance is returned). There is no output schema and the return structure is not described. For a query tool, this leaves some ambiguity, though the core function is clear.

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% (empresaId is described as 'ID da empresa'), so the description doesn't need to explain parameters. The description implies the parameter is used to select the company, but adds no extra meaning 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 'Retorna' (returns) and clearly identifies the resource: 'o saldo atual de todas as contas bancárias da empresa' (current balance of all company bank accounts). This distinguishes it from sibling tools like listar_contas_bancarias, which likely list account details rather than balances.

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

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

The description makes the use case clear: this tool answers the question 'what is the current balance of all company accounts?'. It doesn't explicitly name alternatives or exclusions, but the context is sufficiently clear for an agent to select it when a balance query is intended, especially given the tool's name.

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

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

Annotations declare readOnlyHint: true, and the description's verb 'Consulta' aligns with this. The description adds minimal behavioral context beyond the annotation—it specifies the document types and the reference field but does not disclose response structure, potential statuses, or any operational nuances. With the annotation covering safety, the added value is marginal, so a 3 is appropriate.

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 conveys essential information without redundancy. It is appropriately concise and well-structured, fitting comfortably within quality limits.

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 required parameter, no output schema), the description provides sufficient context to know when and how to invoke it. It identifies the resource, the reference method, and document types. A small gap exists: it does not describe the return format or possible statuses, but for a simple status query this is not critical. Overall, it is complete enough for correct invocation.

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

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

Schema description coverage is 100% for both parameters. The description reinforces the meaning of 'referencia' by specifying it as a Focus NFe reference and listing document types, but this adds little beyond what the schema already states (e.g., 'Referência Focus NFe do documento'). Since the schema carries the weight, a 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 the action ('consulta o status de processamento'), the resource ('documento fiscal'), and narrows the scope to specific document types (NFS-e, NF-e, NFC-e) and a specific lookup method ('pela referência Focus NFe'). This is a specific verb+resource combination that distinguishes it from siblings like emitir_nfse or cancelar_nfse.

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: querying the processing status of a fiscal document by its unique Focus NFe reference. It provides clear context but does not explicitly mention when not to use it or suggest alternatives (e.g., listar_documentos_fiscais for broader listing). No exclusionary guidance is given, 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?

The description states 'Cria' (creates), but the destructiveHint annotation indicates the tool is destructive, which contradicts the description's clear creation semantics. The description's additional behavior about generating boleto/Pix is overshadowed by this contradiction, earning a score of 1.

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

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

Two short sentences that immediately state what the tool does and its automatic payment generation. 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 no output schema and a misleading annotation, the description fails to disclose return values, side effects, or clarify the destructive contradiction. It is too sparse for a 6-parameter financial tool.

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

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

Schema coverage is 100%, so all six parameters have descriptions. The description adds a small note that boleto/Pix can be generated automatically, which relates to the formaPagamento enum, but does not add further semantic detail. 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 the specific verb 'Cria' and names the resource 'nova cobrança (conta a receber)', clearly distinguishing it from siblings like listar_cobrancas or criar_cobranca_pix by mentioning both boleto and Pix 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 a general charge creation scenario with automatic boleto or Pix generation, but does not explicitly contrast with related tools like criar_cobranca_pix or agendar_cobranca. No when-not-to-use guidance is provided.

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

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

Annotations already indicate destructiveHint: true, and the description adds some context by specifying immediate receipt and Asaas integration. However, it does not disclose any side effects or irreversible actions beyond what the hint implies, leaving room for more behavioral detail.

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 directly states the tool's purpose without any filler. It is concise and efficiently conveys the essential information.

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

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

For a simple creation tool, the description provides the core purpose and mentions the output (QR Code). However, it lacks details about return values, prerequisites, or any post-creation behavior, which would make it more complete. The 100% schema coverage mitigates parameter gaps, but overall the description is minimal.

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

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

The input schema has 100% description coverage for all six parameters, so the description does not need to add parameter explanations. It adds no extra semantic value beyond the schema, matching 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 creates a Pix charge (QR Code) for immediate receipt via Asaas. This specific verb+resource combination distinguishes it from sibling tools like criar_cobranca (generic create) and agendar_cobranca (scheduled).

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or explicit comparisons to similar sibling tools such as criar_cobranca or agendar_cobranca.

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 the crucial behavioral fact that the tool is disabled, which is not conveyed by the annotations. The destructiveHint annotation is present, but the description's 'Módulo desativado' provides the operational context that calls will not execute. This goes beyond the annotation's basic safety hint.

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, front-loaded with the key disabled status, and contains no unnecessary verbiage. It is concise and well-structured for a disabled tool.

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

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

The description fully covers the situation: the tool is disabled, contact support for reactivation. With no parameters, no output schema, and a destructive annotation, this is complete for an agent to understand it should not be invoked. The only minor gap is lack of alternative tooling, but that is not essential.

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 zero parameters, the schema is fully covered. The description does not need to explain parameters. Baseline for no parameters is 4, and there is nothing to add.

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

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

The description clearly states that the module is disabled in Core v3.0, which communicates that the tool is unavailable. While it does not describe what the tool does, the title and name indicate it is for creating an orçamento, and the disabled status is the relevant purpose for an agent. It distinguishes itself from siblings by being the only disabled tool.

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 tells the agent to contact support for reactivation, implying the tool should not be used. However, it does not mention any alternative tools (e.g., listar_orcamentos) or provide explicit when-to-use guidance. The implicit instruction is strong but lacks alternative directions.

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 readOnlyHint annotation is consistent with the description's 'Retorna' (returns), and the description adds context about the specific metrics included. However, it does not disclose any additional behavioral traits such as data freshness, default period, or whether the metrics are aggregated for a specific company or all.

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 verb and lists the key metrics. Every word adds value, and there is no redundant or irrelevant detail.

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

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

Given the low complexity (one optional parameter, no output schema, read-only annotation), the description is adequately complete: it names the returned metrics and implies a read action. However, it could be more helpful by mentioning the intended use case or clarifying the difference from similar dashboard tools, 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 covers 100% of parameters with a description ('ID da empresa'), so the baseline is 3. The tool description does not add further meaning about how the parameter affects the returned metrics, such as whether it is required for filtering or what the default value (0) implies.

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

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

The description clearly states that the tool returns consolidated executive metrics and lists the specific metrics (revenue, expenses, profit, cash flow, delinquency). This uses a specific verb ('Retorna') and resource, and the content distinguishes it from other general dashboard tools, though it does not explicitly name alternatives.

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

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

The description provides no guidance on when to use this tool versus alternatives such as dashboard_multi_pj, metricas_escritorio, or consultar_dre. There is no mention of scenarios, prerequisites, or exclusions, leaving the choice of tool to the agent's inference.

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

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

The readOnlyHint annotation already signals a safe read operation. The description adds value by specifying the scope (multiple companies) and the output structure (receita, despesas, saldo por empresa), giving the agent a concrete expectation of what the tool returns beyond the annotation.

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

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

The description is a single, well-structured sentence that immediately conveys the core purpose and output fields without any wasted words. It is front-loaded with the action verb 'Retorna' and clearly presents the resource and data scope.

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 only one optional parameter and simple output expectation, the description is sufficiently complete. It explains the returned metrics and their grouping, which would guide an agent even without an output schema. Minor omission: it does not mention that all companies are included by default or how the empresaId affects the result, but this is covered by the schema.

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

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

The input schema provides 100% coverage with a description for the only parameter 'empresaId' ('ID da empresa principal (grupo)'). The tool description does not add further semantics about the parameter, so it remains at 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: 'Retorna visão consolidada de múltiplas empresas do grupo' (returns consolidated view of multiple companies) and lists the specific data points (revenue, expenses, balance per company). This verb+resource combination distinguishes it from sibling dashboards like dashboard_executivo, which likely targets a single company.

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 implicitly conveys when to use the tool: whenever a consolidated view across the group's multiple companies is needed, with financial metrics broken down by company. It lacks explicit exclusions or comparisons to alternatives, but the context is clear enough for an agent to select it appropriately.

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

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

The readOnlyHint annotation already flags this as a safe read operation, so the description doesn't need to cover that. It adds context about 'otimizações aplicadas,' implying reliance on existing company optimization data, but doesn't disclose return behavior or any other operational constraints.

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

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

A single, well-formed sentence in Portuguese that wastes no words. It is front-loaded with the verb and object, making it easy to parse.

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

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

With no output schema, the description should specify what the tool returns, but it only says it 'calculates' the savings. The simple single-parameter interface is mostly covered, but the missing return-value detail keeps it from being fully 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 coverage is 100% since empresaId has a description in the schema. The tool description adds no additional parameter information, so the baseline 3 applies.

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

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

The description uses a specific verb ('Calcula') and identifies the resource ('economia tributária gerada pela empresa com otimizações aplicadas'), clearly distinguishing it from sibling tax tools like 'simular_regime_tributario'. However, it doesn't explicitly name alternatives, so it loses the last point.

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

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

No guidance is provided on when to use this tool versus alternatives. There are no exclusions, prerequisites, or references to related tools, leaving the agent to infer usage from the name alone.

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

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

The description adds the behavioral trait of automatic CBS/IBS calculation, which is beyond the basic destructiveHint annotation. However, it does not disclose other side effects (e.g., whether the invoice is registered with the government, generates a protocol, or is irreversible beyond the annotation's implication). The annotation covers the destructive nature, so the description provides some extra context but not rich behavioral detail.

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 core action and includes the key differentiator (CBS/IBS calculation). It is concise with no filler or redundancy.

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

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

For a mutating financial tool with no output schema, the description is relatively brief. It covers the main purpose and a key feature, but does not explain return values, asynchronous behavior, or prerequisites beyond the required inputs. Given the complexity and lack of output schema, a bit more context would be beneficial, but the description is not misleading and covers the essential action.

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

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

The input schema has 100% description coverage, so the schema already documents each parameter thoroughly. The description merely mentions that tomador and serviço are required, but adds no additional meaning beyond what the schema provides. This matches the baseline for high schema coverage.

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

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

The description clearly states the tool's function with a specific verb ('Emite' - issues) and resource (Nota Fiscal de Serviço Eletrônica NFS-e). It also distinguishes itself from siblings like cancelar_nfse by specifying the emission action and automatic CBS/IBS calculation.

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 primary use case (emitting an NFS-e) and states required inputs (tomador and serviço), providing context for when to use it. It does not explicitly list alternatives or exclusions, but the sibling context makes the differentiation clear.

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 does not add behavioral context beyond the destructiveHint annotation. It fails to explain what destructive means here (e.g., irreversible message sending, state changes) or any side effects like cost or permissions required.

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

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

The description is a single, direct sentence that is front-loaded and contains no filler. It efficiently communicates the tool's purpose without unnecessary length.

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 a destructiveHint annotation, yet the description offers no elaboration on consequences, return values, or prerequisites. For a simple action, the lack of depth leaves room for misuse or misclassification.

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

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

Schema description coverage is 100%, so parameters are adequately documented in the schema. The description adds no extra meaning beyond what the schema already provides, matching the baseline of 3.

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 (send), the resource (payment reminder), and the channels (WhatsApp, Telegram, Email). It distinguishes from sibling tools like 'criar_cobranca' and 'enviar_relatorio_email' by specifying a unique 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or contextual triggers, leaving selection to the agent's inference.

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

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

With no annotations, the description carries the full disclosure burden. It usefully adds that the link is a signed JWT URL, but it leaves ambiguity about whether the link is actually sent to the client (despite the tool name 'enviar') or just returned for manual delivery. It also does not mention permissions, audit logging, or error behavior.

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

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

The description is one concise sentence, front-loaded with the main action and resource, followed by the scope list. There is no filler or redundant explanation, so it earns every word.

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

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

For a four-parameter tool with no output schema and no annotations, the description explains the core generation function well, but it omits expected return format and delivery behavior. The name 'enviar' versus the description 'retorna' creates a gap that should be clarified for complete context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's scope list merely duplicates the enum and does not add extra meaning for parameters like motivo or ttlDias 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 specific verb 'Gera e retorna' and identifies a concrete resource: a Magic Link (JWT-signed URL) for client portal access. It also lists the four scopes, which clearly distinguishes it from sibling tools like enviar_relatorio_email.

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

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

The description clearly implies the main use case: generating access links for clients to the portal. However, it does not explicitly mention when not to use it or point to alternatives among siblings, so it stops short of full when/when-not guidance.

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

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

The annotation destructiveHint=true already signals that this operation has side effects. The description adds the context that it emails the account owner and lists report types, but it does not disclose additional behavioral traits such as whether an email record is created, costs, or irreversibility. Since annotations provide the baseline, a score of 3 is appropriate.

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, front-loaded with the primary action and purpose, and then concisely lists the available report types. No unnecessary words or repetitions.

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

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

For a low-complexity tool with no output schema, the description covers the essential behavior (generate and send email), the recipient, and the available types. Together with the schema and annotations, the tool is well-specified. Minor gaps include no mention of possible errors or delivery timing, but these are not critical for this simple action.

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

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

Schema description coverage is 100%, so the parameters are well-documented in the schema itself. The description lists the report types which match the tipo enum, but this is redundant with the schema and adds no new semantic detail about parameters like periodo or empresaId beyond what the schema already provides.

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

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

The description clearly states the tool generates and sends a financial/tax report by email to the account owner, and lists the supported report types (resumo_diario, fluxo_caixa, inadimplencia, compliance, dre). This provides a specific verb+resource+scope and distinguishes it from sibling tools like consultar_dre or dashboard_executivo.

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 you need to send one of the listed report types by email) but does not explicitly state when to use this tool versus alternatives like agendar_cobranca or enviar_lembrete_cobranca. No exclusions or alternative guidance is provided.

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

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

The annotation readOnlyHint=true already covers safety. The description adds a small amount of behavioral context by specifying that the projection is based on receipts vs payments and covers a future N-month period. However, it does not disclose methodology, limitations, or data dependencies.

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?

Single sentence, front-loaded with the core action, no filler. Perfectly concise.

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 read-only projection tool with two fully documented parameters and good annotations, the description is largely sufficient. It states the purpose and scope, though it does not describe the return format, which is not critical for 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?

Both parameters are fully described in the schema (100% coverage). The description only aligns 'N meses' with the 'meses' parameter and does not add significant meaning beyond the schema's field descriptions.

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

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

The description uses the specific verb 'Projeta' (projects) with a clear resource 'fluxo de caixa futuro' (future cash flow) and specifies the scope 'recebimentos vs pagamentos' and time horizon 'próximos N meses'. This clearly distinguishes it from sibling tools like consultar_saldo or listar_transacoes.

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

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

The description provides no guidance on when to use this tool versus alternatives such as consultar_dre or dashboard_executivo. It only states what it does, leaving the agent to infer usage context without explicit exclusions or prerequisites.

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

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

Annotations declare destructiveHint: true, so the agent already knows the tool can be destructive. The description adds the behavioral detail that the report is saved in company history, which implies a write operation. However, it does not disclose what specific destructive effects might occur (e.g., overwriting existing reports) or any other side effects. Since the annotation covers the safety profile and the description adds some context, a 3 is appropriate.

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 clearly communicates the tool's core function and outcome. There is no wasted wording or redundant information, making it efficiently 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?

Given the tool's complexity (4 params, 3 required) and the abundance of similar report-related siblings, the description lacks context on when to use it, what the report is for, and what happens after saving. The absence of an output schema also means the description should explain the return behavior, but it does not. The minimal description is insufficient for an agent to fully understand the tool's role.

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 describes all four parameters (titulo, conteudo, tipo, empresaId) with 100% coverage, including an enum for 'tipo'. The description adds no additional meaning about parameters, so it relies on the schema. With high schema coverage, the baseline is 3.

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 'Gera' (generates) and the resource 'relatório estruturado de análise (agent report)', making the core action clear. It also distinguishes itself by noting the report is 'salvo no histórico da empresa' (saved in company history), which separates it from tools that simply send or display reports. However, it does not explicitly name alternatives among siblings, so it falls short of a 5.

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 offers no guidance on when to use this tool versus alternatives like 'enviar_relatorio_email' or 'gerar_insight_cliente'. There are no explicit context signals, exclusions, or alternative tool mentions. This is essentially a single-purpose statement without usage direction.

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, so the agent knows this is a safe read-only operation. The description adds tax scope but does not disclose what happens to the generated guide (e.g., returned as PDF, saved to a file) or any prerequisites. With annotations covering the key behavioral trait, a 3 is appropriate.

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

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

The description is a single concise sentence that front-loads the action ('Gera guias DARF') and includes only relevant detail about taxes and context. No filler or redundancy.

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

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

The tool is simple with two well-documented parameters and a read-only annotation. The description states the purpose and context adequately, but it does not mention what the generated guide looks like or how it is delivered (e.g., download link, PDF). For a generator tool, this is a noticeable gap, but the core functionality is still clear enough for basic use.

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 100% coverage with descriptions for both parameters (empresaId and competencia), including format. The description does not add any parameter-specific semantics beyond what the schema already states, so the baseline 3 is retained.

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 'Gera' with a clear resource 'guias DARF' and specifies the exact tax types (IR, PIS, COFINS, CSLL) and context (serviços tomados). This distinguishes it from sibling tools like emitir_nfse or calcular_cbs_ibs, making its purpose unmistakable.

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 usage context: generate DARF guides for withheld taxes on services taken. It does not explicitly name alternatives or exclusions, but the context is specific enough that an agent can infer when it applies. This aligns with '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?

No annotations exist, so the description carries the full burden. It discloses the use of Claude AI and that the output is accessible text with highlights and a recommended next action, which is useful. However, it doesn't mention cache behavior, latency/cost, or potential variability of AI-generated content despite the forceRefresh parameter.

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

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

The description is two sentences, front-loaded with verb and resource, and contains no redundant filler. Every phrase adds information: narrative, client, AI, and output structure.

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

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

The description explains the return type in words, which matters because no output schema exists. Yet it omits when to use, cache behavior, and service dependencies; for an AI generation tool with no annotations, this is adequate but not complete.

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

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

The schema covers all three parameters with descriptions, so baseline is 3. The description doesn't add parameter-level detail, but the schema already documents each field adequately, so no compensation is needed.

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

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

The description starts with 'Gera narrativa personalizada...' providing a specific verb and resource. It clearly distinguishes this from sibling tools by focusing on AI-generated textual insights for a client, not on dashboards or list 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 when-to-use or alternative/exclusion guidance. The description implies the tool is for generating client-specific narratives but never tells the agent when to prefer it over similar report/insight tools like dashboard_executivo or saude_financeira.

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 annotation destructiveHint: true already informs the agent the operation is destructive, and the description does not contradict it. However, the description adds little behavioral context beyond the batch aspect, such as whether the import appends, overwrites, or has validation 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 a single, front-loaded sentence that states the action and then lists required fields. It is compact and avoids fluff, conveying essential information 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?

The tool has a rich schema and a destructive annotation, but the description lacks details about the meaning of empresaId (especially default 0), the optionality of categoriaId, and any side effects of bulk import. The description provides a minimal summary but leaves these contextual 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?

Although schema coverage is 100%, the description lists categoriaId as a required field ('deve ter') while the schema marks it optional, creating a contradiction. This misinformation reduces the added value, and the description otherwise only repeats field names without enriching 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 imports financial transactions in bulk for a company, using the specific verb 'Importa' and a distinct resource. This distinguishes it from sibling tools like classificar_transacao and listar_transacoes, which handle classification and listing.

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 for bulk importing transactions through its 'em lote' phrasing, but it does not explicitly state when to prefer this tool over alternatives, nor does it mention any prerequisites or exclusions. For example, it doesn't clarify when to use this vs reconciliation_import_transactions.

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 readOnlyHint annotation already covers the safety profile, so the description does not repeat that. It adds scoping to 'da empresa' and mentions return fields, but does not disclose other behavioral traits like pagination or rate limits. This is consistent with annotations and adds moderate value.

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 starts with the action verb 'Lista' and includes only the essential details. There is no fluff or redundancy, making it highly concise and well-structured.

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

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

For a simple list tool with a readOnly annotation and fully described optional parameters, the description covers purpose and key output fields. It does not explain ordering or pagination, but those are minor gaps given the schema and annotations.

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?

All three parameters have schema descriptions, giving 100% coverage. The tool description itself adds no extra parameter semantics, so it sits at the baseline score of 3.

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 resource ('histórico de chamadas de tools MCP da empresa'), clearly distinguishing it from sibling list tools like listar_clientes or listar_cobrancas. It also names included fields (latency, status, timestamps), 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 for inspecting tool call history but gives no explicit guidance on when to use this tool versus alternatives, nor any exclusions or alternative tool references. The context is clear from the resource name, but the guidance is not directly stated.

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

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

The annotation readOnlyHint=true already signals a safe read operation. The description adds no additional behavioral context (e.g., pagination, filtering, or scope details), but it does not contradict the annotation either. The bar is lower with annotations, so a neutral score is appropriate.

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 conveys the tool's purpose without unnecessary words. It is appropriately sized for the tool's simplicity.

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

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

For a simple read-only list tool with one optional parameter and no output schema, the description adequately states its purpose. However, it omits details about the return format, potential pagination, or any implicit company scoping beyond the parameter, but the tool's simplicity makes this acceptable.

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

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

The input schema has 100% coverage for the single parameter (empresaId with description "ID da empresa"). The description does not add parameter-specific meaning beyond what the schema already provides, so baseline 3 applies.

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

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

The description clearly states the tool lists registered customers ("Lista clientes cadastrados da empresa"), using a specific verb and resource. It does not explicitly differentiate from sibling list tools, but the resource "clientes" is distinct enough.

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

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

There is no guidance on when to use this tool versus alternatives, no exclusions, and no mention of preconditions. The description only states what it does, leaving the agent to infer usage from context.

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

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

The annotation readOnlyHint=true already covers the safety profile, and the description adds that results include payment status. However, it does not disclose additional behavioral details like pagination behavior or response format, which would be useful but not critical for a read-only tool.

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

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

The description is a single, concise sentence that directly states the tool's purpose without any wasted words. It is well-structured and 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 list tool with optional parameters, the description is complete enough. It states the resource (receivables) and a key output field (payment status). The absence of an output schema is mitigated by the simplicity of the tool, though more detail on return fields would be beneficial.

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 all parameters described in the input schema. The description does not add meaningful information beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the verb 'Lista' and the resource 'cobranças (contas a receber)', specifying it is about accounts receivable with payment status. This distinguishes it from the sibling tool 'listar_contas_pagar' which handles payables.

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 for listing receivables, but it does not explicitly mention alternatives or exclusions. While the context indicates it is for accounts receivable, there is no direct comparison with sibling tools like 'listar_contas_pagar'.

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 readOnlyHint annotation already covers safety, and the description adds that balances are included in the response. It does not disclose other behavioral traits such as data freshness, pagination, or default company selection, so it provides moderate additional 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 filler or redundancy. It communicates the core purpose 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 read-only listing tool, the description covers the primary return (accounts and balances) but leaves ambiguity around the optional 'empresaId' and whether it returns all companies when omitted. This is a noticeable gap in a complete 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?

Schema description coverage is 100% for the single optional parameter 'empresaId', so the schema already explains its meaning as 'ID da empresa'. The description does not add any further parameter semantics, aligning with the baseline for high coverage.

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

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

The description uses a specific verb ('Lista') and clearly identifies the resource ('contas bancárias cadastradas da empresa') with an additional detail about current balances. This clearly distinguishes it from sibling tools like listar_contas_pagar or listar_transacoes.

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: use this when you need the company's bank accounts and their current balances. However, it does not explicitly mention alternatives or when not to use it, so guidance is implicit 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?

Annotations already declare readOnlyHint=true, establishing the safe read operation. The description adds that it returns vencimentos e status, but does not disclose filtering behavior, default handling of empresaId, or pagination. This is modest added value beyond the annotations.

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

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

The description is a single, front-loaded sentence that conveys purpose and return fields with no filler or redundancy. 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?

The tool is simple with one parameter, a read-only annotation, and a description covering key return fields. It lacks explicit mention of optionality or default behavior of empresaId and no output schema, but given the low complexity, it is reasonably complete.

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

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

The input schema has 100% description coverage for the single parameter empresaId, so the schema already explains the parameter. The description adds no additional parameter-level detail, 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 the tool lists company accounts payable with due dates and status, using the specific verb 'Lista' and resource 'contas a pagar'. This distinguishes it from sibling list tools like listar_cobrancas or listar_transacoes.

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

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

The description provides no guidance on when to use this tool versus alternatives such as listar_cobrancas or listar_transacoes. There is no mention of scenarios, exclusions, or related tools.

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

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

Annotations indicate a read-only operation. The description adds that only active contracts are listed and includes values and due dates, but does not disclose pagination, filtering details, or access requirements. Acceptable for a simple read 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 one efficient sentence with no unnecessary information. It is direct and easy to parse.

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

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

For a simple read-only list tool with annotations, the description covers the core return values and scope. It could clarify the default behavior for the optional empresaId, but overall 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?

The single parameter 'empresaId' is fully described in the schema with 100% coverage. The tool description does not add parameter semantics, so baseline 3 applies.

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

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

The description clearly states the tool lists active contracts with values and due dates, using a specific verb ('lista') and resource ('contratos'). It is distinct from sibling tools like listar_clientes or listar_cobrancas.

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 use cases, exclusions, or other tools to prefer.

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 readOnlyHint annotation already covers safety, and the description adds scope ('emitidos pela empresa') and document types. However, it does not disclose behavior such as pagination, ordering, or result format, which is an acceptable level since annotations cover the key behavioral trait.

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 states the verb, resource, and scope without wasted words. It is concise and effectively structured.

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

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

For a simple listing tool with no output schema and good annotations, the description is largely complete. It could mention default behavior like limit enforcement or return a list, but the verb 'Lista' and schema cover most essentials.

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% (all three parameters have descriptions in the schema). The description's 'com filtros' adds a slight semantic hint that parameters are for filtering, but it does not meaningfully expand beyond the schema's own descriptions.

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

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

The description uses a specific verb ('Lista') and resource ('documentos fiscais'), and specifies the document types (NFS-e, NF-e, NFC-e), clearly distinguishing it from sibling list tools like listar_cobrancas and listar_transacoes.

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 for listing fiscal documents but provides no explicit when-to-use or alternative guidance. It does not mention exclusions or when to prefer other tools, leaving usage context to inference.

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

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

The readOnlyHint annotation already signals a safe read operation. The description adds the behavioral detail that the tool returns all companies linked to the account, which is useful but does not go beyond that. No pagination, ordering, or return format is disclosed, but the bar is lower given the annotation.

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

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

The description is a single, front-loaded sentence that says exactly what the tool does without any redundant information. 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 parameterless, read-only list tool, the description is sufficiently complete to understand the tool's purpose and scope. There is no output schema, but the simplicity of the operation does not demand elaborate return-value documentation.

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, and schema description coverage is 100%, so no parameter documentation is needed. The baseline for no-parameter tools is 4, and the description does not need to add parameter-level detail.

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

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

The description clearly states the action (list) and resource (companies), and specifies the scope (all companies linked to the user's account). This distinguishes it from sibling tools like listar_clientes and listar_contas_bancarias, so the purpose is 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 the use case: when the agent needs to retrieve all companies associated with the user's account. It does not explicitly mention alternatives or exclusions, but the context is clear enough for a simple list operation with no parameters.

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, so the safety profile is covered. The description adds ordering behavior (by valor em aberto) and clarifies the scope (clients with overdue charges), which is useful but not extensive. 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?

The description is a single, concise sentence that front-loads the main function and includes the sorting detail. Every word earns its place with no redundancy.

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

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

For a simple read-only list tool, the description adequately explains what is returned (clients with overdue charges) and the ordering. No output schema exists, but the description covers the essential return semantics. Minor gap: no mention of pagination or response format limits, but not critical for this tool.

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

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

Schema description coverage is 100%, with both parameters (empresaId and diasAtraso) already described. The description adds no extra parameter meaning, 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 clearly states the tool lists clients with overdue charges and orders them by outstanding value. This specific verb+resource+ordering distinguishes it from siblings like listar_clientes and listar_cobrancas.

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?

Usage is implied by the name and description (use when needing defaulters), but there is no explicit when-to-use guidance or mention of alternatives. No exclusions are stated, so it remains at the 'implied usage' level.

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

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

Annotations already declare readOnlyHint=true, and the description adds the scope of data (obligations, deadlines, status) without contradicting that. However, it does not disclose additional behavioral traits such as pagination, default company context, or how filters combine, providing only minimal extra context beyond the annotation.

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

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

The description is a single, concise sentence that front-loads the action and object. Every word contributes meaning, with no filler or repetition of the name, 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 is simple with only three optional parameters and a read-only annotation. The description states the output content (obligations with deadlines and status), which partially compensates for the lack of an output schema. It doesn't mention return format or edge cases, but given the low complexity, it is sufficiently complete.

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

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

Schema description coverage is 100%, so all three parameters are already documented with types, defaults, and formats. The description does not add any parameter-specific meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description uses the specific verb 'Lista' and identifies the resource as 'obrigações acessórias' with concrete examples (DCTF, EFD, SPED, DIRF). It also specifies the included data (prazos e status), clearly distinguishing it from sibling listing tools.

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

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

The description implies the use case for listing ancillary tax obligations, but it does not explicitly mention when to use this tool over alternatives or provide any exclusions. With similar sibling tools like listar_documentos_fiscais, a note about differentiation would improve guidance.

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

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

The description discloses a crucial behavioral trait beyond the readOnlyHint: the tool is deactivated and requires support intervention. This is valuable context that the annotations do not convey. It does not contradict the readOnlyHint since being disabled is consistent with a read-only 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 extremely concise, with two short sentences that immediately convey the essential status and required action. It is well-structured and front-loaded, wasting no 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 disabled tool with no parameters and no output schema, the description fully covers the necessary context: the tool is unavailable, and the agent knows to contact support. It is complete for its purpose, which is to prevent usage and redirect the user.

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 and the schema is empty, so the description does not need to add parameter semantics. According to the 0-param baseline, a score of 4 is appropriate. The description adds nothing beyond the schema, but there is nothing to add.

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 completely omits the tool's intended function of listing budgets (orçamentos). It only states that the module is disabled and instructs contacting support, which is a status message rather than a purpose statement. The title and name provide the purpose, but the description itself fails to state it.

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 signals that the tool is disabled and should not be used, and it provides a clear alternative action ('Contate suporte para reativação'). While it doesn't describe positive usage scenarios, it effectively tells the agent when not to use it and what to do instead.

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 readOnlyHint annotation indicates a safe read operation, and the description aligns with that. However, it claims support for a 'period' filter that does not exist in the schema, which is misleading about the tool's actual behavior. It also lacks disclosure about pagination, defaults, or output format.

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 is concise and easy to parse. However, the phrase 'por período' is unnecessary and inaccurate, so it does not fully earn its place. Overall, the structure is efficient but slightly flawed.

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 read-only list tool with full schema coverage, the description is mostly adequate. However, it omits practical details like default limit/offset behavior and does not clarify the return format. The misleading period filter claim also creates a gap in 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?

Schema coverage is 100%, so the baseline is 3, but the description adds misleading information by mentioning a 'period' filter that is not a parameter. It provides no additional clarity for offset or empresaId, and the false claim could confuse an agent trying to understand which parameters are actually available.

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 lists financial transactions (income and expenses) for the company, using a specific verb and resource. However, it mentions support for a 'period' filter that is not reflected in the input schema, which introduces slight ambiguity. It does not explicitly distinguish itself from other list tools, but the resource type is clear.

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 simply states what it does without mentioning use cases, exclusions, or relationships to sibling tools like listar_contas_pagar or classificar_transacao.

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, so the description does not need to state read-only. It adds useful context about what is listed ('status e eventos configurados'), but does not disclose pagination, authentication needs, or response format beyond that.

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 delivers the essential information without 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?

For a simple read-only list operation with one optional parameter and no output schema, the description provides sufficient context. It states the resource and included details. It could benefit from mentioning the return format, but complexity is low enough that current detail is adequate.

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

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

Schema description coverage is 100% for the single parameter (empresaId with 'ID da empresa'). The description adds no parameter-level meaning, but with full schema coverage, a 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 uses a specific verb 'Lista' (lists) with a clear resource ('webhooks registrados para a empresa') and adds detail ('com status e eventos configurados'). It clearly distinguishes from siblings like 'cancelar_webhook' and 'subscribe_webhook'.

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 naming the resource and action, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. For a simple list operation, the context is inferred but not explicitly guided.

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

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

Annotations declare readOnlyHint=true, so the safe-read profile is covered. The description adds value by listing the specific metrics returned, but does not disclose additional behavioral context such as default company scope, date ranges, or return format. This is minimal but non-empty additional context beyond annotations.

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

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

The description is a single, focused sentence that lists the metrics in a readable, comma-separated format. Every word earns its place, with no fluff or redundancy; it is front-loaded with the action and resource.

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 read-only tool with one optional parameter and no output schema, the description adequately communicates the returned metric set. However, it does not clarify whether the metrics apply to the company identified by empresaId or the global office context, nor does it mention the default behavior when the parameter is omitted. This leaves a small but relevant 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 has one parameter, empresaId, with 100% description coverage ('ID da empresa'), so the schema already documents its meaning. The description does not mention the parameter or add any additional syntax or format details, keeping it at the schema-dependent 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 opens with a specific verb ('Retorna') and resource ('métricas SaaS do escritório contábil'), then enumerates concrete metrics (MRR, ARR, churn, LTV, ticket médio, clientes ativos). This clearly distinguishes it from broader sibling tools like dashboard_executivo by focusing on a defined set of SaaS metrics.

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

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

No guidance is provided on when to use this tool versus alternatives such as dashboard_executivo, saude_financeira, or consultar_dre. There are no exclusions, prerequisites, or alternative tool suggestions, leaving the agent to infer usage solely from the metric list.

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 behavioral burden. It discloses that AI classifies intent and generates an automatic response, but it does not state side effects (e.g., whether the response is actually sent to the customer), what happens for the 'humano' intent (e.g., escalation), or any required permissions. This is a significant gap for a tool that triggers automatic actions.

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

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

The description is a single, efficient sentence that packs a clear purpose and an enum-like list of intents. Every part is informative, though the intent list could arguably be part of the schema. 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?

The tool has no output schema, and the description does not explain what the tool returns or the format of the auto-response. It also lacks guidance on when to escalate to 'humano'. Given the action-oriented nature (generating and possibly sending responses), the description is not complete enough for an agent to understand the full impact and outcome.

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

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

Schema description coverage is 100%, and each parameter has a description, so the schema already documents the parameters well. The description adds the intent taxonomy, which is useful but not directly tied to parameter syntax or additional meaning beyond what the schema provides. 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 uses a specific verb ('Processa') with a clear resource ('mensagem de texto de um cliente') and states the core function: 'usando IA para classificar intenção e gerar resposta automática'. It also lists concrete intent categories (boleto_2via, status_envio, etc.), which distinguishes it from sibling tools focused on financial operations.

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

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

The description implies the tool is for processing incoming customer messages, but it does not provide explicit 'when to use' guidance or mention alternatives. Sibling tools like 'classificar_transacao' might overlap, but no exclusions are stated. The intent list gives context but no direct usage instructions.

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

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

The description adds some behavioral context beyond the readOnlyHint annotation, such as including both granted and received powers of attorney and providing validity status. However, it does not disclose return format, pagination, or permission requirements. The annotation already establishes it as a safe read operation.

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

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

The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the purpose, scope, and a key feature, making it highly concise and well-structured.

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

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

For a simple read-only list tool with one optional parameter and no output schema, the description covers the core functionality adequately. It could clarify how the optional 'empresaId' filters results or what the validity statuses mean, but these are not critical for basic interpretation.

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

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

Schema description coverage is 100% for the single parameter 'empresaId' (described as 'ID da empresa'), so the description does not need to elaborate on parameter meaning. The description itself mentions no parameters, which is acceptable given the schema's completeness.

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' (lists) with a specific resource 'procurações eletrônicas do e-CAC' and indicates scope ('outorgadas e recebidas') and a distinguishing feature ('com status de validade'). This clearly differentiates it from sibling tools like 'caixa_postal_ecac' or 'listar_obrigacoes_acessorias'.

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

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

The description implies when to use the tool (when needing to list e-CAC powers of attorney) but does not explicitly state when not to use it or mention alternative tools. There are no exclusions or comparisons with siblings.

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 meaningful behavioral context beyond the destructiveHint annotation by stating that transactions and ledger entries are marked as reconciled. It does not disclose irreversibility or permission requirements, but the annotation already flags the destructive nature, so the added context is valuable.

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

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

The description is two short sentences, front-loaded with the action and followed by the effect. There is 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 simple one-parameter tool, the description sufficiently explains the action and its immediate outcome. It does not mention return values or prerequisites, but given the low complexity and the schema covering the only parameter, this 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 input schema already provides 100% coverage for matchId with the comment 'ID do match a aprovar'. The description adds no further parameter semantics, so the baseline of 3 applies.

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

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

The description clearly states the action ('Aprova') and the resource ('um match sugerido pelo motor de conciliação'), and further specifies the consequence ('Marca as transações e lançamentos envolvidos como conciliados'). This distinguishes it from sibling tools like reconciliation_list_matches and reconciliation_execute.

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 context with 'sugerido pelo motor de conciliação', but it does not explicitly recommend when to use this tool versus alternatives, nor does it mention prerequisites such as listing matches first. Guidance is implied rather than stated.

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

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

The annotations only specify destructiveHint: false, and the description adds that the session is a container. However, it does not disclose potential side effects, such as what happens if a session already exists for the period, or whether any other state is created or modified. The description carries some weight beyond annotations but leaves 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 two short sentences, front-loaded with the primary action, and contains no redundant information. Every word contributes to understanding the tool's purpose.

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

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

The description explains the basic creation action but does not mention the return value (no output schema exists), nor does it connect to related reconciliation workflows. Within its simplicity, it covers the main function, but the lack of output/response details and relationship to sibling tools leaves room for improvement.

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

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

The input schema has 100% description coverage for all four parameters, each with a clear description. The tool's description only references 'período específico', which maps to existing schema fields, adding no additional meaning 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 clearly states the specific action ('Cria uma nova sessão de conciliação') and the resource ('sessão de conciliação'), and explains its role as a container for comparing transactions and entries. This distinguishes it from sibling tools like reconciliation_import_transactions or reconciliation_execute.

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 that this tool is used to start a reconciliation process for a given period, but it does not explicitly state when to use it versus other reconciliation tools, nor does it provide exclusions or alternative recommendations. The context is clear but not fully elaborated.

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

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

Annotations already declare destructiveHint=true, and the description does not contradict this. It adds context about the multi-layer process and the return summary, but doesn't elaborate on side effects or what gets destroyed. Given the annotation, the description provides some additional insight but not a full picture.

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 efficiently conveys the core action, mechanism, and return type. It is front-loaded and every part contributes functional meaning, with no redundancy.

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

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

The description covers the operation's result and mechanism, but misses workflow context (e.g., needing a session created and populated first) and doesn't detail the response structure beyond a summary. For a destructive, complex operation, this is a moderate gap, though annotations offset the destructive aspect.

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 100% schema description coverage, the schema fully documents the only parameter (sessionId: number, 'ID da sessão de conciliação a executar'). The description adds no extra parameter detail, but that is unnecessary. 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 that the tool executes the reconciliation engine with three layers (deterministic rules, fuzzy matching, LLM) for a session. This distinguishes it from sibling tools like reconciliation_create_session or reconciliation_import_entries, with a specific verb ('Executa') and resource ('motor de conciliação').

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. It doesn't mention prerequisites such as creating a session or importing entries, nor does it contrast with other reconciliation_* siblings. The implied usage context exists but is not articulated.

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 mark destructiveHint: true, but the description does not disclose what destructive action occurs (e.g., overwriting existing entries). It only says 'imports' without clarifying side effects, leaving a significant gap for a potentially destructive operation.

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

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

Two concise sentences, front-loaded with the purpose, no superfluous 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?

While the schema is rich, the description lacks context about the destructive potential (from annotation) and does not differentiate from the sibling reconciliation_import_transactions. It also does not mention what the tool returns or the effect on the session, leaving the agent somewhat in the dark for a complex import operation.

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 baseline is 3. The description summarizes the array fields (data, descrição, valor, tipo, contas débito/crédito) but omits optional fields like documento, historico, favorecido, which could mislead. It does not add meaningful detail beyond the schema.

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

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

The description clearly states the tool imports general ledger entries ('lançamentos do razão contábil') into a reconciliation session, using a specific verb and resource. It distinguishes from siblings by focusing on accounting entries rather than transactions.

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?

Provides clear context for when to use: to import ledger entries into a reconciliation session. However, it does not explicitly mention alternatives or when not to use, such as the difference from reconciliation_import_transactions.

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 annotation deststructionHint=true already indicates the tool is destructive, but the description provides no additional behavioral context such as whether importing appends to or replaces existing transactions, or what side effects might occur. The description adds no value beyond the annotation.

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

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

The description is two concise sentences, front-loaded with the main purpose and followed by input format. Every word earns its place, with no unnecessary detail.

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

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

For a mutation tool with destructiveHint=true and no output schema, the description is too sparse. It does not mention return values, success/failure behavior, or any prerequisites (e.g., session must exist). The schema covers parameters, but the description leaves the agent uncertain about outcomes.

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 repeats what the schema already states about the array fields (data, descricao, valor, tipo), adding no additional meaning or context 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 clearly states the action ('imports transactions') and the target resource ('to a reconciliation session'), providing a specific verb+resource. It does not explicitly distinguish from similar sibling tools like reconciliation_import_entries, but the bank statement context adds clarity.

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 context of importing into a reconciliation session implies when to use it, but the description gives no explicit guidance on when to prefer this over alternatives like importar_transacoes or reconciliation_import_entries. No exclusions are stated.

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

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

Annotations already declare readOnlyHint=true, so the agent knows it is a safe read operation. The description adds value by enumerating the exact KPIs returned, but it does not disclose behavior around the optional empresaId filter, data freshness, or return envelope, though this is less critical given the read-only hint.

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?

Single sentence that front-loads the verb and object, then lists the specific KPIs. No filler or redundant wording; every part earns its place.

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

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

The tool is simple (one optional param, no output schema), and the description lists the key result elements, which compensates for the missing output schema. However, it does not clarify how empresaId affects the results or how this KPI view relates to the broader dashboard/metrics sibling tools, leaving a small 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% – the single optional parameter empresaId is already described as 'ID da empresa'. The description does not add additional parameter semantics, so it meets but does not exceed the baseline for fully-covered schemas.

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 'Retorna' (returns) plus the resource 'indicadores-chave de conciliação' and enumerates the exact KPIs (contas ativas, sessões concluídas, taxa de automação, exceções pendentes, sessões recentes). This clearly distinguishes it from sibling tools that perform reconciliation actions (e.g., reconciliation_approve_match, reconciliation_execute) or list raw data (e.g., reconciliation_list_exceptions).

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 choose this over alternatives like dashboard_executivo, metricas_escritorio, or reconciliation_list_exceptions. The usage is implied by the KPI-focused title and description, but there are no stated criteria, exclusions, or alternative tool references.

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 readOnlyHint annotation already indicates this is a safe read operation. The description adds value by disclosing the scope (reconciliation accounts) and the return fields (name, type, bank, tolerance settings), going beyond what annotations provide.

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, front-loaded with the verb and resource, and contains no unnecessary information.

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

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

For a simple listing tool, the description covers scope and return fields well. However, it omits the effect of the optional 'empresaId' parameter and does not mention pagination, which are minor gaps given the low complexity.

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

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

The schema has 100% coverage for the 'empresaId' parameter description, so the baseline is 3. The description does not elaborate on how 'empresaId' affects results; in fact, saying 'todas as contas' creates ambiguity about whether the parameter filters or is ignored.

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 lists all accounts configured for accounting reconciliation, specifying categories (banking, customers, suppliers, taxes) and the output fields. It distinctly differentiates from sibling tools like 'listar_contas_bancarias' by focusing on reconciliation-specific accounts.

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 context is clear: use this tool when you need to list reconciliation accounts. The description implicitly restricts to reconciliation-configured accounts, which distinguishes it from general bank account listing, but it does not explicitly mention alternatives or exclusion 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?

The readOnlyHint annotation already signals safety. The description adds useful context by defining the two types of exceptions and noting that the response includes priority and AI suggestion, but it does not cover return format, pagination, or ordering. This is similar to the TDQS get_calls example and does not contradict annotations.

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

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

Two concise sentences that start with the primary action and include necessary context without waste. Each phrase adds value, and the structure is front-loaded.

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

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

For a simple read-only list tool with a clear schema and readOnly annotation, the description is mostly complete. It mentions the key output features (priority and AI suggestion) but omits any mention of pagination or result count. Overall adequate, with a minor gap.

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

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

Schema description coverage is 100%, with sessionId and status already described. The tool description does not add parameter-level detail beyond the schema, 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 uses a specific verb ('Lista') and identifies the resource ('exceções de uma sessão'), clearly distinguishing it from siblings like reconciliation_list_matches and reconciliation_list_accounts. It also clarifies what counts as an exception, making 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?

The description provides clear context for when to use the tool—when needing to view unmatched items in a reconciliation session—but does not explicitly name alternatives or exclusions. The sibling tool names (e.g., reconciliation_list_matches) imply the choice, but the description itself lacks explicit contrast.

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 readOnlyHint=true in annotations, the read-only behavior is already disclosed. The description adds context about the output fields (confidence, match type, status) but does not provide additional behavioral traits such as sorting, pagination, or any side effects. It is consistent with the annotations and adds some value beyond them.

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

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

The description is two sentences, front-loaded with the core purpose ('Lista os matches') and immediately clarifies the returned information. Every sentence contributes 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?

Given the simple scope (a list operation with one required parameter and a filter) and the presence of a read-only annotation, the description adequately informs the agent of what the tool does and what output to expect. It does not mention pagination or ordering, but these are not critical for this straightforward listing tool.

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

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

The schema covers both parameters with descriptions (sessionId = 'ID da sessão', status = 'Filtrar por status'), and the schema description coverage is 100%. The description mentions the status field in the output but does not add extra meaning to the parameters beyond what the schema already provides. Therefore, 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 verb ('Lista') and a clear resource ('matches... em uma sessão de conciliação'), and distinguishes it from sibling tools like reconciliation_list_accounts and reconciliation_list_exceptions. It also mentions the displayed fields (confiança, tipo de match, status), making the scope explicit.

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 this tool is used to list matches for a session, but it does not explicitly state when to use it versus reconciliation_approve_match, reconciliation_execute, or other listing tools. No alternatives or exclusions are named, but the context of siblings and the read-only nature provide some implicit guidance.

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

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

Annotations include destructiveHint:true, so the safety profile is partially known. The description adds what is created (bank account, session, transactions, entries, matching rules) but does not disclose whether it overwrites existing data or what the destructive aspect entails. No contradiction with the annotation.

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

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

The description is two concise sentences, front-loaded with the action verb and resource, and efficiently enumerates the created artifacts. No filler or repeated schema information.

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

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

For a demo-seeding tool, the description covers purpose, contents, and use case. It lacks mention of return values and specifics about destructive side effects (e.g., whether it resets data), but the annotation and schema compensate partially. A 4 reflects the small gaps in side-effect disclosure.

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%, as the only parameter (empresaId) has its own description. The tool description adds no additional parameter semantics, but the baseline is 3 due to high schema coverage. The parameter is simple and optional, so no major gap.

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

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

The description clearly states the tool's action ('Cria dados fictícios de demonstração') and resource ('conciliação contábil'), listing specific artifacts (bank account, session, 20 transactions, 19 entries, matching rules). This distinguishes it from sibling reconciliation tools that perform real operations, not demo data 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 explicitly says 'Útil para testes e onboarding', giving a clear context for when to use the tool. It does not explicitly mention alternatives or exclusions, but the use case is clear and distinct from the operational reconciliation siblings.

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 readOnlyHint annotation already indicates a safe read operation, and the description adds valuable context by specifying that the tool computes a score with four named indicators, giving the agent a clear picture of expected behavior. It does not contradict the annotation, and the extra detail about the score calculation goes beyond what the annotation alone provides.

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 immediately states the action, the target, and the output. Every element is meaningful: the score range, the indicators list, and the calculation intent. There is no verbose filler or repetition of the tool name, making it highly concise and well-structured.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description adequately explains what the tool returns (a 0-100 score plus indicator names). However, it does not mention how to interpret the score, whether the default empresaId=0 refers to the current company, or any potential error conditions, leaving a small gap in completeness given the absence of an output schema.

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

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

The input schema covers 100% of the parameter documentation (empresaId with description 'ID da empresa'), and the description adds no additional parameter-level detail. Since the schema already explains the parameter, the baseline score of 3 is appropriate—the description does not enhance or clarify parameter semantics beyond the schema.

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

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

The description clearly states a specific verb ('Calcula') and resource ('score de saúde financeira da empresa'), plus the output range (0-100) and key indicators (liquidez, inadimplência, margem, compliance). This distinguishes it from sibling analytics tools like dashboard_executivo or consultar_dre, which focus on broader metrics rather than a single composite health score.

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

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

The description implies the tool is for assessing overall financial health, but it does not explicitly state when to choose it over alternatives such as consultar_saldo, fluxo_caixa_projetado, or metricas_escritorio. There is no 'when-not-to-use' guidance, leaving the agent to infer usage from the purpose alone.

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

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

The readOnlyHint annotation already declares this is a safe read-only operation, so that aspect is covered. The description adds value by explaining the comparative nature (new CBS/IBS vs current taxes), but it does not disclose conditional parameter dependencies (e.g., NCM required for mercadoria, codigoServico for servico) or what the output will specifically include beyond a comparison.

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

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

The description is a single, focused sentence. It front-loads the action ('Simula') and clearly conveys the scope and comparison. There is no redundancy or irrelevant information, 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 7 parameters, no output schema, and moderate complexity. The description provides a high-level purpose but is thin on conditional requirements—such as which parameters are needed for each tipoOperacao. The schema offers hints ('para mercadorias', 'para serviços') but the description itself does not reinforce this, leaving gaps for an agent to understand how to structure a valid request across operation types.

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's mention of CBS/IBS and current taxes gives context, but it does not add parameter-specific semantics beyond what the schema fields already say (e.g., amount, operation type, regime). The tool's behavior regarding interactions between parameters is not clarified further.

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 (simulates) and resource (impact of Tax Reform with CBS + IBS) and explicitly compares with the current regime (PIS/COFINS/ISS/ICMS). This distinguishes it from sibling tools like calcular_cbs_ibs, which focuses on calculating a specific tax, and simular_regime_tributario, which simulates regime choice.

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 intended usage is implied by the description—simulating the impact of the tax reform—but there is no explicit guidance on when to use this tool versus alternatives such as calcular_cbs_ibs or consultar_aliquota_cbs_ibs. No exclusion criteria or alternative tool mentions are provided, leaving the choice somewhat ambiguous.

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 annotation readOnlyHint=true already covers the safety profile. The description adds the behavioral detail that the tool indicates the most advantageous regime, which is useful context. However, it does not disclose potential dependencies (e.g., on company data via empresaId) or any limitation beyond what the schema already provides.

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 is concise and front-loaded. It conveys the core action, the specific regimes, and the outcome without any filler 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 readOnlyHint annotation and the parameter descriptions in the schema, the description covers the essential purpose and output ('indicando o mais vantajoso'). It does not detail return structure, but the indication of the most advantageous regime is sufficient for this simulation tool. The inclusion of the three regimes adds necessary context.

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

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

Schema description coverage is 100% for all four parameters, so the schema already documents each parameter. The description does not add any parameter-specific meaning beyond the schema, giving it a baseline score of 3.

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 ('Simula e compara') and resource (regimes tributários), listing the three exact regimes (Simples Nacional, Lucro Presumido, Lucro Real). It also states the outcome ('indicando o mais vantajoso'), distinguishing this tool from vague or generic names. This differentiates it from sibling tools like simular_imposto_reforma.

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 one needs to compare tax regimes for a company, but it does not explicitly state when to use this tool vs alternatives or provide any exclusions. No mention of when not to use or sibling guidance is present.

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

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

Annotations provide readOnlyHint=true, which covers the read-only nature. The description adds that it returns the version, which is useful, but does not disclose other behaviors such as authentication requirements, response latency, or the exact meaning of 'operational status.' No contradiction with annotations.

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

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

The description is a single sentence, direct, and front-loaded. It conveys the tool's purpose and return value without any unnecessary words, achieving high information density.

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 (no parameters, no output schema), the description sufficiently explains what to expect: operational status and current version. This is complete for a health-check tool, and the read-only annotation covers safety.

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

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

The input schema has zero parameters and schema coverage is 100%, so there is no parameter information to add. The baseline for zero-parameter tools is 4, and the description provides no additional parameter semantics beyond the schema.

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

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

The description clearly states it 'Retorna o status operacional da API Contazz AutoPilot e versão atual' (returns the operational status and current version), using a specific verb and resource. This unambiguously distinguishes it from all sibling tools, which focus on business operations.

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

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

The purpose itself makes the use case clear: checking the API's health and version. No alternatives exist among the sibling tools, so exclusions are not needed. However, it lacks explicit guidance like 'use this to verify API availability' or mention of when not to use it.

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

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

The description says the tool 'Registra' a webhook, implying a non-destructive creation operation, yet the annotation has destructiveHint=true. This is a direct contradiction: registering a webhook does not normally destroy data, and the description adds no mention of overwriting or other destructive effects. The HMAC-SHA256 detail cannot reconcile this mismatch.

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

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

The description is two sentences, front-loaded with the primary action, and includes a relevant security detail without repetition of schema information. 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?

The tool is simple and the schema covers parameters, but the description omits expected success/error behavior and fails to explain the destructiveHint annotation. While the HMAC note adds value, the unresolved contradiction leaves the description incomplete for robust agent decision-making.

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

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

Schema coverage is 100%, so the baseline is 3. The description mentions event examples already present in the schema's enum and adds no extra meaning about URL format, empresaId, or array structure. The HMAC note is behavioral, not parameter-specific.

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 leads with 'Registra uma URL de webhook' (registers a webhook URL), a specific verb and resource, and clarifies the purpose: receiving real-time company event notifications. This clearly distinguishes it from siblings like 'listar_webhooks' and 'cancelar_webhook'.