Cálculo de FGTS

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

Annotations only provide idempotent and non-destructive hints. The description adds valuable behavioral context: the permanent non-expiring config approach vs session-only login, the link-generation behavior with no args, and the header format. It does not disclose what happens on invalid tokens or whether server state changes, but the added context is solid.

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 with a clear 'Best' vs 'Or' structure, and every clause earns its place. Slightly verbose in the first sentence, but the front-loaded purpose and scannable alternatives make it effective.

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 main flows and return for the no-args case (get the link), but does not describe the return value when a token is passed, nor any failure modes. With no output schema and no additional annotations beyond idempotency, this is a noticeable gap for an authentication 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 has a single token parameter with no description, but the description fully explains it: it is an optional JWT pasted by the user for session-only login, and omitting it returns the login link. This completely compensates for the schema's lack of 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 tool's purpose: authenticating the user for this MCP server by logging in the browser and obtaining an access token. It distinguishes itself from the sibling calculo_* tools, which are calculation-oriented, though it does not explicitly name an alternative auth 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 provides explicit guidance on when to use each invocation mode: permanent setup via config header vs session-only login by pasting a token, and using no args to get the login link. It lacks an explicit 'do not use when already authenticated' note, but the conditional routing 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?

The description discloses the full calculation behavior: index-based adjustment over the contract, correction of each overdue month through today, 1% monthly mora interest, late-payment penalty, and monthly-plus-total output. This goes well beyond the readOnlyHint/idempotentHint annotations and is consistent with them, with no contradiction.

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 front-loads the use case and legal basis, then describes the calculation steps in order, and ends with the return shape. No filler or repetition; 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?

The description is adequate to identify the tool and understand its main behavior, but for a complex legal-financial calculation with 9 parameters, no output schema, and no per-property descriptions, it leaves notable gaps: no default assumptions when optional parameters are omitted, no date format guidance, and only a vague 'detalhamento por mês + total' for return structure.

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 to core parameters: aluguel_inicial, inicio_contrato, inicio_atraso/fim_atraso, juros (1% a.m.), multa, and indice are all referenced directly. However, it does not explain optional parameter semantics such as periodicidade_meses, whether juros/multa are overrides or defaults, or expected date formats, leaving gaps for a 9-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 names a specific resource ('Aluguéis em atraso (Lei 8.245/91)') and a clear set of actions: it adjusts the rent by the index, corrects each overdue month until today, applies 1% monthly mora interest and a late-payment penalty, and returns a monthly breakdown plus total. This clearly distinguishes it from sibling tools like calculo_indice or calculo_atualizar.

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 opening phrase 'Aluguéis em atraso' clearly signals the intended scenario: overdue rent calculations under Brazil's Lease Law. It does not explicitly name alternatives or state when not to use it, so it falls short of full routing guidance, but the context is unambiguous enough for an agent to select it over related calculo_* 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it warns about the SELIC regime and the post-2024 legal framework, and states that the tool returns a per-installment breakdown plus totals. This is genuinely useful calibration for legal calculations.

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

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

Three sentences with no filler. The purpose is front-loaded, the return behavior is stated, and the legal warning is compact but critical. Every sentence earns its place and the warning is placed at the end where it does not obscure the main 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?

This is a complex legal calculation tool with 11 parameters, no output schema, and no parameter descriptions in the schema. The description covers the high-level purpose and the return shape, but it is not complete enough to correctly invoke the tool for all parameters, especially the many optional legal-calculation toggles and date/interest modes.

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 for 11 undocumented parameters. It only vaguely references indices, interest, fines, and fees, and mentions SELIC's special behavior, but it does not explain key parameters such as pro_rata, periodicidade_juros, multa_incide_sobre_juros, honorarios_tipo, data_calculo, or the structure of parcelas. Too much parameter meaning is left to the agent to infer.

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 purpose: monetary updating and judicial debt settlement, correcting installments by an official index and applying interest, fines, and fees. It clearly distinguishes this from siblings like calculo_aluguel or calculo_indice by naming the exact financial-legal operation and the return of per-installment details and totals.

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 strong usage context, especially the legal warning: SELIC already includes both correction and interest, and post-September/2024 civil cases use IPCA plus the legal rate under Lei 14.905/2024. This guides correct parameter selection and prevents double-counting, though it does not explicitly name alternative sibling tools or state when not to use this tool.

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 readOnly, idempotent, non-destructive behavior. The description adds algorithmic transparency by detailing the three-phase computation and noting that fractions are configurable, which is useful 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?

