Atualização Monetária

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

The description discloses key behaviors beyond the annotations: no args yields a login link, passing a token enables session-only authentication, and config-based tokens produce a permanent non-expiring connection. Annotations already mark it as idempotent and non-destructive, and the description does not contradict 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 compact and front-loaded with the tool's purpose. The second sentence is slightly long but every part contributes to how authentication should be performed.

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

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

For a tool with one optional parameter and no output schema, the description covers the main calling patterns: no args and token-provided. It could mention what the response looks like or error cases, but the essential usage context is present.

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

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

The schema only defines an optional 'token' string, but the description explains that it expects a JWT access token copied from the browser and that it provides session-only login. This adds meaningful meaning beyond the raw 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 identifies the tool as an authentication flow for IDE agents: log in in the browser, copy the access token, and either add it to config or pass it as a token. It does not explicitly differentiate itself from siblings like 'connect', but 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 gives explicit usage modes: call with no args to get a login link, or call with a token for session-only login. It also explains the recommended alternative of adding the token to server config for a permanent connection. It does not explicitly mention when not to use the tool, but the guidance is 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?

As annotations já declaram readOnlyHint=true e idempotentHint=true, e a descrição agrega o que importa para o comportamento do cálculo: reajuste pelo índice, correção mensal, juros de mora de 1% a.m., multa moratória e retorno de detalhamento mensal + total. Não contradiz as annotations e explica o método além do que elas cobrem.

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?

Duas frases objetivas, sem repetição do nome e com informação essencial na frente: escopo legal, etapas do cálculo e formato do retorno. Cada sentença agrega valor e não há padding.

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?

Para uma ferramenta com 9 parâmetros, schema sem descrições e sem output schema, a descrição é insuficiente para um agente preencher corretamente todos os campos. 'Até hoje' sugere data fixa, mas existe o parâmetro data_calculo, e a descrição não explica opcionais como periodicidade_meses, multa ou juros em termos de preenchimento.

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?

A cobertura do schema é 0% e a descrição não mapeia explicitamente conceitos como aluguel_inicial, inicio_contrato, inicio_atraso, fim_atraso, data_calculo ou periodicidade_meses. Ela dá dicas qualitativas ('reajusta ao longo do contrato', 'corrige cada mês atrasado'), mas não compensa a ausência total de descrições dos 9 parâmetros.

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?

A descrição usa verbos específicos ('reajusta', 'corrige', 'aplica', 'retorna') sobre um recurso bem delimitado: cálculo de aluguéis em atraso sob a Lei 8.245/91. Isso a distingue claramente dos demais tools da família 'calculo_*', pois especifica o objeto (aluguel) e o regime legal.

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

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

A descrição traz contexto claro de uso: 'Aluguéis em atraso (Lei 8.245/91)'. Isso informa quando utilizar a ferramenta, embora não indique explicitamente quando não usar nem cite alternativas entre os vários tools de cálculo. Falta apenas a exclusão formal de casos fora do escopo.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses that the tool corrects installments, applies interest/penalties/fees, and returns a per-installment breakdown plus totals. The legal regime warning adds important behavioral context that prevents incorrect calculations. No contradiction with annotations exists.

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

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

Two-purposeful sentences: the first fronts the purpose, scope, and output shape, and the second packages the essential legal caveat under 'ATENÇÃO'. There is no filler and no redundant repetition of schema 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?

Given 11 parameters, no output schema, and no schema-level descriptions, the description covers the main calculation inputs, the high-stakes legal rules, and the return format ('detalhamento por parcela e totais'). It leaves minor gaps for secondary parameters like pro-rata, fee type, and interest compounding behavior, which are likely inferable from the schema enums.

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

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

