Calculadora Jurídica

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

The description discloses key behaviors: calling with no args returns a link, passing a JWT token performs a session-only login, and the config-header option yields a non-expiring connection. It also mentions the browser flow and that the token is a JWT. Annotations already indicate idempotency and non-destructiveness, so the added behavioral context about login modes is valuable.

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

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

The description is three sentences and front-loads the core flow ('log in in the browser, copy the access token'). It then gives the recommended permanent setup and the alternative session-only path. No filler, though the phrasing could be slightly tighter.

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

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

For a simple one-parameter tool with no output schema, the description covers the user interaction flow, both authentication paths, and the no-argument behavior. It would benefit from stating what happens after successful authentication (e.g., session established) or what errors might occur, but the essential instructions are present.

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

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

The schema only defines 'token' as an optional string with no description. The tool description fully compensates by specifying that the token should be a JWT access token obtained from the browser after login, and by explaining that omitting the token is valid and causes the tool to return the login link. This is exactly the semantic detail an agent needs.

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 MCP.AI for IDE agents via browser login and access token. It uses a specific action (log in, copy token) and resource (server connection), making it unmistakably an authentication tool. It is distinct from the sibling calculation/marketplace 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 provides clear usage context: it says the best approach is adding the token to the server config as a header for a permanent connection, and the alternative is a session-only login by passing the token. It explains when to call with no args (to get the link) versus with a token. It does not explicitly compare this tool to the sibling 'connect' tool or state when not to use it.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description only needs to add context beyond safety. It does this by disclosing the calculation components: index adjustment, 1% monthly interest, late penalty, and per-month breakdown plus total. This meaningfully clarifies what the tool computes.

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-loaded with the core scenario, and every sentence contributes value. It avoids redundancy and does not restate parameter names from the schema.

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

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

Given the 9-parameter schema with no parameter descriptions and no output schema, the description offers a solid high-level overview but leaves gaps around optional parameters, date formats, and specific index/penalty computation details. It is adequate for a first understanding, but not fully complete for precise 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 provides general semantics for key inputs like the rent amount, index, contract period, and overdue month range, but it does not explicitly map these to parameter names or explain optional fields like juros, multa, data_calculo, or periodicidade_meses. The information is helpful but incomplete.

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 overdue rent adjustments under Lei 8.245/91 with index-based readjustment, late interest, and penalty. It also specifies the return shape ('detalhamento por mês + total'), and the focus on 'Aluguéis em atraso' distinguishes it 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 provides clear usage context by naming the relevant law and the specific scenario (overdue rent calculations). However, it does not explicitly mention when not to use it or point to alternatives among the sibling tools, so it lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the tool as safe and non-mutating. The description adds valuable behavioral context: it explains that SELIC already bundles correction and interest (so users should not double-count) and highlights the legal regime change after 09/2024. 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 efficient: two sentences conveying purpose, scope, output, and crucial legal caveats. It front-loads the primary function and then adds necessary warnings. No redundant phrasing or fluff.

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

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

Given the tool's complexity (11 parameters, no output schema), the description covers the core purpose, return value (detailed per installment and totals), and critical legal constraints. It does not detail each parameter's semantics but provides enough context for an agent to understand the tool's role and major rules. The presence of a clear output and legal emphasis makes it fairly complete.

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

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

Schema coverage is 0%, so the description must compensate. It mentions indices (IPCA, INPC, etc.), interest, fines, and fees, which map to parameters like 'indice', 'taxa_juros', 'multa', and 'honorarios'. It also clarifies that using SELIC means not adding separate interest, which is semantic guidance for the 'taxa_juros' parameter. However, it does not explain all 11 parameters (e.g., pro_rata, multa_incide_sobre_juros), leaving 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 clearly states the tool's function: monetary update and liquidation of judicial debts, correcting installments by an official index and applying interest, fines, and fees. It explicitly names the resource (judicial debt) and distinguishes it from sibling tools like 'calculo_aluguel' and 'calculo_fgts' by focusing on court settlement 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?

It provides clear context on when to use the tool (judicial debt settlement) and includes legal regime warnings (e.g., SELIC already includes correction+interest; post-Sep/2024 civil uses IPCA + legal rate). However, it does not explicitly contrast with alternatives or state when not to use it, though the purpose is specific enough to imply usage.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat safety. It adds behavioral context by describing the calculation methodology (three-phase system), which is beyond annotations and helps understand what the tool does.

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

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