Three compact sentences front-load the core definition and then add the legal-phases detail and the configurable-fractions note. No redundant wording.

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 9 parameters, 0% schema coverage, and no output schema, the description still omits expected return shape, input constraints or units, and how the optional parameters interact. It is conceptually rich but operationally 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 description coverage is 0%, so the description must compensate. It maps legal concepts to the phase-related parameters (aggravating/mitigating factors, increase/decrease causes, configurable fractions) but leaves some parameters (pena_min_anos, pena_max_anos) and array item requirements implicit.

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 (penalty dosimetry under Brazil's three-phase system) and breaks down the three phases with legal references (art. 59, STJ Precedente 231, causes of increase/decrease). This clearly distinguishes it from sibling calculo_* tools covering unrelated financial and labor calculations.

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 makes the intended use case clear, but no explicit when-to-use/when-not-to-use guidance or comparison to sibling tools is provided. An agent must infer that all other calculo_* tools are out of scope.

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

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

As anotações já cobrem readOnlyHint, idempotentHint e destructiveHint. A descrição adiciona contexto comportamental valioso: cálculo por depósito, juros de 3% a.a., depósitos manuais e OCR apenas futuramente. Não contradiz 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, sem repetição do nome da ferramenta e com a informação central apresentada logo no início. A menção ao OCR futuro é contextual e não polui a definiçã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?

Não há output schema nem descrição explícita do retorno, e os detalhes de parâmetros são insuficientes. Para uma ferramenta com 4 parâmetros e um array obrigatório de depósitos, faltam informações sobre formato dos itens, saída e possíveis padrões ou defaults.

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 de descrição no schema é 0%, então a descrição deveria compensar. Ela menciona conceitos como depósitos, índice de inflação e juros de 3%, mas não enumera os quatro parâmetros nem explica a estrutura esperada de cada depósito. Fica uma lacuna relevante para invocação correta.

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 tem verbo específico ('calcula a diferença'), recurso específico (FGTS) e contexto jurídico delimitado (tese TR → INPC/IPCA-E, STF). Isso a distingue claramente de irmãos genéricos como calculo_indice, calculo_revisional e 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?

O contexto de uso fica claro: correção de FGTS segundo a tese do STF, por depósito. Porém, não há exclusões explícitas nem menção a alternativas ou situações em que outro cálculo deveria ser usado.

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 read-only and idempotent, and the description adds meaningful behavior: the month-inclusive/exclusive convention, the conditional outputs, and the instruction to pull raw indices when `incluir_valores` is set. No contradiction 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 dense sentences pack purpose, date convention, and conditional modes without padding. The front-loading of the core operation makes the primary action clear immediately.

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 query with no output schema, the description covers the main return types (corrected value, monthly variations) and the critical date convention. The absence of `pro_rata` semantics and an explicit output example leave minor gaps, but the core call pattern is well-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?

Schema description coverage is 0%, so the description must carry parameter meaning. It explicitly explains `valor` and `incluir_valores`, and implicitly covers `data_inicial`/`data_final` through the 'between two dates' phrasing and month convention. However, `pro_rata` is never mentioned, and the `indice` enum is only referenced generically as 'índice oficial', leaving a gap for a tool with six 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 specifies a concrete operation: querying an official index's accumulated correction factor between two dates, with the BACEN/IBGE month convention. It also clarifies two result modes (corrected value or monthly variations), which distinguishes it from sibling calculation tools that target specific subjects like FGTS or aluguel. Though it does not name a sibling, the resource and operation are 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 explains conditional behavior — when `valor` is supplied it returns the corrected amount, and when `incluir_valores` is true it returns raw monthly changes — which guides invocation parameter usage. However, it does not explicitly state when to choose this tool over alternatives or when not to use it. The guidance is implied by the domain 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?

Annotations already provide readOnlyHint and idempotentHint, and the description does not contradict them. It adds useful computational behavior beyond the annotations: it explains that the tool applies a regime-specific default for inclusion in the shared estate and that setting 'entra_partilha' on an asset overrides that default. It also previews the key result components: shareable mass, each spouse's quota, and equalization.

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 dense sentences with no filler: the first sentence front-loads the core computation and outputs, and the second gives one actionable tip about the override flag. Every word contributes to tool selection or correct invocation.

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 complex nested inputs, four distinct regimes, and no output schema, the description provides a strong high-level contract but not a complete one. It explains inputs conceptually and previews the main outputs, but it does not specify how each regime affects the default treatment, what the less obvious ownership flags mean, or the output structure, leaving some room for inference.

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 carry parameter meaning. It does relate 'bens', 'dividas', and 'regime' through the formula and explains the override role of 'entra_partilha'. However, it leaves several nested properties unexplained ('oneroso', 'titular', 'heranca_doacao', 'adquirido_na_constancia', 'anterior_casamento', and the 'nomes' object), so an agent still cannot fully infer their semantics.

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 and resource: it calculates property division in divorce under the Civil Code, explicitly stating the formula (assets minus debts per regime) and the outputs (each spouse's share, equalization payment). This clearly differentiates it from the other calculo_* sibling tools even without naming them.

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 invocation context unambiguous: it is for divorce property sharing under a marital property regime, not alimony, labor, or housing calculations. It does not list exclusions or alternative tools explicitly, but the domain-specified wording is enough to route an agent correctly.

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, idempotentHint, and destructiveHint already covering the safety profile, the description adds real algorithmic transparency: per-month due computation, payment deduction, INPC correction, and 1% monthly interest from each due date. It does not explain how an explicit `indice` parameter interacts with the stated INPC default, but the core behavior is clear.

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 with no filler; the legal context is front-loaded and every clause adds calculation detail. It is not broken into sections, but it is appropriately compact for a calculation 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 no output schema and 9 parameters with zero schema descriptions, some gaps remain: the return format is not stated, and `referencia` and `data_calculo` are not explicitly explained. The algorithm is well summarized, so the description is adequate but not fully complete for all invocation details.

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

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

At 0% schema coverage, the description carries the burden and mostly compensates: it explains the `forma` enum (percentage of minimum wage, fixed value, percentage of remuneration), `pagamentos` (subtracted), `juros` (1% monthly), the period parameters, and `remuneracoes`. It leaves `referencia` and `data_calculo` implicit, but the calculation modes imply the role of `referencia`.

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 calculates overdue alimony under art. 528 CPC and specifies the three calculation modes. The phrase 'pensão alimentícia em atraso' distinguishes it from the many sibling cálculo tools without needing to inspect their schemas.

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 a clear triggering context — overdue alimony under art. 528 CPC — and what the calculation covers. It does not explicitly name alternatives or state when not to use it, but the domain label is specific enough to route an agent correctly.

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 the core behavior beyond the annotations: it computes a completion percentage using stated factors, discounts remição and detração, and returns a date. Annotations already mark it read-only and idempotent, and nothing in the description contradicts 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?

One dense, front-loaded sentence that packs legal basis, formula variables, discounting behavior, and return value with no filler. Every clause contributes.

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 calculator with no output schema, the description covers the legal context, the main input factors, the discounting logic, and the output. It leaves minor gaps such as exact required-parameter mapping and return structure, but annotations cover the safety profile, making the overall guidance sufficient.

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

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

Schema description coverage is 0%, so the description carries the semantic burden. It compensates by mapping domain concepts to the parameters (primário/reincidente maps to reincidente, comum/hediondo to hediondo, violência/resultado morte to violencia/resultado_morte, trabalho/estudo to hours/days worked, detração to dias_detracao). It does not explicitly state units or date formats, but the conceptual mapping is strong.

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 computation ('Progressão de regime'), cites the controlling legal provisions (LEP art. 112, Lei 13.964/2019), and enumerates the factors that distinguish it from sibling calculators (recidivism, heinous crime, violence/death). It also states the output (progressão date), so an agent can tell exactly what the tool does.

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-citation-heavy description makes the intended use clear: calculating Brazilian prison regime progression. It does not explicitly say when not to use it or name an alternative (e.g., calculo_dosimetria), so it lacks the explicit routing of the strongest definitions.

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, so no safety contradiction exists. The description adds behavioral context by explaining this is an administrative reimbursement calculation that sums corrected installments, which helps the agent understand the tool's output nature 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 two sentences with no filler. The first sentence states the core purpose and scope, and the second adds the legal context. Every part contributes to understanding what the tool does and when it applies.

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 establishes the legal context and core calculation, and annotations cover safety behavior. However, with no output schema and zero parameter documentation, it leaves gaps around how `indice` and `data_calculo` affect the calculation and what exactly is returned. Adequate for routing, but not fully complete 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, but it only indirectly references discounted installments and correction. It does not explain the meaning of the `indice` enum, the required structure of `descontos` items (competencia/valor), or the role of `data_calculo`. An agent would have to infer parameter semantics from schema structure alone.

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 operation — restitution of undue INSS discounts — and provides concrete identifying details: the fraud codes 280/304/310/378 and the STF ADPF 1.236 agreement. It states the calculation action ('soma as parcelas descontadas corrigidas') and is clearly distinguishable from sibling tools like calculo_fgts, calculo_rmi, or calculo_revisional.

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 a clear usage context: administrative reimbursement of undue INSS discounts associated with specific codes and a specific legal framework. It does not explicitly name alternative tools or state when not to use it, but the legal and code constraints are specific enough to guide 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?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint values. The description adds valuable behavioral context: it performs a live BACEN lookup by modality+month, supports Price or SAC, and clarifies that the average rate is a reference, not a ceiling, per STJ. There is 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 two sentences with no filler. It front-loads the core purpose, then adds the key calculation method and an important legal caveat. 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 annotations cover the side-effect profile, and the description explains the core algorithm well. Still, with no output schema and 8 parameters whose schema descriptions are absent, the description omits the output format and the behavior/meaning of several optional parameters. It is usable for invocation but not 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 description coverage is 0%, so the description must compensate. It adds meaning by tying modalidade+mês to the live BACEN lookup and Price/SAC to the sistema parameter, and 'excedente por parcela' clarifies parcela_paga. However, it does not map all 8 parameters or explain optional fields like taxa_bacen_am and data_contrato in 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 opens with 'Revisional de contrato bancário' and states a specific verb: 'recalcula o financiamento' and 'apura o excedente por parcela'. The resource and scope are clear, and the bank-contract-revision domain distinguishes it from the sibling calculo_* tools without ambiguity.

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 phrase 'Revisional de contrato bancário' clearly establishes when this tool applies: bank loan contract revision using BACEN average rates. It does not explicitly name alternatives or exclusions, so it stops short of a 5, but the use case is clearly framed.

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á estabelecem comportamento somente-leitura, idempotente e não destrutivo. A descrição agrega lógica operacional: calcula um teto de 5% e uma restituição corrigida, além de expor a tese jurídica de cartão rotativo vendido como consignado que nunca amortiza. Isso é contexto comportamental útil além das 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 é concisa e começa pelo acrônimo e escopo INSS; a cláusula da tese acrescenta contexto jurídico relevante de forma compacta. Perde um ponto por usar jargão técnico/abreviações que podem exigir decodificação, mas não há 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?

Para um cálculo com cinco parâmetros, schema sem descrição de parâmetros e sem schema de saída, a descrição é insuficiente. Deixa sem explicação o mapeamento dos parâmetros, o formato do retorno e a escolha entre esta e outras ferramentas de cálculo INSS.

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 de descrição do schema é 0%, então a descrição deveria explicar os parâmetros, mas apenas alude a 'descontos' e ao limite de 5%. Não explica tipo (RMC vs RCC), indice (qual índice de correção e como é aplicado), data_calculo, beneficio_mensal ou os campos obrigatórios competencia/valor dentro de descontos.

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 identifica um domínio de cálculo específico — RMC/RCC, reserva de margem consignável de cartão com códigos INSS 217/268 — e explicita os dois resultados calculados: limite de 5% e restituição corrigida dos descontos. É clara, mas não usa um verbo explícito como 'calcula' e não diferencia a ferramenta de irmãs próximas como calculo_restituicao_inss.

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 escopo é claramente delimitado a casos RMC/RCC com códigos INSS 217/268, o que permite ao agente reconhecer quando a ferramenta se aplica. No entanto, não há exclusões nem comparação explícita com ferramentas irmãs relacionadas, como calculo_restituicao_inss ou calculo_revisional.

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 the computational behavior: it averages contribution salaries, applies a sex-dependent coefficient (60% plus 2% per year above 20 for men/15 for women), and enforces the minimum-wage floor and INSS cap. This adds meaningful behavioral context beyond the readOnly/idempotent/non-destructive annotations, though edge cases like rounding or floor/cap precedence are not addressed.

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 entire definition fits into one dense, front-loaded sentence: the concept and legal context come first, followed immediately by the formula and constraints. There is no filler, and every clause contributes to understanding the calculation.

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 core formula, floor, and cap, which is substantial for a calculation tool, but with no output schema it does not state the return value/format, rounding behavior, or how optional floor/cap inputs are handled when absent. An agent would still need to infer some operational details before invoking it correctly.

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

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

With 0% schema description coverage, the formula text compensates well: 'média dos salários de contribuição' maps to media_salarios, 'salário mínimo' to salario_minimo, 'teto (INSS)' to teto_inss, and '20H/15M' conveys the roles of sexo and tempo_contribuicao_anos. It does not explicitly enumerate the parameters or note which are optional/defaulted, so a perfect score is not warranted.

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 resource (RMI/Renda Mensal Inicial), anchors it to the post-EC 103/2019 reform, and states the calculation as average salary × coefficient with floor and cap. This formula-level specificity separates it from sibling calculators such as calculo_pensao and calculo_rmc_rcc, even without an explicit verb.

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 use—calculating the initial monthly benefit under the post-reform INSS rules—is clearly implied by the formula and acronym, but the description never states when to choose this tool over alternatives or what it is not for. There are no exclusion criteria or sibling references, leaving routing partially 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?

Annotations already mark the call read-only, idempotent, and non-destructive; the description adds useful behavioral context by noting the value is 'dinâmico' and sourced from IPEADATA. It does not address failure modes or response format, but that is a minor omission for this simple 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?

Two compact clauses: the first defines exactly what the tool returns, and the second justifies why an agent would use it. Every sentence earns its place and there is 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 one-parameter, read-only lookup, the description is nearly complete: it gives the source, dynamic nature, year scope, and intended applications. Minor omissions are return-unit/format details and the effect of calling without 'ano'.

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 only parameter, 'ano', is mapped by the phrase 'de um ano', but the description does not cover optionality, valid year ranges, or behavior when the parameter is omitted. Since schema coverage is 0%, the description only partially compensates for that 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 identifies the tool's resource ('salário mínimo nacional vigente de um ano') and its source (IPEADATA). It lacks an explicit action verb like 'retrieves' or 'calculates', though the tool name and noun phrase make the intent 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 names concrete legal use cases ('dosimetria (dia-multa), pensão por % do SM e mínimo existencial'), so an agent can decide when this figure is relevant. It does not include when-not-to-use guidance or point to alternatives, but no close sibling tool exists.

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 read-only/idempotent behavior, and the description adds useful context about the computed metrics: committed income percentage, R$600 parameterizable minimum existential, available income, and payment capacity. It does not disclose formulas, default values beyond R$600, or exactly how the 5-year plan is capped, but the read-only annotation lowers the burden.

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 legal subject; each clause adds a distinct metric or parameter context. It is a fragment rather than a complete sentence, but it contains 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?

There is no output schema, and the description only summarizes outputs at a high level. Given a required debt array and no parameter documentation, the definition is not detailed enough for a reliable first call, even though tool selection is straightforward.

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 needed to explain inputs like renda_liquida, dividas, and prazo_meses, but it only hints at income and a 5-year plan. It does not clarify the debt structure fields (saldo, parcela, credor) or required conditions, leaving an agent to infer most parameter semantics from variable names alone.

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 specific legal subject ('Superendividamento (Lei 14.181/2021)') and enumerates the computed outputs: committed income percentage, minimum existential, available income, and payment capacity. This clearly distinguishes it from sibling calculo_* tools such as calculo_aluguel or calculo_trabalhista, although it lacks an explicit verb like 'calcula'.

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 citation and the concepts of mínimo existencial and payment capacity imply use for Brazilian over-indebtedness cases under Lei 14.181/2021. However, it does not explicitly state when not to use it or name alternative tools, so the guidance remains implied rather than directive.

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 annotations (readOnlyHint, idempotentHint, non-destructive), the description discloses important behavioral details: concurrent vínculos are counted once, special activity conversion is limited to 13/11/2019, and the output indicates both total time and whether the old-time threshold is reached. 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 two tight sentences, front-loading the domain and then providing the algorithm and outputs. There is no filler, and every clause adds operational 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 tool with no output schema, the description explains the return values (total time and whether the old threshold is reached) and covers the key algorithm cases: concurrency, special activity conversion, date cutoff, and sex-specific thresholds. It is slightly incomplete on parameter formatting and output units, but the core behavior is well covered.

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 explains vínculos conceptually and hints at sex via 35H/30M, but it does not explain the `inicio`, `fim`, or `tipo` fields of the vínculos items, the enum meanings, or the expected date format. This is insufficient parameter guidance.

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 ('Tempo de contribuição (CNIS)') and states concrete operations: summing vínculos, counting concurrent periods once, and converting special activity to common using EC 103/2019 factors. It also states what the tool returns, making its purpose clear and distinguishable from sibling calculators.

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 through CNIS, vínculos, and the 35H/30M old-time threshold, but it never explicitly states when to choose this tool over a sibling calculator or gives exclusions/prerequisites. Usage context is present but only implied.

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. The description adds useful behavioral detail beyond that: it discloses INSS/IRRF deductions using 2026 tables, the FGTS fine rates, and that indemnity items are exempt. 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 compact: two sentences, front-loaded with the core domain, followed by an organized list of items. Every phrase adds information, including the law reference and the 2026 table 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?

Given 9 parameters, 0% schema coverage, and no output schema, the description is adequate as a high-level overview but not fully self-sufficient for nuanced calls. It does not explain required input formats, the meaning of 'projetar_aviso', or how 'motivo' influences the FGTS fine and tax treatment.

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 for the 9 parameters, but it only loosely maps to a few of them (aviso, férias, FGTS). It leaves 'motivo', 'saldo_fgts', 'projetar_aviso', 'dependentes', and date formats unexplained, and it only names the 'indenizado' aviso option, potentially obscuring the other enum values.

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 and scope: 'Verbas rescisórias / liquidação trabalhista (CLT)' and enumerates the main calculation components (saldo de salário, aviso prévio, 13º, férias, FGTS). It is unambiguous about the tool's purpose, though it lacks an explicit verb and does not explicitly contrast it with sibling calculators.

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 statement implies when to use the tool — for CLT termination/labor settlement calculations — but it does not state explicit conditions, prerequisites, or alternatives such as calculo_fgts or calculo_salario_minimo. There is clear contextual scope but no exclusions or sibling routing.

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 this is read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond that by specifying the two main response states: authenticated:true with empty pending[] when all providers are connected, and connect_url plus per-install URLs when credentials are missing. This helps an agent predict what to expect.

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

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

The description is compact, front-loads the core purpose, and then adds only the essential conditional details. Every sentence contributes meaningful information, and there is no waste.

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

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

For a zero-parameter read-only status tool with no output schema, the description is complete enough. It tells the agent what information will be returned, what the success condition looks like, and what happens when credentials are missing. The low complexity means no additional guidance is required.

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 description does not need to explain any input semantics. The baseline of 4 applies because there is no parameter burden at all.

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

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

The description clearly states the tool's purpose: returning connection status and URLs. It distinguishes connect from its sibling authenticate by framing it as a status/read operation rather than an action, and the conditional output descriptions reinforce this.

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 clear that this is the tool to call when checking connection state or getting URLs. It does not explicitly mention alternatives like authenticate, but the context strongly implies connect is for status checking rather than initiating authentication, so usage is clear without being fully 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?

Beyond the annotations, the description discloses important behaviors: invoke runs an MCP even when it is not installed, does a one-off run without adding the MCP to the toolkit, returns a connect link when credentials are needed, returns a checkout/top-up link when payment is needed, and requires workspace owner/admin for write operations. The description enriches the annotations and 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 front-loaded with identity and the core flow, and nearly every sentence carries useful guidance. However, it is one dense, wall-of-text paragraph with mixed language ("pontualmente") and heavy inline emphasis, which makes the many action alternatives hard to scan and 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 complex 23-parameter, 14-action facade with no output schema, the description is remarkably complete: it covers the core flow, one-off invoke semantics, auth/credential/payment behavior, permission requirements, installed flags, the prompt library, and most action outcomes. The main gaps are the resume action and return-shape details for a few actions, but the overall guidance is sufficient for correct invocation in most cases.

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 does a lot of compensating work: it maps action values such as search, describe, invoke, install, list_tools, publish_prompt, and explains tool_id, arguments, and prompt-related intent. However, several parameters and enum actions remain unexplained, including resume, limit, immediate, tier_slug, cancel_reason, report_context, conversation, request_name, and request_details, leaving agents under-specified for those paths.

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 the official mcp.ai marketplace: the in-platform catalog of MCPs/tools and the way to run them. It states the core discovery→describe→invoke flow, distinguishes the prompt-library subdomain from the MCP flow, and makes it clear this is a marketplace orchestrator rather than one of the sibling calculator/authenticate 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 gives explicit when-to-use guidance: use install only to make an MCP permanent, prefer invoke for one-off use, use list_tools to see what is callable now, use subscribe/cancel for billing, and use request_mcp when nothing fits. It also explains what to do when invoke returns a connect link or checkout link, including retry behavior.

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 cover the basic safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds some behavioral context by instructing the agent to include the conversation array for reproduction, implying the report is shared for debugging. However, it does not disclose privacy implications, data handling, or what happens after submission.

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 filler. The primary purpose is front-loaded, followed by a practical instruction about the conversation array. 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 core usage is clear, and the conversation guidance is helpful for a bug report. However, the 'context' parameter is completely undocumented, and the description does not indicate what the agent should expect after submitting a report. For a simple reporting tool this is adequate but has clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It only clarifies the 'conversation' parameter by explaining it should contain recent messages for reproduction. The meaning of the required 'message' and optional 'context' parameters is left entirely to inference, which is insufficient.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'Report a bug, missing feature, or send feedback.' This is unambiguous and distinguishes it from the sibling calculation tools, which serve completely different functions.

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 it clear when to use this tool: for bugs, missing features, or feedback. It does not explicitly name alternatives or exclusions, but there are no competing reporting tools among the siblings, so the usage context is sufficiently 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 annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, non-mutating call. The description adds little beyond that—it names the output as versions but doesn't specify the format (e.g., semver strings, JSON object) or whether the output is human-readable. Since the annotations carry the safety profile, 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 sentence of 9 words, front-loading the action ('Show') and the object ('version'). There is zero waste, and it fully conveys the tool's purpose within its scope. This is a model of conciseness.

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

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

For a zero-parameter, read-only, idempotent tool with no output schema, the description is nearly complete. An agent can confidently invoke it without additional context. The only minor gap is that the return format is unspecified, but since there is no output schema, a brief note on the output structure (e.g., 'returns a plain-text summary') would elevate completeness. Still, the description is sufficient 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?

The tool has zero parameters, and the schema coverage is 100% (no properties). The description doesn't need to explain parameters. The baseline for zero-parameter tools is 4, and the description is consistent with that—it correctly implies that no input is 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 states the tool's purpose: 'Show the current MCP platform and adapter versions.' This is a specific verb-resource pair that distinguishes it from sibling tools, which are all calculation or authentication tools. It could be slightly more explicit about what 'show' returns (e.g., a text summary vs. structured data), but the resource 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 that this tool is for checking version information, which makes sense in contexts where an agent needs to confirm platform/adapter versions before proceeding. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention whether version information is needed for authentication or compatibility checks. Given the sibling tools are all calculations, the usage context is reasonably clear, but not explicitly delineated.

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 description does not need to restate safety. It adds value by detailing what kind of state is returned, including connection status and account bindings, which helps the agent understand the tool's informational scope.

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 tightly packed sentence with the main action front-loaded, followed by a colon-delimited list of return contents. Every phrase earns its place with no repetition 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 zero-parameter, read-only introspection tool, the description fully covers what the agent needs to know before calling: what information it will receive. No output schema exists, but the description essentially provides a light output contract by enumerating the returned components.

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 is empty with zero parameters, and schema description coverage is 100%, so the description has no parameter burden. Per calibration, zero-parameter tools receive a baseline of 4; the description's output-focused content is more than sufficient.

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 ('Returns') and resource ('current toolkit state'), then enumerates exactly what is included: installed MCPs, connection status, connected accounts, and catalog tool counts. This is specific enough to distinguish it from computational siblings like calculo_* and action tools like authenticate or connect.

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 conveys that this is the tool to call when an agent needs an overview or snapshot of the toolkit's current state. It does not explicitly list exclusion criteria or name alternatives such as show_version, but the context is clear enough for routine selection.

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