Schema description coverage is 0%, so the description must compensate; it does by adding meaning to 'indice' with a list of official indexes and by clarifying how SELIC, IPCA, juros, multa, and honorários should be treated. It does not individually cover every parameter such as pro_rata, honorarios_tipo, or periodicidade_juros, but the legal guidance meaningfully reduces ambiguity for the most critical inputs.

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 'Atualização monetária / liquidação de débito judicial' and explains that the tool 'corrige parcelas por um índice oficial' and 'aplica juros, multa e honorários'. This gives a specific verb, resource, and scope, clearly separating it from sibling calculators such as calculo_aluguel or calculo_indice.

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 context: the tool is for judicial debt monetary updating/settlement, and it even gives conditional legal guidance such as 'SELIC já engloba correção+juros' and 'pós-set/2024 o cível usa IPCA + taxa legal'. This is actionable parameter-level guidance, though it does not explicitly name alternative sibling tools or state when not to use them.

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, idempotentHint, and non-destructive behavior, so the description's job is light. It adds valuable context: the three-phase calculation, the Súmula 231 STJ constraint on phase 2, and configurable fractions. No contradiction with annotations; no side effects are implied.

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 dense sentence that front-loads the core purpose, packs legal citations into parentheticals, and closes with the configurable-fractions detail. 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 calculation with 9 parameters and no output schema, the legal algorithm is well covered, but an agent is left to infer how the required pena_min_anos/pena_max_anos map to the three phases and what the result or fraction format looks like. These are meaningful gaps given the schema provides no descriptions.

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

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

With 0% schema coverage, the description must compensate and does partially: it maps 'circunstâncias judiciais' to circunstancias_desfavoraveis, 'atenuantes/agravantes' to those fields, and 'causas de aumento/diminuição' to the cause arrays. But it never names pena_min_anos/pena_max_anos as the statutory range, nor specifies units, fraction format, or defaults for optional fields.

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

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

The description identifies the resource ('Dosimetria da pena') and the exact legal method (art. 68 CP, three-phase system), which clearly separates this from sibling calculo_* tools such as calculo_fgts or calculo_pensao. It lacks an explicit verb like 'calcula', so it stops just 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 legal context implies when to use it: for criminal sentence dosimetry with the three-phase framework, not for other calculations. However, it never states when not to use it, mentions no alternative tools, and gives no 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?

Annotations already mark this read-only and idempotent, and the description adds useful behavioral context: per-deposit granularity, the specific 3%-per-year interest assumption, and the TR-to-inflation comparison logic. It does not describe return format or edge cases, but the core calculation behavior is transparent enough.

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 with no fluff. The main computation is front-loaded, the input limitation is stated, and the future OCR note adds useful context without bloating the text.

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

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

For a tool with no output schema and four parameters, the description gives the core calculation logic and input mode but omits the output shape, default behavior of incluir_juros_3aa, and how deposits should be structured. It is adequate for a high-level understanding but leaves practical invocation details unresolved.

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

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

Schema description coverage is 0%, so the description must compensate, but it only partially does. It explains the inflation-vs-TR concept and 3% interest, which relates to indice and incluir_juros_3aa, yet it does not explain the structure of depositos, the role of data_calculo, or the full list of supported indices.

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 calculates the FGTS correction difference per deposit, comparing inflation indices against TR and applying 3% annual interest. This specific verb+resource+computation distinguishes it from generic sibling tools like calculo_indice or calculo_trabalhista.

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 FGTS correction calculations from manual deposits and notes OCR extraction is only future functionality. However, it never explicitly says when not to use this tool or names alternative sibling tools for related calculations.

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?

Beyond the readOnly/idempotent annotations, it discloses the exact month-inclusion rule (initial excluded, final included) and the two conditional behaviors (return corrected value if `valor` is passed; return monthly published variations if `incluir_valores` is true). 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?

Two sentences, no filler; the core purpose and the date convention are front-loaded, and the optional behaviors are placed in a compact conditional sentence.

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

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

There is no output schema, so the description must carry return-value and edge-case information. It covers the main return modes but omits behavior when `data_final` is absent (it is not required) and omits `pro_rata`, leaving a meaningful gap for a 6-parameter calculation 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?