The description is a single sentence that efficiently conveys the core purpose and legal framework. It is dense but not overly long, front-loading the primary function and key details without unnecessary fluff.

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, no output schema, and 0% schema coverage, the description should provide more details on inputs and outputs. It lacks specifics on required fields (min/max penalties), array structures, and what the tool returns. The legal jargon may confuse non-experts, leaving the description incomplete for effective use.

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

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

Schema coverage is 0%, so the description must compensate. It explains concepts like mitigating/aggravating circumstances and causes of increase/decrease, and mentions configurable fractions, but does not explicitly map all parameters (e.g., pena_min_anos, pena_max_anos) or define the required fields. This partial explanation is insufficient for a complete understanding.

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

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

The description clearly states it calculates criminal sentencing following the three-phase system (art. 68 CP), specifying each phase with legal references. It distinguishes itself from other calculo_* tools by focusing on criminal law, leaving no doubt about its purpose.

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

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

The description implies usage for criminal sentencing calculations but does not explicitly say when to use it vs. alternatives or provide exclusions. It provides clear context that it is for penalty dosimetry, which is sufficient for an expert, though not explicit about alternatives.

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, and the description does not contradict them. It adds useful behavioral context by explaining the calculation details (inflation vs TR, 3% annual interest) and the input method (manual deposits, future OCR), which 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?

The description is two concise sentences, front-loaded with the core purpose and followed by relevant input context. Every clause earns its place, with no redundant wording 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 calculation tool with good annotations and 4 parameters, the description provides enough context to understand the domain, formula, and input mode. It does not describe the output format, but the lack of an output schema and the straightforward calculation scope make this acceptable.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It adds meaning for depositos (per-deposit manual input), indice (inflation index vs TR), and incluir_juros_3aa (3% annual interest). However, it does not explicitly explain data_calculo or precisely map all parameters, leaving a partial 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 purpose: it calculates the FGTS correction difference between inflation indices and the TR, per deposit, under the STF thesis. This specific verb+resource+scope distinguishes it from sibling tools like calculo_indice and calculo_trabalhista.

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

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

The description implies the use case (FGTS correction with manual deposits) but does not explicitly state when to choose this tool over alternatives, nor does it provide exclusions or direct comparisons to sibling tools. The mention of manual deposits and future OCR input gives some usage context, but no clear when/when-not guidance.

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

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

The description discloses behavioral details beyond the annotations, including the date convention (initial month excluded, final month included) and the conditional outputs based on 'valor' and 'incluir_valores'. It also mentions pulling raw indices, providing transparency about internal logic without contradicting the read-only, idempotent 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 concise, a single sentence with a clear structure: main purpose, date convention, and conditional returns. It contains no unnecessary fluff and is efficiently packed with 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?

The description provides a solid understanding of the tool's core functionality and conditional outputs, but lacks explanation for 'pro_rata' and does not mention potential edge cases or error behavior. Given the simplicity of the tool, it is fairly complete, but not exhaustive.

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 description explains the roles of 'valor' (triggers corrected value), 'incluir_valores' (triggers monthly variations), and the date parameters (via 'between two dates'). It does not mention 'pro_rata', leaving one parameter semantically unexplained. Given low schema coverage, the description compensates reasonably but not fully.

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 queries an official index and computes the accumulated correction factor between two dates, with optional corrected value or monthly variations. It uses a specific verb ('consulta') and resource ('índice oficial'), distinguishing it from sibling 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 provides clear context for when to use the tool (for index-based corrections) and explains conditional behavior based on parameters, but does not explicitly mention alternatives or exclusions relative to sibling tools. It implies usage through its purpose, which is moderately clear.

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

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

As anotações (readOnlyHint, idempotentHint, destructiveHint) já cobrem segurança. A descrição acrescenta a lógica de cálculo (bens − dívidas conforme regime) e a possibilidade de override via entra_partilha, o que é informação comportamental útil. 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 e diretas, com o propósito no início e uma dica de uso no fim. Não há palavras desnecessárias; é um exemplo de concisão efetiva.

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?

