Liquidação de Sentença

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

The description adds useful behavior beyond the annotations: config header yields a permanent connection, while passing a token yields a session-only login, and no args returns a link. It does not fully spell out side effects or success/failure return values, but annotations already cover idempotency and non-destructiveness.

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 dense and front-loaded, with no fluff, but the long single sentence with parenthetical clauses and multiple alternatives could be structured into clearer separate instructions. Still, every part adds necessary 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 one-parameter auth tool with no output schema, it covers the no-arg return (the link), the token-paste path, and the persistent-config alternative. It doesn't state the response on a token success/failure, but the invocation guidance is sufficient for an agent to call 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 coverage, the description carries the full burden for the optional `token` parameter. It explains that token is a JWT/access token pasted by the user and how to pass it, compensating well for the bare schema.

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

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

The description clearly identifies the tool as MCP.AI authentication for IDE agents, with a concrete browser-login + access-token flow and two invocation paths (no args for a link, token for login). This specific verb+resource is unambiguous and easily distinguished from the unrelated calculo_* sibling 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?

It explicitly differentiates the persistent config-header approach ('best... permanent, non-expiring') from the session-only paste/login path, and states exactly when to call with no args versus with { token }. This gives the agent clear selection criteria for both setup and invocation.

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 flow: index-based adjustment, monthly correction of overdue amounts, 1% monthly mora interest, and penalty, and it states the return format (month-by-month detail plus total). Since annotations already declare readOnlyHint=true and idempotentHint=true, the description adds useful behavioral context beyond those hints. A minor ambiguity remains about whether the optional juros/multa/indice parameters override the stated defaults, but this 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 concise sentence followed by a return-value statement. It front-loads the legal basis and domain, enumerates the computation steps in a compact list-like structure, and ends with the output shape. Every clause is informative and there is no wordiness or redundancy.

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

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

The description covers purpose, legal context, computation logic, and return format, which is reasonably complete for a read-only calculation tool. However, with 9 parameters, 0% schema coverage, and no output schema, the meaning and format of inputs are left inadequately specified, and potential relationships between optional parameters and default interest/penalty values are unclear. An agent can select this tool but may struggle to populate all parameters 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 bears the full burden of explaining parameters, but it only alludes to concepts like initial rent, contract, and overdue months without mapping them to actual fields (aluguel_inicial, inicio_contrato, inicio_atraso, fim_atraso). The optional parameters (juros, multa, indice, periodicidade_meses) are completely unexplained, and the description's phrase 'até hoje' may conflict with the required fim_atraso parameter. This is insufficient for an agent to correctly construct the invocation.

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 'reajusta' and 'corrige' overdue rents (aluguéis em atraso) under Lei 8.245/91, which clearly distinguishes it from sibling tools like calculo_fgts, calculo_pensao, or calculo_revisional. The legal basis and the focus on rent arrears make the tool's purpose unambiguous.

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

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

The description clearly indicates when to use the tool: for overdue rent calculations under the specific law. It does not explicitly name alternative tools or state when not to use it, but the domain-specific phrasing 'Aluguéis em atraso' provides enough context to route an agent correctly among the many calculo_* siblings. A slight gap is the lack of explicit comparison to related rent tools, but the context is strong.

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 read-only/idempotent/destructive annotations, the description discloses return behavior ('detalhamento por parcela e totais') and the crucial SELIC double-counting trap plus the Lei 14.905/2024 regime. This materially shapes how an agent should configure and interpret the calculation.

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

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

Three short, information-dense segments: scope/action, return shape, and critical legal warning. No filler; every sentence carries load.

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 11-parameter calculation with no output schema, the description gives purpose, output shape, and the legal caveats that prevent miscomputation. It stops short of documenting defaults (e.g. data_calculo/pro-rata) and edge-case routing, leaving some burden on the agent.

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 by explaining the role of index, interest, penalty, fees, and parcelas, and by clarifying the SELIC/interest relationship and post-2024 index choice. It does not spell out every parameter such as pro_rata or multa_incide_sobre_juros, but the core legal semantics are conveyed.

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 scope: 'Atualização monetária / liquidação de débito judicial', names the resource ('parcelas'), and states the operations: correction by official index plus interest, fine, and fees. This clearly differentiates it from siblings like calculo_indice or calculo_trabalhista without requiring schema inspection.

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 a clear use context (judicial debt settlement/monetary update) and critical legal handling rules: SELIC already bundles correction+interest, and post-09/2024 civil cases should use IPCA + legal rate. It does not explicitly name sibling alternatives or exclusions, 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 declare the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by describing the three calculation phases and noting that fractions are configurable. There is no contradiction with 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?