With 0% schema description coverage, the description must compensate. It explains the date range semantics and the purpose of `valor` and `incluir_valores`, but it does not explain `pro_rata`, the `NENHUM` enum value, or date formats. This is partial compensation with clear gaps.

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

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

The description names the exact operation ('consulta de índice oficial'), the computed result ('fator de correção acumulado'), and the date convention (initial month excluded, final month included). It also states the two optional output modes, which clearly separates it from the calculo_* siblings.

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

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

It gives clear context: use when an official BACEN/IBGE index correction factor between dates is needed, with explicit conditional use of `valor` and `incluir_valores`. It does not name exclusions or sibling alternatives, so it falls just 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?

Beyond annotations (read-only, idempotent, non-destructive), the description discloses the calculation behavior: shareable mass equals assets minus debts according to regime, spouse shares, and compensation for imbalance. It also reveals the override mechanism for 'entra_partilha', which is important behavioral and semantic 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?

Two sentences, front-loaded with the tool's purpose and formula, with the override instruction as a compact second sentence. Nothing is redundant and every clause earns its place.

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

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

For a complex legal calculator with no output schema, it does enough: it describes inputs (assets/debts/regime), the computation, and the outcome (shareable mass, quotas, compensation). It does not enumerate the per-regime defaults or define each legal flag, but the override instruction plus schema enums make invocation feasible.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaning for 'bens', 'dividas', 'regime', and 'entra_partilha' by embedding them in the formula and override instruction, but it does not explain fields like 'titular', 'incomunicavel', or 'nomes', leaving some parameters to be inferred from schema enum names and structure.

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

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

The description states a specific verb and resource: it 'apura a massa partilhável' for 'partilha de bens no divórcio por regime', including each spouse's share and compensation. This level of specificity clearly separates it from sibling tools like calculo_fgts or calculo_pensao.

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

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

It gives clear context: use for divorce asset division under a Civil Code property regime, and tells the agent to mark 'entra_partilha' per asset to override the default. It does not explicitly name alternative tools or state when not to use it, but the domain context is unambiguous.

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 mark the tool as read-only and idempotent; the description adds the meaningful calculation behavior: per-month due amount across three modes, subtraction of payments, INPC correction, and 1% monthly interest from each maturity. It does not contradict any 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?

One dense, front-loaded sentence; every clause maps to a schema parameter or behavioral rule. There is no filler or restatement of the tool name.

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 9-parameter legal calculator with no schema descriptions and no output schema, the description covers the core algorithm and most inputs. It falls short only on an explicit definition of 'referencia' and the return shape, but the tool's calculation purpose is largely inferable.

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

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

With schema description coverage at 0%, the description maps the main parameters: the three 'forma' modes, pagamentos, remuneracoes, juros/indice, and the arrears period. It leaves 'referencia' and 'data_calculo' implicit and does not specify date formats.

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

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

The description names a specific resource (alimony in arrears, art. 528 CPC) and a concrete verb (calcula) with the full algorithm. It is clearly distinguishable from sibling tools such as calculo_aluguel or calculo_fgts.

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 legal context and subject matter ('Pensão alimentícia em atraso') make the intended use case explicit. It does not name alternative tools or state exclusions, but against the sibling list the selection is unambiguous.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful behavioral context: it performs mathematical computation on multiple factors, discounts remição (work/study) and detração, and returns a date. However, it does not disclose the exact legal fraction percentages applied, rounding rules, or how missing optional factors are treated.

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, dense sentence that packs a lot of legal and computational detail without padding. It front-loads the core purpose (progressão de regime) and the legal basis. It loses one point because the technical terms and symbols are not separated (e.g., ×) and the sentence is long enough that an agent might need to parse carefully.

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 computational tool with 9 parameters and no output schema, the description conveys the main inputs and the output type (date). Given annotations declare it safe and idempotent, and the sibling list makes the domain clear, this is mostly complete. Missing details are the exact legal percentage table and the date format, but those are arguably algorithmic details rather than invocation-critical.

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

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