Dada a complexidade (objetos aninhados, 4 parâmetros, sem output schema), a descrição cobre a lógica central e o override, mas não menciona o formato de retorno nem detalhes sobre a divisão de dívidas/torna. Ainda assim, é suficiente para o uso básico do tool, embora deixe espaço para mais detalhes.

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?

Como o schema tem cobertura 0%, a descrição precisa compensar. Ela explica o uso de entra_partilha e a relação entre bens e dívidas, mas não detalha parâmetros como nomes, dividas ou os valores do enum de regime. Fornece semântica parcial, suficiente para entender o propósito principal, mas não todos os campos.

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

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

A descrição define claramente a operação: apura a massa partilhável (bens − dívidas conforme regime) e a quota de cada cônjuge, com torna por desequilíbrio. O verbo 'apura' é específico e o recurso 'partilha de bens no divórcio' distingue-se dos irmãos (pensão, trabalhista, etc.) por ter escopo legal claro.

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

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

A descrição indica contexto claro (divórcio por regime do Código Civil) e a informação 'Marque entra_partilha por bem para sobrepor o default' sugere como ajustar a entrada. No entanto, não menciona quando não usar ou alternativas explícitas; ainda assim, a finalidade é evidente.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description does not add extra behavioral context beyond the calculation steps, such as potential side effects or limitations. It is adequate but not enhanced beyond the annotations.

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

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

The description is a single, well-structured sentence that packs essential information without unnecessary verbiage. It is concise and to the point, covering the key calculation aspects efficiently.

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

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

Given the complexity of the calculation and the number of parameters, the description is incomplete. It does not clarify the output format, the exact role of all parameters, or any edge cases. The absence of an output schema and incomplete parameter explanations leave significant gaps for correct usage.

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

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

The description explains the meaning of some parameters (e.g., 'forma' for percentage type, 'pagamentos' for payments, 'indice' for correction index, 'juros' for interest) but leaves others unexplained (e.g., 'referencia', 'inicio_atraso', 'fim_atraso', 'data_calculo', 'remuneracoes'). With no schema descriptions, this partial coverage is insufficient for full parameter understanding.

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

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

The description clearly states the tool calculates alimony in arrears and outlines the calculation method (percentage of minimum wage, fixed amount, or percentage of remuneration, subtracts payments, applies correction and interest). It also references the legal article (art. 528 CPC), making its purpose unambiguous and distinct from 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 implies use for alimony calculations but does not explicitly state when to use this tool versus alternatives (e.g., other calculation tools). It lacks direct guidance on scenarios where this tool is appropriate or inappropriate, leaving the agent to infer from the name and 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?

As anotações já declaram readOnlyHint=true e idempotentHint=true; a descrição agrega contexto sobre a base legal (LEP art. 112) e os fatores de cálculo (remição, detração, percentuais). Isso ajuda a entender o comportamento sem contradizer as anotações.

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

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

É uma frase única e densa, sem excessos, mas carrega muitos termos técnicos em sequência. A informação é condensada de forma eficiente, embora possa ser difícil de processar de uma só vez.

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

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

A descrição cobre a finalidade, os principais fatores legais e o tipo de retorno (data de progressão). Porém, com 9 parâmetros, 0% de cobertura no schema e sem output schema, faltam detalhes sobre entradas e formatos para garantir invocação correta.

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?

O schema tem 0% de cobertura descritiva, então a descrição deveria explicar cada campo. Ela menciona indiretamente vários parâmetros (reincidente, hediondo, violencia, resultado_morte, estudo, trabalho, detração), mas não detalha significados individuais nem formatos (ex.: pena_anos, inicio_cumprimento). A compensação é parcial.

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

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

A descrição usa verbo específico ('retorna a data de progressão') e delimita claramente o recurso (cálculo de progressão de regime) com base legal explícita. Diferencia-se dos irmãos ao especificar o cenário jurídico, não deixando dúvida sobre a função.

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

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

A descrição deixa implícito que a ferramenta é para cálculos de progressão de regime, mas não há orientação explícita sobre quando usar versus alternativas, nem exceções. O contexto legal é claro, mas não há exclusions ou comparação com outros cálculos.

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, so the bar is lower. The description adds legal context and the calculation purpose but doesn't explain any behavioral specifics like whether it returns a single value or handles errors. It doesn't contradict annotations.

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

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

Two sentences, front-loaded with purpose goes directly to the calculation and legal basis. No fluff, though the parentheticals add detail but are not overly long.

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

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