One compact, information-dense sentence with no filler. The legal basis is front-loaded, the phases are presented in order, and the mention of configurable fractions is essential rather than 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?

The description provides strong domain context for a complex legal calculator, but it is operationally incomplete: there is no output schema, no return format, no default fraction values, and no guidance on how to fill the array fields such as causas_aumento and causas_diminuicao.

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 most of the semantic weight. It maps phases to likely parameter groups (judicial circumstances, aggravating/mitigating factors, increase/decrease causes) and mentions configurable fractions, but it does not explain fraction format/units, defaults, or how pena_min_anos and pena_max_anos are used.

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 purpose: calculating criminal sentence dosimetry under the Brazilian three-phase system (art. 68 CP). It is far more specific than a tautology and provides concrete legal context, but it does not explicitly distinguish itself from criminal-law siblings such as calculo_progressao.

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 the tool should be used, but the description does not state explicit conditions, exclusions, or alternatives. An agent must infer that this is for sentencing calculations rather than other criminal-law 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?

Annotations already declare the tool read-only, idempotent, and non-destructive, so the description only needs to add behavioral context. It adds useful specifics: the calculation is per deposit, it accepts manual deposits today with OCR planned for the future, and it includes the 3% p.a. account interest component. This 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 dense sentence that packs legal context, calculation behavior, and interest rule into a compact space. The only minor inefficiency is the parenthetical future roadmap about OCR extraction, which is not needed for invoking the tool today.

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 calculation tool whose safety profile is already carried by annotations, the description explains what is computed, at what granularity, and under which legal rule. There is no output schema, but the description makes the natural result clear: a difference per deposit. It is slightly light on exact input shapes and explicit comparison with sibling tools, but those gaps are not crippling.

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 connects domain concepts to likely parameters: 'depósitos manuais' maps to the required depositos, 'índice de inflação vs TR' maps to indice, and 'juros de 3% a.a.' maps to incluir_juros_3aa. Still, it does not specify the expected structure of depositos or clarify how all four parameters are meant to be populated, so an agent lacks full value-level 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 the exact resource (FGTS) and the operation: per deposit, calculate the difference between correcting by an inflation index and by TR, under the STF thesis. This clearly distinguishes it from the many sibling calculo_* tools, each of which targets a different calculation domain.

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 clear context for when the tool is relevant: FGTS correction under the STF TR-to-inflation thesis, with manual deposits as the current input mode. However, it does not explicitly mention alternatives or say when not to use it, leaving the agent to infer the boundary relative to sibling tools like calculo_revisional or calculo_trabalhista.

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 operation read-only and idempotent, and the description adds genuinely non-obvious behavior: the asymmetric month convention (initial month excluded, final month included) and the conditional outputs when valor or incluir_valores are set. These are exactly the behavioral quirks that would cause wrong results if left undisclosed.

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

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

Three short sentences, front-loaded with the core purpose, then branching into the two conditional behaviors. Every sentence earns its place; the date convention and the operational hint 'puxar os índices crus' are high-value density.

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

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

The description is solid on core semantics but leaves real gaps: pro_rata is unexplained, the meaning of the NENHUM enum option is unclear, and with data_final optional an agent is left guessing the default period. With no output schema, the return shape is also undisclosed.

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

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

With 0% schema description coverage, the description carries the full burden and largely pays it: it explains that valor triggers a corrected-value result, incluir_valores triggers monthly variations, and it pins the meaning of the date pair via the month convention. However, pro_rata (a boolean that plausibly controls pro-rata correction) is never mentioned.

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?