Schema description coverage is 0%, so the description carries the full burden of explaining 9 parameters. The description does mention key concepts (primário/reincidente, comum/hediondo, violência/morte, remição, detração), which map to the boolean and numeric parameters (reincidente, hediondo, violencia, resultado_morte, horas_estudo, dias_trabalhados). However, it does not explain the date format for inicio_cumprimento or the unit interpretation of pena_anos (decimal years).

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

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

The description identifies the specific legal basis (LEP art. 112, Lei 13.964/2019), the exact computation factors (primário/reincidente, comum/hediondo, violência/morte, remição, detração), and the output (data de progressão). This clearly distinguishes it from sibling calculo_* tools, which cover unrelated domains like aluguel, FGTS, and pensão. The verb is implicit ('calcula') but the resource and scope are precise.

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 criminal penalty progression calculations, which is evident from the legal citation and factors. However, it does not explicitly state when to use this over siblings like calculo_dosimetria (which likely covers sentence calculation) or how to decide between them. There is no exclusionary language or 'use instead' 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?

As anotações já cobrem readOnlyHint, idempotentHint e destructiveHint. A descrição acrescenta contexto comportamental valioso: restring-se a códigos específicos e ao ressarcimento via acordo STF (ADPF 1.236), sem contradizer as anotações.

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?

Duas frases curtas, com o propósito na frente e sem redundáncia. A referência ao acordo STF adiciona contexto sem inchaço.

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?

A ferramenta tem 3 parâmetros, sem output schema e sem descrição do retorno. Falta dizer se o resultado é um total único, uma lista corrigida ou um detalhamento por competência, além de como indice e data_calculo afetam o cálculo.

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?

A cobertura do schema é 0%, então a descrição deveria compensar explicando descontos, indice e data_calculo. Ela apenas alude a 'parcelas descontadas corrigidas', o que sugere os campos, mas não explica formato, obrigatoriedade, competencia ou papel do indice e da data de cálculo.

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?

A descrição define com verbo específico ('soma'), recurso claro ('parcelas descontadas no INSS') e escopo delimitado ('códigos 280/304/310/378'), o que a distingue das demais ferramentas calculo_* pela matéria previdenciária e pelo objetivo de restituiçã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?

O contexto de uso é claro: ferramenta para restituição administrativa de descontos indevidos no INSS via acordo STF. Não há, porém, exclusão explícita de alternativas nem menção de quando não usá-la, embora o dominio previdenciário já oriente o agente.

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, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavior beyond that: it performs a live BACEN lookup by modality and month, and it clarifies that the average rate is a reference, not a cap (STJ). This is useful operational and legal context not available from annotations alone.

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 tight sentences with no filler. It front-loads the domain and core action, then gives the essential legal caveat about the reference rate. Every sentence earns its place.

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

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

The description conveys the main purpose, the output concept (excesso por parcela), and the legal status of the rate. But with no output schema and 8 parameters, it leaves ambiguity about how optional inputs like modalidade and data_contrato affect the live BACEN lookup, and whether taxa_bacen_am overrides the live search. These are material gaps 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 0%, so the description must compensate. It partially does: 'modalidade+mês' explains modalidade and data_contrato, 'Price ou SAC' explains the sistema enum, and 'taxa média' relates to taxa_bacen_am. However, it does not explicitly map the required parameters valor_financiado, num_parcelas, taxa_contratada_am, and parcela_paga, leaving a meaningful gap for a tool with 8 parameters.

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

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

The description clearly identifies the tool as a bank contract revisional calculation that recalculates financing using BACEN's average market rate and computes the excess per installment under Price or SAC. This specific verb+resource combination distinguishes it from sibling calculo_* tools covering FGTS, trabalhista, aluguel, etc.

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 an explicit use case: revisional de contrato bancário, recalculating a loan based on the BACEN average rate and computing excess per installment. It does not explicitly name when not to use it or list alternative sibling tools, but the domain and calculation type are 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?