The description explains the tool's purpose and broad behavior (sum of corrected installments), but lacks details on parameter semantics (e.g., index, date) and expected output format. No output schema provided, so it's incomplete but not severely.

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

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

Schema description coverage is 0%, and the description does not explain any parameter. It mentions summing corrected installments but does not clarify the roles of 'indice', 'data_calculo', or 'competencia'. With zero schema coverage, the description should compensate but fails to add parameter meaning.

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

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

The description clearly states the tool calculates restitution for undue INSS discounts, lists specific fraud codes (280/304/310/378), and mentions the legal basis (STF agreement). This is specific and distinguishable from sibling calculation tools like calculo_revisional or calculo_fgts.

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

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

The description indicates this is for administrative reimbursement via STF agreement, and it specifies the exact type of deductions (fraud associativa, codes 280/304/310/378). This provides strong usage context, though it doesn't explicitly state when not to use it or compare with alternatives.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is known to be safe and non-mutating. The description adds valuable behavioral context: it performs a live lookup to BACEN, uses the market rate as a reference (not a ceiling, per STJ), and supports two amortization systems (Price or SAC). This exceeds what annotations alone convey.

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

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

The description is a single sentence with three clauses, but it is front-loaded with the main purpose and includes important details about the rate source and legal reference. It is concise without excess words, though it packs multiple concepts into one sentence, slightly reducing readability.

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

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

Given the tool's complexity (8 parameters, 2 enums, no output schema), the description covers the core behavior and key parameter semantics. It does not describe return values, but since no output schema exists, the description could elaborate more on what output the tool produces (e.g., does it return total excess, per-installment breakdown?). However, for a calculator tool with clear annotations, it is sufficiently complete for an agent to invoke it correctly.

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

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

The input schema has 8 parameters with 0% description coverage, so the description must compensate. It clarifies the role of key parameters: 'taxa_contratada_am' (contracted monthly rate) and 'parcela_paga' (paid installment), and explains the optional 'sistema' (Price or SAC). The description also indicates that 'taxa_bacen_am' is the market rate used, though it doesn't detail every parameter (e.g., modalidade, data_contrato), but the enum values provide reasonable semantics for those.

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 performing a 'revisional de contrato bancário' calculation, with specific details on what it computes (recalculating financing via BACEN market rate, and determining excess per installment). It distinguishes from siblings (e.g., calculo_aluguel, calculo_fgts) by mentioning the specific domain (bank contract review) and the BACEN rate lookup.

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

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

The description states the tool recalculates a bank contract using the BACEN market rate, implying when it should be used (for reviewing bank contracts), but does not explicitly state when not to use it or mention alternative tools for similar calculations (e.g., when a different calculation system is needed). No exclusions are provided, so it meets a minimum viable level.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description doesn't need to repeat safety. The description adds behavioral context by explaining the underlying legal thesis (card sold as consignado that never amortizes) and the correction of discounts, which is beyond what annotations provide.

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

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

The description is concise, using a few sentences and a thesis statement. It is front-loaded with the acronym expansion and key facts, but the thesis statement might be slightly extraneous for tool selection. Still, every clause contributes to purpose and context, so it earns a high score.

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 calculation with no output schema and 0% parameter description coverage, the description should explain what inputs are expected and what the output looks like. It provides purpose and background but lacks detail on how to use the tool, such as required fields or return format. Marginal adequacy.

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 for parameter semantics, but it does not mention any parameters. It names the key inputs (beneficio_mensal and descontos) only indirectly via the schema, and provides no additional meaning beyond what the schema offers. This is a significant 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 explicitly states it calculates RMC/RCC (reserva de margem consignável de cartão) for INSS codes 217/268, with limits of 5% and corrected restitution. It clearly distinguishes from sibling tools by naming a specific calculation type and its niche (rotative card sold as consignable that never amortizes).

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

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

The description implies when to use this tool: for RMC/RCC calculations related to INSS benefit margins, specifically for contested credit card deductions. It doesn't explicitly exclude other tools or mention alternatives, but the specificity of the purpose makes its usage context 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?