'Consulta de índice oficial' names a specific verb and resource, and the description defines the exact computation: accumulated correction factor between two dates under the BACEN/IBGE convention (initial month excluded, final month included). This scope cleanly separates it from sibling calculo_* tools, which address other domains like rent or 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 description makes the tool's domain (official index correction) clear enough that an agent can infer when to pick it over calculo_aluguel or calculo_fgts, but it never states an explicit when-to-use or when-not-to-use rule and names no alternative tool. Usage context is implied rather than stated.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds beyond that: it reveals the core calculation (assets minus debts according to regime), the concept of compensation for imbalance, and the override behavior for 'entra_partilha'. 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?

Two tightly written sentences front-load the core purpose and legal basis, then give the most important user-actionable instruction. 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 gives the algorithm and the override mechanism, which is a solid baseline. However, with no output schema and no parameter descriptions, an agent is left without the return shape, field-level input semantics, or examples of how regime defaults differ. For a legal calculation involving nested assets and debts, this is helpful 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 carries the burden of explaining parameters. It mentions 'bens' and 'dívidas' conceptually and explains 'entra_partilha', but it leaves 'regime' somewhat implicit, does not explain 'nomes', and does not clarify nested fields like 'titular', 'oneroso', 'heranca_doacao', or 'adquirido_na_constancia'. The guidance is too thin for a schema with four top-level parameters and nested objects.

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 legal operation: 'Partilha de bens no divórcio por regime (Código Civil)', then explains it computes the shareable estate, each spouse's share, and equalization payment. This clearly distinguishes it from sibling calculation tools (e.g., pensão, FGTS, trabalhista) by naming both the resource and the specific legal calculation.

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

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

The description gives clear context: use for divorce asset division under a marriage regime, and it instructs the user to mark 'entra_partilha' per asset to override the regime default. It does not explicitly name sibling tools to avoid or give when-not-to-use conditions, so it stops one step short of full explicit 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?

Beyond the read-only/idempotent annotations, the description discloses the calculation pipeline: monthly due amount, subtraction of payments, INPC correction, and 1% monthly interest from each maturity. It does not detail every edge case such as payment ordering or rounding, but it gives substantial behavioral context.

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

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

A single dense sentence packs the subject, legal basis, timeframe, calculation modes, payment deduction, correction index, and interest rule. There is no filler and the core information is front-loaded.

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

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

For a complex nine-parameter calculator with no output schema, the description provides most of the needed context: what is calculated, how, over what period, and with what corrections. It stops short of describing the return shape and the exact meaning of 'referencia' and 'data_calculo', which prevents a perfect score.

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 text compensates by explaining the forma modes ('% do salário mínimo', 'valor fixo', '% da remuneração'), the role of payments, the correction index, and the interest rate. The required 'referencia' parameter is not named explicitly and 'data_calculo' is absent, but most inputs are inferable from the described formula.

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 domain ('Pensão alimentícia em atraso'), a specific legal basis (art. 528 CPC), and a concrete action ('calcula o devido'), with an explicit formula. This distinguishes it from sibling calculo_* tools such as calculo_aluguel or calculo_fgts 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?

It clearly states the intended scenario: overdue alimony payments, calculated month by month. It does not explicitly name alternative tools or say when not to use it, but the legal and factual context 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?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful transparency by disclosing the calculation logic: percentage by reincidence/hediondo/violence, remission discounts for work/study, detention discount, and the progression date as the return value. 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?

A single dense sentence communicates the legal source, calculation factors, discounts, and return value with no filler. The structure is reasonably front-loaded with the tool's core purpose, though the compressed formula notation could be slightly clearer.

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 output schema and no parameter descriptions, the description covers the main input dimensions and the return value. It does not state exact percentages or edge-case behavior, but an agent can reasonably infer what inputs are needed and what the tool will compute.

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 most parameters conceptually: reincidente, hediondo, violencia, resultado_morte, horas_estudo/dias_trabalhados as remição, dias_detracao as detração, and pena_anos/inicio_cumprimento as the basis for the percentage and date. It does not explicitly name each parameter, but the legal factors give strong semantic grounding.

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 calculation ('Progressão de regime'), includes the legal basis, and clearly identifies the output ('retorna a data de progressão'). The legal context and factor breakdown distinguish it from sibling calculators like calculo_dosimetria 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?