Annotations already signal readOnly, idempotent, and non-destructive behavior. The description adds behavioral context by mentioning the 5% limit and corrected restitution of discounts, but it does not disclose output shape, error behavior, or assumptions, so it only modestly extends the annotation data.

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 compact and front-loaded with the core RMC/RCC scope and key quantitative thresholds. The legal thesis sentence adds useful context without being repetitive, so each 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?

For a financial/legal calculation with five parameters, no output schema, and zero per-parameter documentation, the description is too thin for reliable invocation. It sets the domain but does not clarify input semantics, especially the index enum, nor how the 5% and restitution rules are applied.

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

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

Schema description coverage is 0%, and the description does not explain individual parameters. It indirectly relates to 'descontos' and to 'RMC/RCC' via `tipo`, but leaves `indice`, `data_calculo`, and `beneficio_mensal` semantically undocumented, which is a significant gap for a 5-parameter tool.

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

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

The description identifies the RMC/RCC consignable-margin domain, cites INSS codes 217/268, and mentions the 5% limit, which clearly distinguishes it from sibling calculation tools. However, it never states an explicit verb such as 'calculates' or 'returns'; it is a noun-phrase description of the subject matter, 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 domain context implies when to use this tool: for RMC/RCC card margin calculations tied to INSS and the revolving-card thesis. It does not name alternative tools or state when not to use it, so the guidance is implied rather than explicit.

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

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

As anotações já declaram readOnlyHint=true e idempotentHint=true, e a descrição não contradiz isso. Além das anotações, a descrição revela o comportamento central: a regra do coeficiente (60% + 2% por ano acima de 20H/15M) e a aplicação de piso e teto. Faltam detalhes sobre formato de retorno e casos extremos, mas a segurança da operação já está coberta pelas anotações.

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

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

A descrição é uma única frase densa e bem estruturada, começando pelo nome completo e depois condensando fórmula, limiares e limites sem palavras desnecessárias. Cada trecho contribui para o entendimento do cálculo.

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?

Apesar de cobrir bem a fórmula e os parâmetros, a descrição omite informações práticas: não há output schema, não declara o formato do valor retornado, unidades ou arredondamento, nem se teto_inss e salario_minimo têm valores padrão quando omitidos. A distinção entre obrigatórios e opcionais só aparece no schema, não na descrição.

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?

Com 0% de cobertura descritiva no schema, a descrição precisa dar significado aos parâmetros, e ela faz isso: media_salarios corresponde a 'média dos salários de contribuição'; tempo_contribuicao_anos e sexo estão codificados na regra '20H/15M'; salario_minimo e teto_inss correspondem a 'piso' e 'teto'. Todos os cinco parâmetros são explicados semanticamente pela fórmula.

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?

A descrição abre com 'RMI — Renda Mensal Inicial' e declara exatamente o que a ferramenta calcula: média dos salários de contribuição vezes coeficiente, com piso e teto. Isso identifica claramente o recurso e o distingue das calculadoras irmãs como calculo_pensao ou calculo_tempo_contribuicao.

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?

Não há orientação explícita sobre quando usar esta ferramenta em vez das alternativas, nem exclusões mencionadas. A fórmula sugere que o uso é para cálculo de RMI pós-reforma EC 103/2019, mas isso fica implícito, sem comparar com outras calculadoras do INSS.

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, idempotentHint, and non-destructive behavior. The description adds useful behavioral context: the value is dynamic and comes from IPEADATA, implying it is not a static table. It does not explain what happens when 'ano' is omitted, whether historical years are covered, or what the return payload looks like, so the extra disclosure is moderate.

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 short, front-loaded with the core meaning, and every part contributes value. The dynamic data source and the legal use cases are packed into two sentences with no filler. A bit more structure or explicit parameter framing could improve it, but 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?