Annotations already declare readOnlyHint, destructiveHint:false, and idempotentHint:true. The description adds the formulaic context but no additional behavioral disclosure (e.g., no side effects, dependencies, or limitations). It aligns with annotations without adding new behavioral safeguards.

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 delivers the full formula and reform context without redundancy or filler. It is front-loaded with the core domain term 'RMI' and immediately specifies the calculation components.

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 five-parameter calculation tool, the description covers the key algorithm, coefficient, floor/ceiling, and gender-specific years. Since no output schema exists, the description makes the return value implicit (the RMI amount). Minor gaps: no mention of error conditions or whether parameters must be pre-adjusted, but the formula is sufficiently detailed for deputy purposes.

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 interprets the parameters: 'média dos salários de contribuição' maps to media_salarios, 'tempo de contribuição' to tempo_contribuicao_anos, 'sexo' determines the H/M thresholds, and 'piso/teto' correspond to salario_minimo and teto_inss. It clarifies the roles but does not provide types or units.

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 explicitly states the tool computes the Renda Mensal Inicial (RMI) post-reform, including the precise coefficient formula and floor/ceiling rules. It clearly distinguishes from sibling tools like calculo_tempo_contribuicao by focusing on benefit value rather than contribution time.

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

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

The description implies usage for retirement benefit calculations with the EC 103/2019 reform but lacks explicit when-to-use or comparison with alternative tools. The context is clear but no exclusions or situations are specified.

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=true, idempotentHint=true, destructiveHint=false), the description adds meaningful behavior: the value is dynamic, sourced from IPEADATA, and represents the current national minimum wage for a given year. This is useful context not present in 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 short sentences with no redundancy. It front-loads the core purpose and adds compact, relevant use-case context without wasting words.

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

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

For a simple read-only lookup tool with one optional parameter and no output schema, the description is mostly adequate. However, it leaves important gaps: it does not clarify the 'ano' parameter semantics, default behavior if omitted, or the output/return value format.

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

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

The schema has one parameter 'ano' with no description and 0% schema coverage, so the description must compensate by explaining the parameter. It only mentions 'de um ano' indirectly and never explicitly states that 'ano' is the year input, its format, or what happens when it is omitted.

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 providing the current national minimum wage for a year, with the data source (IPEADATA) and dynamic nature stated. It distinguishes itself from sibling calculo_* tools by focusing on salário mínimo rather than other calculation targets like FGTS or pensão.

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

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

The description gives useful context, stating it serves as a basis for dosimetria (dia-multa), pensão por % do SM, and mínimo existencial. However, it does not explicitly say when to use this tool versus the sibling calculators like calculo_dosimetria or calculo_pensao, nor does it state exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by explaining the parametrizable minimum existential (R$600 default) and the plan horizon of up to 5 years, enriching the agent's understanding beyond the annotations.

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

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

The description is a single, dense sentence that front-loads the legal basis and key concepts without any wasted words. Every phrase adds value.

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

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

Although there is no output schema, the description lists the key computed outputs, making it clear what the tool returns. It covers the main inputs and legal context, but does not elaborate on the debt array structure, which is a minor gap given the tool's complexity.

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

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

With 0% schema description coverage, the description partially compensates by explaining minimo_existencial ('parametrizável' with R$600 default), prazo_meses ('até 5 anos'), and renda_liquida implicitly via 'renda disponível'. However, it does not clarify the structure or fields of the 'dividas' parameter, leaving a 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 as computing over-indebtedness metrics under Law 14.181/2021, listing specific outputs (percent of committed income, existential minimum, available income, payment capacity). This distinguishes it from all other calculo_* siblings.

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

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

Usage is implied by the tool name and legal reference, but the description does not explicitly state when to use this tool versus alternatives like other calculo_* tools. No exclusions or alternative references are provided.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral details: concurrent periods are counted once, special activity is converted only up to 13/11/2019, and it checks whether the old requirement threshold was reached. This is beyond what annotations provide.

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

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

The description is compact and information-dense, with two sentences carrying all essential details. It starts with the core purpose and includes only relevant behavior and output, with no redundant text.

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

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

It explains what the tool returns (total contribution time and whether the old threshold is reached) and gives calculation rules, which is helpful without an output schema. However, critical input details are missing: no date format for the string dates, no explicit mapping of sexo values to the thresholds, and no description of the vinculos item 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 coverage is 0%, yet the description does not explain the required parameters 'sexo' or 'vinculos' fields ('inicio', 'fim', 'tipo') or the expected date format. The agent must infer that 'vinculos' represents employment/service periods and that 'sexo' affects the threshold. This is a significant gap.

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

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