The description implies when the tool should be used through its legal formula and context, but it never explicitly states when to use it over alternatives or mentions any exclusions. The use case is clear, but routing guidance is left entirely 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 declare read-only, non-destructive and idempotent. The description adds meaningful behavior beyond that: it sums and applies monetary correction to the discounted installments, and ties the calculation to the STF agreement framework. It doesn't cover edge cases or output details, but the safety profile is already carried by 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 dense sentences, no filler. The scoped purpose and legal context are front-loaded, and both sentences add selection-relevant 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?

Despite strong annotations, the tool has no output schema and near-zero parameter descriptions, so the description must cover invocation details. It provides the domain context but not the parameter semantics, correction-index behavior, or return value, making it incomplete for reliable agent 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?

With 0% schema-description coverage, the description must define the parameters, but it only indirectly refers to the discount list ('parcelas descontadas') and the idea of correction ('corrigidas'). It never explains the 'indice' choices, 'data_calculo', or how 'codigo/competencia/valor' are used, leaving an agent under-informed for invocation.

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 action ('Restituição de descontos indevidos no INSS') with a concrete computation ('soma as parcelas descontadas corrigidas') and scopes it to exact discount codes (280/304/310/378). This clearly differentiates it from sibling calculo_* tools, e.g. calculo_indice or calculo_fgts, even without inspecting 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 description provides clear when-to-use context: INSS undue discounts from associative fraud codes and the ADPF 1.236/STF administrative reimbursement pathway. It does not explicitly name alternative tools or state when not to use it, so it misses the top level of guidance, but the use case 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?

Beyond the annotations (readOnly, idempotent), the description discloses that the tool performs a live BACEN rate lookup by modalidade+mês and that the average rate is only a reference, not a cap per STJ. These are useful behavioral nuances that could affect expected results.

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, front-loaded sentences with no fluff. The main purpose and method come first, and the legal caveat is added as a concise final 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?

For a tool with 8 parameters and no output schema, the description covers the core calculation and a key legal nuance but does not describe return values, output format, error conditions, or the role of optional parameters. It is adequate for selection but not fully complete for invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It gives contextual meaning to modalidade, month, Price/SAC, and the surplus-per-installment idea, but it does not explicitly explain each parameter such as taxa_bacen_am or data_contrato. It partially compensates but leaves 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 a specific verb ('recalcula'), a specific resource (financiamento bancário), and a concrete calculation method (taxa média BACEN, excedente por parcela Price/SAC). This clearly differentiates it from sibling calculo_* tools by domain and algorithm.

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' establishes a clear context for when the tool applies, and the BACEN/Prize/SAC details help an agent select it among many siblings. It does not list explicit exclusions or alternative tools, but the intended use is readily apparent.

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 it read-only, idempotent, and non-destructive, so no safety disclosure is missing. The description adds useful behavioral context: the 5% limit, corrected restitution, and the thesis that the revolving card sold as consigned never amortizes, which clarifies the calculation's assumptions.

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 sentences front-load the domain and key calculation factors. The legal thesis sentence adds context without bloat, so the description is efficient.

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

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

For a calculation with five parameters, no output schema, and zero parameter descriptions, the description is too sparse to fully guide invocation. It omits what the tool returns, how the descontos array is interpreted, and the meaning of the indice/tipo enums; annotations compensate only for safety, not for these 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 carries the burden, and it only loosely maps to parameters: '5%' relates to beneficio_mensal, 'descontos' appears in the schema, and 'corrigida' hints at indice. It does not explain tipo, indice choices, data_calculo, or the descontos item structure, leaving several parameters under-specified.

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 RMC/RCC and the INSS consignment margin domain with specific codes (217/268), making the calculation's subject unmistakable. It doesn't use an explicit verb like 'calculates', but 'limites de 5% e restituição corrigida' conveys the computation. It is clearly distinct from the sibling calculo_* tools.

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

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

The description implies the tool is for RMC/RCC margin/restitution calculations and mentions the legal thesis, but it never states when to prefer this tool over a sibling or when not to use it. No alternatives or exclusions are given, so routing must be inferred from the domain context.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description fully discloses the calculation behavior: base average, gender-specific coefficient thresholds, and floor/cap clamping. An agent can predict exactly what computation will happen, and the annotations already rule out side effects.

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

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