For a tool with a single optional parameter, no output schema, and no parameter documentation, the description leaves important gaps: what 'ano' means, whether omitting it returns the current year, and what the returned value contains. The read-only annotations reduce safety concerns, but an agent still lacks enough information to invoke the tool with full confidence.

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 one parameter, 'ano', with 0% schema description coverage. The description mentions 'de um ano', which weakly hints that the parameter represents a year, but it never explicitly explains the 'ano' parameter, its allowed range, optionality, or default behavior. Since the schema gives no semantic help, the description should compensate but does not.

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 resource: the current national minimum wage for a year, sourced dynamically from IPEADATA. It also signals the tool's legal purpose (day-fine, percentage-based pension, existential minimum), which helps distinguish it from general calculation siblings. However, it is phrased as a noun phrase rather than a verb-led statement and does not explicitly differentiate from any sibling tool by name.

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

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

The description gives concrete usage context by stating the tool is the basis for dosimetria (dia-multa), pensão por % do SM, and mínimo existencial. This tells an agent when this value is needed. It does not mention when not to use it or point to an alternative tool, so it stops short of full routing 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 already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying the legal basis, the R$600 parameterizable minimum existencial, and the 5-year plan horizon, which goes beyond the structured 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 dense sentence with no filler. It front-loads the domain and legal reference, then lists the key outputs and constraints. Every phrase contributes to understanding the tool.

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

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

Given the absence of an output schema, the description adequately lists the return concepts: percentage of committed income, minimum existencial, available income, and payment capacity. Combined with the input schema and safe annotations, an agent has enough context to invoke the tool correctly, though it could more explicitly map inputs to parameters.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for some parameters: minimo_existencial is described as R$600 parametrizável, prazo_meses is implied by 'plano de até 5 anos', and renda_liquida is implied by '% da renda comprometida'. However, it does not explain the dividas array structure (saldo, parcela, credor) or the exact meaning/units of the other parameters.

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

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

The description clearly identifies the domain (superendividamento under Lei 14.181/2021) and enumerates the computed outputs: percentage of committed income, existential minimum, available income, and payment capacity. This makes the tool distinguishable among the calculo_* siblings, though it lacks an explicit verb such as 'calculates' and does not directly contrast with another 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 implies usage: it is the tool for over-indebtedness calculations involving income, debts, and a payment plan. However, it never explicitly states when to use it versus alternatives, nor mentions any when-not-to-use conditions.

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

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

Annotations already mark the tool read-only and idempotent, and the description goes beyond them with concrete behavior: it counts simultaneous vínculos once, converts special activity using EC 103/2019 factors only through 13/11/2019, and returns total time plus a threshold check. These details materially shape how an agent invokes and interprets the 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?

Two dense sentences with no filler. The main subject is front-loaded ('Tempo de contribuição (CNIS)'), followed by the algorithm and return values; every clause adds 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 complex legal calculation with no output schema, the description covers the main inputs, the key rules, and the return value at a high level. It is slightly incomplete around output format and date/string formats, but it is still sufficient for an agent to call 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 description coverage is 0%, so the description must add meaning. It does: 'soma os vínculos' explains the array semantics, 'converte atividade especial' clarifies the tipo enum, and the 35H/30M threshold implies how sexo is used. It does not define date format for inicio/fim or map each ESPECIAL_* value to its factor, leaving a small 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 identifies a specific verb and resource: it computes contribution time from CNIS vínculos, explicitly naming the calculation rules (concomitância counted once, special-activity conversion). The scope is clearly distinct from sibling calculo_* tools (RMI, FGTS, dosimetria), so an agent can tell what this tool does without opening the schema.

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

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

The usage context is implied ('use this when you need CNIS contribution time and special-activity conversion'), but there is no explicit when/when-not guidance or named alternatives. Given many calculo_* siblings, explicit routing would help.

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 establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only behavior is covered. The description adds useful operational context such as 2026 tax tables and exempt indemnity amounts, but it does not disclose output format or calculation limitations.

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

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