The description clearly states the tool sums contribution periods, handles concurrent intervals only once, and converts special activity using EC 103/2019 factors. This specific scope distinguishes it from sibling calculation tools like calculo_rmi 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 CNIS reference and 'tempo de contribuição' label make the intended context clear, and the description implies it is for computing contribution time against old-age thresholds. It does not explicitly name alternatives or state when not to use it, but the domain is unambiguous enough for selection.

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. The description adds valuable context: it specifies that the calculation uses 2026 tax tables (INSS and IRRF), includes deductions, and notes that indemnity payments are exempt. This goes beyond the schema and annotations, providing useful behavioral details. No contradictions.

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 packages all the key information. It is front-loaded with the primary purpose and then enumerates components. While efficient, it could benefit from splitting into two sentences for readability. It is not verbose, and every phrase contributes to understanding the tool's 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?

This is a complex tool with 9 parameters and no output schema, yet the description gives only a high-level overview. It does not explain the return format (e.g., a breakdown of items, totals, or deductions), nor does it clarify the meaning of optional parameters or their interplay (e.g., how 'projetar_aviso' affects calculations). The description is insufficient for an agent to accurately invoke the tool without additional assumptions.

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 has 9 parameters with 0% description coverage in the schema itself, so the description must compensate. The description lists concepts like 'aviso prévio indenizado' and 'férias vencidas' but does not explicitly map these to parameters such as 'aviso', 'ferias_vencidas', or 'projetar_aviso'. It fails to explain the meaning or default behavior of optional parameters, leaving the agent to infer from 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 clearly states the tool's purpose: calculating termination payouts (verbas rescisórias) under Brazilian CLT law. It enumerates specific components (salary balance, prior notice, 13th salary, vacations, FGTS penalty) and explicitly distinguishes this from other calculation tools like calculo_fgts or calculo_aluguel, making it 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 when to use this tool: for HR or legal calculations related to employee termination in Brazil. It does not explicitly state alternatives or when not to use it, but the name and contents make the context clear. It could have mentioned that for standalone FGTS calculations, calculo_fgts would be more appropriate, but it's not required.

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, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds meaningful behavioral context beyond those hints by specifying exactly what happens in the two key scenarios: authenticated:true with empty pending[], and returning connect_url plus per-install URLs when credentials are missing. It does not cover the partial-connection middle ground, but the disclosed behavior is clear and non-contradictory.

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

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

The description is two sentences, front-loaded with the primary purpose, and every clause adds useful information. There is zero redundancy or filler.

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

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

The tool has no parameters, has strong annotations, and the description covers the main outcome branches. It does not detail every possible return field or the partial-connection case, but the information given is enough for an agent to understand the tool's core behavior and decide when to call it.

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

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

With zero parameters, there is no parameter burden for the description to carry, so the baseline of 4 applies. The description appropriately spends its words on output semantics rather than input 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 uses the specific verb 'returns' with a concrete resource: connection status and URLs. It clearly distinguishes itself from 'authenticate' by focusing on state inspection rather than the authentication action, and it details two outcome branches.

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 conditional context (all providers connected vs missing credentials) that implies a health-check use case, but it never explicitly says when NOT to use this tool or mentions the alternative 'authenticate'. This leaves the decision boundary somewhat implicit rather than explicit.

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

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

Annotations only say readOnlyHint=false (non-read-only), but the description adds rich context: one-off invoke runs without installing, invoke returns a connect link when credentials are needed and a checkout/top-up link when the wallet is empty (with retry guidance), writes require workspace owner/admin, publish_prompt links open without login, and search/describe flag installed_in_toolkit vs installed_in_workspace. No contradiction with annotations (false for all hints).

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 paragraph with run-on dash sentences and some redundancy ('AND the way to run them,' the capability-request examples). Most content is earned given 14 actions and 23 params, but the lack of any bullet or section structure makes it hard to scan, which is particularly costly for a tool this broad.

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

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