The entire behavior fits in one dense, front-loaded sentence with no filler. Every clause adds a structural part of the calculation, from inputs to coefficient to floor/cap constraints.

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 5-parameter calculator with no parameter descriptions and no output schema, the description covers the core calculation, input roles, and floor/cap behavior. It could add explicit parameter units or edge-case notes, but it is largely sufficient for an agent to invoke the tool correctly.

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

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

Although schema description coverage is 0%, the description compensates by mapping all five parameters: media_salarios, tempo_contribuicao_anos and sexo via the coefficient rule, and salario_minimo/teto_inss as piso/teto. It does not explicitly state units or formats, but the formula and schema types make these mostly inferable.

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 the exact output — Renda Mensal Inicial under EC 103/2019 — and gives the precise formula: average salary × coefficient, with minimum wage floor and INSS cap. The '20H/15M' gender-specific threshold and piso/teto terms make it clearly distinct from sibling calculo_* tools.

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

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

The description provides clear context: it is for post-reform RMI calculation using contribution average, coefficient, minimum wage floor, and INSS cap. It does not explicitly name sibling alternatives or say when not to use it, but the formula leaves little ambiguity about the intended use.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the data is dynamic and comes from IPEADATA, which is useful context beyond the annotations, but it does not disclose behavior such as return format, error handling, or data availability windows.

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

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

Two short sentences, front-loaded with the core definition and followed by application context. Every sentence earns its place; 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?

For a single-parameter read-only tool, the description covers what it returns and why it matters, but it omits the return format and what happens when 'ano' is omitted (schema marks it optional). No output schema exists, so these details would need to be in the description to be 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?

With schema description coverage at 0%, the description must compensate. 'um ano' implies the 'ano' parameter refers to the target year, but it does not specify valid year ranges, whether the parameter is required (schema says optional), or formatting expectations. The meaning is inferable but not fully specified.

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 as the national minimum wage in effect for a given year, sourced dynamically from IPEADATA. This is more specific than the tool name alone and clarifies the domain (legal sentencing, alimony, and existential minimum calculations), though it does not explicitly contrast with sibling 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 concrete use contexts: 'Base para dosimetria (dia-multa), pensao por % do SM e minimo existencial', indicating when to invoke it. It does not name alternatives or exclusions, so it stops short of a 5.

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

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

The annotations already indicate a read-only, non-destructive, idempotent calculator. The description adds useful calculation constraints, such as the R$600 default minimum existential being parametrizable and a 5-year plan horizon, but it does not disclose output format, default values for all parameters, or potential edge cases. No contradiction with annotations.

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

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

The description is a single dense sentence with no filler; it front-loads the legal context and then lists the key outputs. Every element contributes to understanding the tool's purpose.

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

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

For a calculator with four parameters and no output schema, the description provides the legal formula and result concepts but omits input semantics, units, optionality, and how the parametrizable minimum existential is configured. It is adequate for high-level selection but has clear 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, but it does not explain the actual input parameters like renda_liquida, dividas, or prazo_meses. It only hints conceptually at income and minimum existential, leaving the agent to map results to inputs without explicit 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 clearly identifies the domain (superendividamento under Lei 14.181/2021) and lists the metrics the tool computes: % of income committed, minimum existential, disposable income, and payment capacity for a 5-year plan. It distinguishes the tool from sibling calculators by topic, though it lacks an explicit verb such as '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 domain terminology imply use for over-indebtedness calculations, but the description does not explicitly state when to choose this tool over the many sibling calculators, nor does it mention exclusions or alternatives. Usage guidance is implicit, not explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail beyond those annotations: it counts simultaneous vínculos only once, applies special conversion only up to the EC 103/2019 cutoff, and returns both total time and threshold attainment. 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 dense sentences with no filler. It front-loads the tool's subject, states the key calculation rules, and ends with the return-value summary. Every clause adds useful 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 read-only, idempotent calculation tool, the description provides the critical legal rules and the return values, which is enough for an agent to select and invoke it correctly. It could be slightly more explicit about the exact output format or units, but that is a minor gap given the annotations and schema.

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

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