The description is a single dense sentence that front-loads the tool's purpose and immediately follows with a concrete list of calculated items. Every phrase contributes domain information; the closing tax-exemption note is relevant and non-redundant.

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 calculator with safe annotations, the description provides adequate domain coverage and legal references. However, with nine parameters, no output schema, and no parameter descriptions, an agent still needs to infer input conventions and result shape, so completeness is only moderately 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?

With 0% schema description coverage, the description partially compensates by naming concepts tied to parameters: aviso prévio, férias vencidas, FGTS multa, and INSS/IRRF discounts. It does not explicitly explain formats or less obvious parameters like projetar_aviso, admissao, demissao, and dependentes, leaving some inference required.

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 domain: Brazilian CLT severance calculation ('Verbas rescisórias / liquidação trabalhista (CLT)') and lists the exact component items. It does not explicitly contrast it with sibling tools like calculo_fgts, so it misses the top-tier sibling differentiation, but the component list makes 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?

Usage is implied by the domain label 'rescisão trabalhista' and the list of severance components; an agent can infer this tool is for CLT termination payouts. However, there is no explicit when-to-use/when-not-to-use guidance or mention of sibling alternatives such as calculo_fgts or calculo_pensao.

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 read-only, idempotent, non-destructive behavior. The description adds meaningful conditional behavior: exactly what the response looks like when all providers are connected (authenticated:true, empty pending[]) and when credentials are missing (connect_url for toolkit and per-install URLs). This goes beyond annotation data and clarifies state-dependent output.

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

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

The description is three short sentences, each carrying information about the output in different states. It avoids filler and front-loads the core purpose ('Returns connection status and URLs') before giving conditional details. Every sentence earns its place.

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

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

This is a zero-parameter read-only status tool, and the description covers both key states (connected vs missing credentials) with expected fields. No output schema is present, so the description's explicit mention of authenticated, pending, and connect_url fills the gap. Nothing an agent needs to invoke this tool correctly is missing.

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

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

There are zero parameters, and the schema coverage is 100% (empty schema fully describes the input). With no parameters, the description does not need to add parameter meaning, and it correctly stays silent on inputs. Baseline 4 for zero parameters applies.

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

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

The description opens with the verb 'Returns' and the resource 'connection status and URLs,' making the read-only purpose immediately clear. It does not explicitly name sibling tools like authenticate, but the contrast between returning status and performing authentication is implied. This is clear but lacks explicit sibling differentiation, so 4.

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 contexts: call this to check connection status, and when credentials are missing it tells you where to connect. It does not explicitly say 'use authenticate to connect' or list exclusions, so guidance is minimal but not absent. This matches implied 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?

Beyond the sparse annotations, it discloses that invoke runs a tool one-off even when not installed, returns a connect link when credentials are needed, and returns a checkout/top-up link when the wallet is empty before retrying. It also states that writes require workspace owner/admin, which the annotation flags do not convey.

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 long but dense; each clause covers a distinct action, flow step, or constraint (e.g., 'without bloating the tool list', 'opens without login'). It is front-loaded with the tool's identity and core flow, and the KEY highlight draws attention to the most important behavior.

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

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

For a 14-action, 23-param tool with no output schema, it covers the central round trip (discover → describe → invoke), auth/payment fallbacks, install-vs-invoke tradeoffs, permissions, and the entire prompt-library subfeature. Notable gaps are the 'resume' action and several optional params like immediate and tier_slug, which are never mentioned.

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

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