With no output schema and 0% parameter coverage, the description carries a heavy burden. It covers the core workflow, auth/payment edge cases, permission requirements, the prompt library, and installed-status flags — but leaves gaps: the resume and uninstall actions, the immediate flag, tier_slug, cancel_reason semantics, and return shapes for most actions. Adequate, not complete, for a tool this complex.

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, and it does explain the action routing (search, describe, invoke, install, subscribe/cancel, list_tools, report_bug, request_mcp, search_prompts/get_prompt/publish_prompt) plus name-drops tool_id, mcp_id, and prompt vars. But it never documents limit, query, message, arguments, conversation, cancel_reason, tier_slug, immediate, report_context, or request_details, so many parameters remain opaque.

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 official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them,' naming the resource precisely and enumerating the verbs (search, describe, invoke, install). It also names the prompt-library sub-capability. Sibling tools are clearly unrelated calculations/auth functions, so no differentiation conflict exists.

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?

Explicit internal routing is strong: 'prefer invoke for a single/occasional use' vs 'Use install only to make an MCP PERMANENT,' plus list_tools for what's callable now and request_mcp 'when nothing fits.' However, guidance is about internal action modes rather than when to pick this tool over external/alternative tools, so it stops short of a full 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?

Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is known. The description adds useful reproduction guidance (conversation array) but does not disclose side effects such as where the report is sent or whether a confirmation is returned.

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

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

The description is two short sentences with no filler. The first sentence states the purpose, and the second provides actionable reproduction guidance, earning its place.

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

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

For a low-complexity tool with helpful annotations, the description covers the purpose and key parameter behavior. The main gap is the lack of output/confirmation behavior and the conversation array-versus-string ambiguity, but these are minor for this tool type.

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

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

Schema coverage is 0%, so the description must compensate. It explains the `conversation` parameter's purpose (recent messages for reproduction) but does not clarify `message` or `context`. It also calls `conversation` an 'array' while the schema defines it as a string, causing a mismatch.

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

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

The description uses a specific verb ('Report') and names three valid targets: bug, missing feature, and feedback. This clearly defines the tool's scope and distinguishes it from the calculation-focused 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 makes it clear when to use the tool: for any bug, feature request, or feedback scenario. It does not name alternatives, but the sibling tools are all unrelated calculation tools, so there is no ambiguity.

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 this as read-only, idempotent, and non-destructive, so the lower transparency bar is met. The description adds useful context by specifying that it reports both the MCP platform and adapter versions, which is beyond what the annotations or empty schema convey.

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

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

The description is a single, well-structured sentence that states exactly what the tool does. Every word contributes to meaning, with no redundancy or filler.

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

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

Given the zero-parameter interface, no output schema, and simple read-only nature, the description provides adequate detail about what the tool returns (platform and adapter versions). A version-checking tool does not require more extensive documentation to be usable.

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 are no parameter semantics to clarify. The baseline of 4 applies, and the description correctly avoids inventing parameter-related information.

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 'Show' and clearly identifies the resource as 'the current MCP platform and adapter versions.' It is distinct from siblings like calcular_* tools and even toolkit_info, leaving no ambiguity about what the tool returns.

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

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

There is no explicit guidance about when to use this tool versus alternatives such as toolkit_info. The purpose strongly implies the appropriate use case, but the description does not state exclusions or alternatives, so the guidance remains implicit rather than direct.

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, and non-destructive behavior, lowering the descriptive burden. The description adds valuable context about what the returned state comprises (installed MCPs, connection status, accounts, catalog counts), which goes beyond the annotations and helps the agent understand the output nature.

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

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

The description is a single, well-structured sentence that front-loads the primary action ('Returns') and then lists the key output categories. Every word earns its place, with no redundancy or filler.

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

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

For a parameterless info tool with no output schema, the description is fully complete. It names what the tool returns and the categories that can be expected. There is no ambiguity about its function, and it aligns with the annotation hints.

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 baseline is 4. The description does not need to explain parameters it doesn't have. It focuses on return content, which is appropriate.

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

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

The description clearly states the tool's function: 'Returns the current toolkit state' and enumerates exactly what is included: installed MCPs, connection status, connected accounts, and catalog tool counts. This specific verb+resource combination effectively distinguishes it from sibling tools like calculo_* or authenticate.

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

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

The description implies when to use the tool (to inspect toolkit state) but does not explicitly state when to use it over alternatives or exclude usage cases. There's no mention of 'use when you need...' or 'not for...'. Given it's a unique info tool, the context is clear but not explicitly articulated.

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