Schema description coverage is 0%, so the description carries most of the parameter-semantics burden. It explains that vínculos are summed with concomitância handled once and that special activity is converted, while 35H/30M gives sexo practical meaning by associating it with the old-time threshold. It does not spell out date formats or individual enum values, but the schema already exposes the structural 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 names the specific resource (tempo de contribuição/CNIS) and states precise behaviors: summing vínculos, counting concurrent periods once, converting special activity to common using EC 103/2019 factors up to 13/11/2019, and returning total time plus whether the old 35H/30M threshold is reached. This clearly distinguishes it from the other calculo_* sibling 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 context is clear: this tool is for CNIS contribution-time calculations, special-activity conversion, and evaluating the old-time threshold. It does not explicitly name alternatives or state when not to use it, but the subject matter is distinctive enough among the siblings that the intended usage is evident.

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, non-destructive behavior, so the description only needs to add methodological nuance. It does so by disclosing 2026 INSS/IRRF tables, the incidence of discounts, and that indemnity-related verbas are exempt. The description is consistent with the annotations and adds useful behavioral context beyond them.

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

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

The description is dense but efficient: two sentences that front-load the domain, then enumerate components and tax treatment with no filler. Every clause contributes, including the legal reference, the 2026 tables, and the indemnity exemption note.

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 tool with nine parameters, no output schema, and zero parameter descriptions, this description provides a solid high-level overview but not enough operational completeness. It omits input semantics, calculation assumptions, enum behavior, and return-value shape, leaving significant gaps for an agent trying to invoke it correctly.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining nine parameters, but it only partially does so. It names concepts like 'férias vencidas' and 'aviso prévio indenizado', which map to some fields, but it lacks explicit guidance for `salario`, `admissao`, `demissao`, `motivo`, `saldo_fgts`, `dependentes`, and `projetar_aviso`. An agent would struggle to correctly map all inputs without additional knowledge.

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: 'Verbas rescisórias / liquidação trabalhista (CLT)' and enumerates exactly what the tool computes: saldo de salário, aviso prévio, 13º proporcional, férias, FGTS penalties, and INSS/IRRF discounts. The intent is unambiguous, but it does not explicitly differentiate itself from the overlapping sibling calculo_fgts, so it misses a perfect score.

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

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

The CLT termination context makes it fairly clear when to use this tool, and the enumerations help disambiguate it from non-labor sibling calculators. However, there is no explicit when-not-to-use guidance or alternative routing, such as directing FGTS-only cases to calculo_fgts. Usage is implied rather than stated.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint. The description adds concrete behavioral detail: it returns authenticated:true with empty pending[] when all providers are connected, and connect_url plus per-install URLs when credentials are missing. This goes 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?

Two sentences with no filler. The core action is front-loaded, and the conditional return behavior is stated compactly in the second 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?

For a zero-parameter status tool, the description explains the key return scenarios: all connected vs. missing credentials. Minor ambiguity exists around partial connection states, but the core behavior needed to invoke the tool correctly 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 tool accepts zero parameters, so there are no parameter semantics to document. Schema coverage is already complete with an empty properties object, and no additional input guidance is needed.

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

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

Description opens with a specific verb ('Returns') and resource ('connection status and URLs'), immediately identifying the tool's purpose. It also distinguishes itself from sibling 'authenticate', which is an action rather than a status/URL inspection.

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

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

The description implies this tool is used to inspect connection state, with conditional behavior for connected vs. missing credentials. However, it does not explicitly state when to prefer this tool over siblings like authenticate or toolkit_info, nor does it name exclusions.

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

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

The description discloses far more than the sparse annotations provide: invoke runs tools one-off without installing, returns connect/checkout links and a retry flow, writes require workspace owner/admin, search/describe flag install state, and prompt links open without login. There is no contradiction with annotations — readOnlyHint=false is consistent with the install/subscribe/cancel writes described.

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 (~320 words), but for a 14-action dispatcher the length is largely justified. It is well-structured: definition, core flow, conditional invoke behavior, install vs invoke boundary, auxiliary actions, then the prompt library. Minor noise such as the untranslated 'pontualmente' and ALL-CAPS emphasis could be trimmed, but nearly every sentence carries actionable guidance.

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?

Action-level coverage is strong: nearly every enum action is given context, and authorization, billing, and on-demand execution semantics are explained. However, there is no output schema and no per-action parameter documentation, so return formats and argument shapes for many of the 14 actions remain under-specified. An agent could still make exploratory calls to discover details, but the description alone is not complete enough for safe first-try invocation of every action.

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

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