With 0% schema description coverage, the description compensates for the core workflow by explaining action, query ('find an MCP that does X'), mcp_id/tool_id selection, prompt_vars filling, and prompt_slug links. However, ancillary parameters such as limit, immediate, tier_slug, message, conversation, report_context, and prompt_targets receive no explanation, so the compensation is only partial.

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 by defining the tool as the mcp.ai marketplace catalog and execution layer, then enumerates its actions and the core flow (search → describe → invoke). Despite the generic name, an agent can tell this is the discovery-and-runtime tool for MCPs and prompt-library operations, clearly distinct from the domain calculators listed as siblings.

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

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

It gives explicit routing rules: 'prefer invoke for a single/occasional use' vs 'Use install only to make an MCP PERMANENT', and 'request_mcp asks us to build a NEW MCP when nothing fits.' It also separates prompt-library actions from MCP actions, so the agent knows when to call search_prompts/get_prompt/publish_prompt.

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 idempotentHint=true, readOnlyHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that conversation context is needed for reproduction, but it does not disclose what happens after submission, whether external transmission occurs, or what the response contains. It does not contradict 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 with no filler and no redundant restating of the tool name. The only structural issue is the inaccurate 'conversation array' wording, which slightly undermines its clarity.

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

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

With no output schema and no parameter descriptions in the schema, this one-sentence description is incomplete. It omits the semantics of the required message field, the expected format of conversation as a string, and any post-call behavior, leaving an agent without enough detail to invoke the tool reliably.

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

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

Schema description coverage is 0%, so the description must explain all three parameters, but it only addresses conversation. Worse, it calls conversation an 'array' while the schema types it as a string defaulting to '[]', which could mislead an agent into passing an array instead of a JSON string. The required message parameter and optional context parameter receive no explanation.

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

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

The description names the operation explicitly—report a bug, missing feature, or send feedback—and clearly distinguishes this tool from the unrelated calculator and marketplace sibling tools. An agent can immediately tell what resource this acts on.

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, but it does not explicitly say when to use it versus alternatives or when not to use it. The instruction to include recent messages for reproduction is operational detail, not selection 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 already declare readOnlyHint, idempotentHint, and destructiveHint false, describing the safety profile. The description adds only the phrase 'current', which slightly clarifies freshness but does not meaningfully expand on behavior 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?

A single concise sentence with no redundant filler. The gerund 'Show' front-loads the action and the resource is specified with just enough 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 trivial parameter surface, rich annotations, and no output schema, the description sufficiently communicates what the tool returns: current MCP platform and adapter versions. It does not describe output formatting, but for a version-info tool 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 tool has zero parameters, so the schema provides complete coverage and there is nothing for the description to clarify. Baseline 4 is appropriate because the description is not required to explain parameter meaning.

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

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

The description states a specific verb ('Show') and a clear resource ('MCP platform and adapter versions'), making the tool's purpose immediately understandable. It is also distinct from the sibling tools, none of which target version information.

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

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

The description gives no guidance about when to use this tool versus alternatives such as toolkit_info or connect. For a simple zero-parameter tool this is functional, but the absence of any usage context keeps it at the 'no guidance' 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context by specifying what the returned state contains (installed MCPs, connection status, accounts, catalog tool counts), which goes beyond the annotations without contradicting them.

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

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

The description is a single, well-structured sentence that front-loads the main purpose and then lists the key components of the returned state. Every word adds value, 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 tool with no parameters, read-only/idempotent annotations, and no output schema, the description sufficiently covers what the tool does and what the return value contains. No critical information about invocation or expected results is missing.

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

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

The input schema has zero parameters, and schema description coverage is 100%, so there are no parameter semantics to clarify. Per the baseline for zero-parameter tools, this scores 4 because the description appropriately omits irrelevant parameter details.

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 ('Returns') and a specific resource ('current toolkit state'), then enumerates exactly what that state includes: installed MCPs, connection status, connected accounts, and catalog tool counts. This clearly distinguishes it from the sibling tools like authenticate or calculo_* which serve different purposes.

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 when an agent needs an overview of the toolkit's installed MCPs and their status, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. No exclusions or alternative tool references are provided, so the guidance is only implicit.

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