Schema description coverage is 0% across 23 parameters, so the description carries the full burden of explaining parameters. It explains the action enum values and a few implicit fields (tool_id, prompt_slug, prompt_vars), but most parameters — prompt_*, cancel_*, request_*, conversation, arguments, immediate, tier_slug, message — remain undocumented, leaving an agent to guess their intended shape and 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 clearly states the tool's resource ('official mcp.ai marketplace') and its dual function as catalog and execution layer, then breaks down the core flow (search → describe → invoke) and auxiliary actions. It explicitly distinguishes itself from sibling utilities like list_tools, install, report_bug, and the prompt library actions, so an agent can tell what this tool is for.

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 when-to-use versus when-not-to-use guidance: 'prefer invoke for a single/occasional use', 'Use install only to make an MCP PERMANENT', 'list_tools lists what is callable right now', and subscribe/cancel for billing, request_mcp for new MCPs. The prompt library is also cleanly separated from MCP operations, removing ambiguity about which action family to pick.

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 carry the safety profile with idempotentHint=true and destructiveHint=false. The description adds that conversation data is needed for reproduction, which is useful context. However, it does not disclose what happens after submission, such as whether a ticket is created or whether the report is asynchronous, though the annotations lower 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 consists of two tight sentences: the first states the purpose, the second gives the key usage instruction. There is no filler, repetition, or irrelevant detail.

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

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

For a simple three-parameter reporting tool with annotations already covering idempotency and destructiveness, the description is mostly sufficient. The main gaps are the unexplained `context` parameter and the absence of any indication of what the response or outcome will be, though no output schema is expected.

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 undocumented parameters. It only clarifies the `conversation` parameter via 'conversation array with recent messages,' leaving the required `message` and optional `context` undefined. The agent must guess at their intended content.

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 'Report' and explicitly enumerates three targets: 'bug, missing feature, or send feedback'. This makes the tool's purpose unmistakable and easily distinguishable from the sibling calculo_* and authentication tools, which serve entirely 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 establishes a clear context: use when a user reports a problem or wants to provide feedback. It also adds practical guidance to 'Include the conversation array with recent messages for reproduction.' It does not name alternatives, but none of the sibling tools overlap with bug reporting, so exclusions are unnecessary.

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 safety profile is covered. The description adds minimal behavioral context beyond those annotations, only clarifying that the versions are 'current' and scoped to the MCP platform and adapter.

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 wasted words. It immediately communicates the tool's purpose and scope.

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

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

For a parameterless, read-only version-inspection tool, the description is sufficient. The annotations cover safety and idempotency, and no output schema exists, so the description does not need to explain return values or 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?

The tool has zero parameters, so there is nothing for the description to clarify beyond the fact that no input is needed. The schema coverage is effectively complete, and the baseline of 4 for a parameterless tool is appropriate.

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

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

The description states a specific verb and resource: it shows the current MCP platform and adapter versions. It is clear about what the tool does, but it does not explicitly distinguish itself from sibling tools like toolkit_info, which could also provide informational output.

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

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

There is no guidance about when to use this tool versus alternatives such as toolkit_info or authenticate. The intended use is implied by the name and description, but no explicit context, exclusions, or alternative routing is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by listing exactly what information the tool returns, which is especially valuable given there is no output schema.

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

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

A single sentence that immediately states the action ('Returns the current toolkit state') and then lists the returned details in a compact, readable enumeration. There is no filler or repetition, and every phrase 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?

Given zero parameters, existing annotations covering safety, and no output schema, the description fully specifies the tool's return content. An agent has everything needed to decide whether to call it and to interpret the response at a high level.

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 parameter documentation is unnecessary. The baseline for zero-parameter tools is 4, and the description adds no redundant parameter information while still giving a clear account of the tool's operation.

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

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

The description uses the specific verb 'Returns' and names a concrete resource (toolkit state), then enumerates the exact contents: installed MCPs, connection status, connected accounts, and catalog tool counts. This clearly distinguishes it from sibling tools like authenticate and the calculation tools.

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

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

The description implies usage: an agent would call this when it needs to inspect current toolkit state, connections, or available tool counts. However, it does not explicitly state when to use it versus alternatives or provide exclusions, though the sibling tools are mostly unrelated.

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