Revisão de Contrato Bancário

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

It discloses the authentication flow, the difference between permanent and session-only connections, and the fact that calling with no arguments returns a link. The annotations (idempotentHint, non-destructive) do not contradict the description and the text adds meaningful behavioral detail beyond those 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 dense but every clause adds useful information, and it is front-loaded with the tool's purpose. It avoids filler while covering the permanent setup, session-only flow, and no-args behavior in a compact form.

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 that there is no output schema, the description adequately explains how to obtain and supply the token. However, it does not specify what the tool returns after a successful token-based login or how errors like invalid tokens are surfaced, which would make it fully complete.

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

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

Schema coverage is 0%, so the description carries full responsibility for explaining the optional token parameter. It does this well, defining the token as a JWT access token and clarifying that omitting it requests the login link.

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 and resource: logging in to MCP.AI for IDE agents via browser access token. It clearly distinguishes itself from the sibling calculation/tooling tools and explains the two usage modes (token paste vs. no-args link request).

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

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

The description gives explicit instructions for when to use each mode: add the token to server config for permanent non-expiring access, paste it via the tool for session-only login, or call with no args to get the login link. This is actionable and removes ambiguity about 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral detail: it reajusta by index, corrects each late month, applies 1% monthly interest and late penalty, and returns a month-by-month breakdown plus total. This is substantive 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 compact: three sentences, front-loaded with the core purpose, then quick detail on the calculation logic and output. Every sentence adds value and there is no 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 legal calculation with 9 parameters and no output schema, the description is not complete. It gives the high-level formula and a minimal output summary, but omits parameter roles, date formats, optional-field behavior, and details of the returned monthly breakdown. An agent would likely need to inspect schemas or examples to call it reliably.

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

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

Schema description coverage is 0%, so the description must compensate for 9 undocumented parameters. It only alludes to 'índice', 'juros', and 'multa', but does not explain the required date fields, aluguel_inicial, data_calculo, or periodicidade_meses. It also states a fixed 1% monthly interest and penalty while the schema exposes juros and multa as parameters, which may confuse agents about whether those are overrides.

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 calculates overdue rent adjustments under Lei 8.245/91, covering index-based adjustment, per-month correction, interest, and penalty. This clearly distinguishes it from broader sibling tools like calculo_revisional or calculo_atualizar by narrowing the scenario to overdue rent.

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: it is for overdue rent ('Aluguéis em atraso') and names the governing law, making the primary use case obvious. It does not explicitly name alternatives or state when not to use it, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. It adds meaningful behavioral context by warning that SELIC already includes both correction and interest, by noting the post-09/2024 civil regime (IPCA + legal rate via Lei 14.905/2024), and by stating the return shape: per-installment breakdown and totals.

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

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

The description is compact and front-loaded: it states the core purpose first, then the output, then the critical legal caveat. Every sentence carries useful information, and there is no filler or redundant restating of the tool name.

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

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

For a tool with 11 parameters, no output schema, and no schema-level descriptions, the description provides a solid high-level picture and critical legal warnings but still leaves gaps around parameter semantics and calculation defaults. It is adequate for basic invocation but not fully complete for edge cases.

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

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

With 0% schema description coverage, the description must compensate, and it does add important legal semantics for indice/taxa_juros, especially the SELIC warning and the IPCA + legal rate rule. However, several parameters such as pro_rata, data_calculo, periodicidade_juros, honorarios_tipo, and multa_incide_sobre_juros are not explained or even referenced in the description.

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 monetary update and judicial debt liquidation: it corrects installments by an official index and applies interest, penalties, and fees. It is specific about the resource ('parcelas') and distinct from sibling calculation tools by focusing on débito judicial/liquidaçã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 use case is implied by the opening phrase 'Atualização monetária / liquidação de débito judicial', and the legal-regime warnings provide useful context for choosing SELIC vs IPCA. However, it never explicitly says when to use this tool over siblings like calculo_indice or calculo_revisional, 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is consistent with those. It adds useful behavioral detail about the calculation process: pena-base, intermediate phase, and definitive phase, plus configurable fractions. No contradiction exists between the description and 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 organized by the three phases, with legal citations and no filler. It front-loads the core purpose and remains highly scannable for an agent.

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 a nine-parameter legal calculation and the absence of an output schema, the description provides strong algorithmic and legal context. It explains the progressive calculation structure and notes configurable fractions. Minor gaps remain around expected return format and precise fraction encoding, but the core invocation semantics are largely inferable.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It maps phases to legal concepts like circunstâncias judiciais, atenuantes/agravantes, and causas de aumento/diminuição, which align with parameter names. However, it does not explain fraction format, the exact role of fracao_fase1/fracao_fase2, or how circunstancias_desfavoraveis should be quantified.

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 and operation: 'Dosimetria da pena' under the three-phase system of art. 68 CP. It describes each phase, making the tool distinguishable from sibling calculation tools by its criminal-sentencing focus. It lacks an explicit verb like 'calcula' but the purpose is unambiguous.

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

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

The legal context (art. 68 CP, Súmula 231 STJ) implies this is for criminal sentence dosimetry, which gives some usage guidance. However, it does not explicitly state when to choose this tool over alternatives or mention any exclusion conditions. No sibling comparison or routing information 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, idempotentHint, and non-destructiveness. The description adds useful behavioral context beyond annotations: it compares inflation index vs TR per deposit, applies 3% a.a. interest, and notes that deposits can currently be entered manually with OCR planned in the future. 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 that front-loads the legal thesis and calculation method, then clarifies the input mode and future OCR roadmap. There is no filler or repetition.

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

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

For a legal-calculation tool with no output schema and 0% schema description coverage, the description conveys purpose, methodology, and main inputs well. Still, it leaves gaps around `data_calculo`, the exact structure of each deposit object (competencia/valor), and what the returned calculation object looks like.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does: 'por depósito' and 'depósitos manuais' clarify `depositos`, 'juros de 3% a.a.' clarifies `incluir_juros_3aa`, and the inflation-vs-TR comparison relates to `indice`. However, `data_calculo` is not explained at all, and the indice enum choices are not mapped beyond the headline indices.

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

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

The description uses a specific verb phrase ('calcula a diferença') tied to a concrete resource (FGTS correction under the STF TR→INPC/IPCA-E thesis) and states the per-deposit calculation method. This is distinct enough from sibling generic calculo_* tools to be unambiguous.

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

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

The description gives clear context: it is for FGTS revision comparing inflation-index correction with TR and applying 3% a.a. interest, and it explicitly mentions manual deposits as the accepted input mode. It does not name alternative tools or state exclusions, but the legal and domain context makes the appropriate use fairly 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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral detail beyond that: the BACEN/IBGE month convention, conditional behavior based on 'valor', and the monthly-variation mode when 'incluir_valores' is true. Minor missing behaviors like 'pro_rata' handling prevent a higher score.

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

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

The description is compact and front-loaded with the main purpose, followed by the conditional behavior in a single second sentence. The informal 'puxar os índices crus' is slightly redundant but does not add meaningful bloat. It earns its place overall.

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 6 parameters, 0% schema coverage, and no output schema, the description carries a heavy burden. It covers the main calculation, date convention, and output-mode switches, but leaves 'pro_rata' unexplained and does not describe expected return structures. It is adequate for basic invocation but has clear gaps for full autonomous 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 description coverage is 0%, so the description must compensate. It does explain 'valor', 'incluir_valores', the date pair, and implicitly 'indice', but 'pro_rata' is left entirely undefined, and no date format or enum value semantics are provided. This is partial compensation, not complete.

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

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

The description opens with a specific verb and object: 'Consulta de índice oficial', and precisely defines the computation as the accumulated correction factor between two dates. It clearly differentiates this tool from the many calculo_* siblings by focusing on official index correction rather than aluguel, fgts, trabalhista, etc.

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

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

The description provides clear context for when to use the tool: whenever a correction factor or corrected value based on an official index between two dates is needed. It does not explicitly name alternatives or state when-not-to-use, but the use case is specific enough to guide selection among the sibling tools.

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

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

Annotations already signal read-only, idempotent, and non-destructive behavior, so the description only needs to add algorithmic context. It does: the tool subtracts debts from assets according to regime, computes each spouse's share, handles compensation for imbalance, and lets entra_partilha override the regime default. This is meaningful behavioral detail beyond the structured annotations.

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

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

The description is two sentences, front-loaded with the core purpose and followed by a single actionable usage note. Every clause earns its place and there is no redundant restatement of 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?

The description communicates the high-level calculation and output semantics (shareable mass, quota, torna) but omits how the different regimes map to the asset fields and what the regime-dependent defaults are. Given the complex nested schema, no output schema, and no field descriptions, this is an adequate but not complete description for reliable 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 carry the parameter-meaning burden, but it only explains one nested field (entra_partilha) and names bens, dividas, and regime. Important fields such as oneroso, titular, incomunicavel, heranca_doacao, adquirido_na_constancia, and anterior_casamento are left to inference from their names, which is risky in a legal-calculation tool.

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

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

The description states a specific function: computing the shareable mass in a divorce under the Civil Code and determining each spouse's quota, including compensatory torna. It uses a precise verb ('apura') and names the resource ('partilha de bens no divórcio'), which separates it from sibling calculation tools such as calculo_pensao or calculo_aluguel.

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 situates the tool's domain: divorce asset division by marital-property regime, so an agent can tell when this tool is relevant. It does not explicitly name alternative tools or give when-not-to-use guidance, but the context is clear enough that only the explicit exclusion/alternative part is missing.

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 and idempotent annotations, the description reveals the calculation behavior: per-month computation, deduction of payments, application of INPC correction, and 1% monthly interest from each due date. This gives the agent meaningful insight into what the tool actually 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?

A single dense sentence with a colon-delimited structure conveys the scope, legal basis, input modes, and calculation steps without filler. 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?

The description is strong for a calculation tool, covering the algorithm and key inputs. However, there is no output schema and the description does not state the return format or clarify all nine parameters, so an agent may still need to infer some details.

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

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

With 0% schema description coverage, the description compensates well by explaining the three formas, the role of pagamentos, the basis for remuneration, and the correction/interest logic. However, some parameters such as referencia, data_calculo, and date formats remain undefined.

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

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

The description names a specific resource ('Pensão alimentícia em atraso') and a specific verb ('calcula'), then details the calculation method. This makes it clearly distinguishable from sibling tools like calculo_aluguel or calculo_fgts.

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

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

It clearly identifies the intended scenario: overdue alimony under article 528 of the CPC. It does not explicitly contrast itself with alternatives, but the legal context and subject matter make the appropriate use obvious among the calculo_* siblings.

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

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

Annotations already establish this is read-only, idempotent, and non-destructive. The description supplements these by describing the computation behavior: it discounts work/study remission and pre-trial detention (detração) and returns a progression date rather than just a percentage. It could say more about the output format, but it adds meaningful behavioral context and does not contradict annotations.

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

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

The description is a single dense sentence that conveys the legal basis, key inputs, discounting logic, and result with no filler. It is information-dense and front-loaded, though the compact formula-style notation makes it slightly technical.

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 nine-parameter legal calculator with no output schema, the description is informative but incomplete: it does not state which parameters are required, the exact percentage rules, or the full shape of the return value beyond a progression date. The schema covers required parameters, but an agent still lacks some practical invocation details.

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

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

The input schema has 0% description coverage, so the description carries the semantic burden. It maps the nine parameters to legal concepts: primário/reincidente, comum/hediondo, violência/resultado morte, remição via trabalho/estudo, and detração. It does not spell out units or defaults, but it gives enough domain meaning for an agent to understand what each parameter represents.

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 exact legal computation (progressão de regime under LEP art. 112, Lei 13.964/2019) and names the deliverable: it returns the progression date. The specific formula factors (primário/reincidente, comum/hediondo, violência/resultado morte, remição, detração) clearly distinguish it 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 context is unambiguous: this tool is for prison sentence progression calculations, with the governing statute and applicable factors stated. It does not explicitly name sibling alternatives or conditions for when not to use it, but the legal domain is so specific that the intended use is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds the calculation behavior of summing corrected discounted installments. It does not contradict annotations, but it does not disclose return format, failure modes, or legal/processing assumptions beyond the STF agreement.

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 deliver the core operation and legal context with no filler. The most identifying information is front-loaded, making the tool easy to scan and understand.

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 zero parameter descriptions, an agent still lacks the return-value expectations, date/index formats, and required structure of each descontos item. The legal context is useful, but the description is not complete enough for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate, but it only implicitly maps to 'descontos' and 'indice' via 'parcelas descontadas' and 'corrigidas'. It leaves `data_calculo`, the competencia format, and how `indice` is applied unexplained, making reliable parameter construction difficult.

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 operation ('Restituição de descontos indevidos no INSS') and the verb ('soma as parcelas descontadas corrigidas'), with specific scope via codes 280/304/310/378 and the STF/ADPF 1.236 agreement. This distinguishes it well from the generic 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 provides a clear use context: undue INSS discounts, associative fraud, and administrative resarcimento under the STF agreement. However, it does not explicitly state when not to use it or name alternatives among the sibling tools.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses that it performs a live BACEN lookup by modality+month and that the average rate is only a reference, not a ceiling. This adds meaningful behavioral context not available from 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 dense sentences carry the domain, calculation method, live-data behavior, supported amortization systems, and a legal caveat. The identifying content is front-loaded, and every clause contributes value without 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 an 8-parameter tool with no output schema, the description gives a useful high-level result (excedente por parcela) but omits the response shape, the optional taxa_bacen_am override semantics, and calculation assumptions. It is adequate for selecting the tool, but an agent may still need to inspect the schema or infer behavior to invoke it confidently.

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

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

With 0% schema description coverage, the description must compensate for the input schema. It partially does by mentioning modality+mês, Price/SAC, and the per-installment excess, but it does not clarify the role of taxa_bacen_am relative to the live lookup, the source of the month, or the exact meaning of the required fields.

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

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

The description names a specific domain (revisional de contrato bancário), the core computation (recalcular financiamento pela taxa média BACEN), and the concrete output (excedente por parcela, Price ou SAC). This clearly distinguishes it from sibling calculation tools like calculo_fgts, calculo_aluguel, 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?

It establishes the intended use case: reviewing bank financing contracts using the BACEN market rate and either Price or SAC amortization. It does not explicitly name alternatives or say when not to use it, but the domain and method are clear enough to guide an agent toward this tool.

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

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

Annotations already cover the read-only, idempotent, non-destructive profile, so the description does not need to repeat that. It adds useful domain context about the 5% limit and corrected restitution, but it does not disclose what the tool returns, how the 'nunca amortiza' thesis is applied, or any edge-case behavior.

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

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

The description is compact and front-loaded with the tool's subject and the core calculation basis. The 'Tese' clause is somewhat extra but short and provides useful legal rationale, so the overall structure earns its place.

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

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

With five parameters, two enums, and no output schema, the description leaves too much unspecified: no parameter guidance, no return behavior, and no routing against sibling tools. It is closer to a labeled legal-thesis summary than to a self-sufficient invocation guide.

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 beneficio_mensal, indice, data_calculo, or the structure of descontos. Only the broad idea of discounts and the RMC/RCC enum values are inferable, which is not enough to compensate for the total lack of schema-level parameter documentation.

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 domain (RMC/RCC, INSS codes 217/268) and indicates the substantive focus: 5% limits and corrected restitution of discounts. It lacks a direct verb like 'calculates' or 'returns', and the 'Tese' clause reads more like legal context than a tool behavior, so it falls short of a 5.

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

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

The intended use case is implied by naming RMC/RCC and the INSS consigned-card context, but there is no explicit when-to-use or when-not-to-use guidance. With many sibling calculo_* tools, the description expects the agent to infer this tool's niche rather than stating it clearly.

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 that the tool is read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by explaining how the coefficient is computed and that the result is bounded by the minimum wage and INSS ceiling. It does not disclose rounding or default behavior, but the core calculation behavior is transparent.

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. The subject is front-loaded, and every part contributes calculation context: the formula, the coefficient rule, and the floor/ceiling bounds.

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 deterministic calculation tool with no output schema, the description provides enough context to understand what is computed and how. The main gap is that behavior when optional parameters like teto_inss or salario_minimo are omitted is not explained, and output format/rounding is not stated; these are moderate but not fatal omissions.

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 parameter-semantics burden. It maps media_salarios to average contribution salaries, tempo_contribuicao_anos to the coefficient's yearly increments, sexo to the 20H/15M threshold, and salario_minimo/teto_inss to floor and ceiling. It does not state default values or currency units for the optional parameters, but it adds substantial meaning beyond 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 computing the RMI (Renda Mensal Inicial) and provides the exact post-reform formula: average contribution salaries multiplied by a coefficient, with floor and ceiling. This is specific enough to distinguish it from sibling calculation tools such as calculo_pensao or calculo_tempo_contribuicao.

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

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

The intended use is implied by the tool name and the formula: it is for calculating RMI under EC 103/2019. However, it does not explicitly state when to use this tool instead of alternatives, nor does it mention any exclusions or when-not-to-use scenarios.

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

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

Annotations already establish this as a safe read-only, idempotent operation, so the description only needs to add behavioral context beyond that. It discloses that the value is 'dinâmico, IPEADATA', which alerts agents that the data source is external and values may change over time. However, it does not explain what happens when 'ano' is omitted (it is not required), whether an invalid year is handled, or what shape the result takes.

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 compact sentence that front-loads the core resource and then adds relevant use-case context. There is no redundancy or filler. It loses one point because it is a fragment rather than a complete, self-contained sentence, but it remains highly efficient.

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

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

For a simple single-parameter lookup, the description provides the essential purpose and primary use cases. However, it omits important operational details such as default behavior when 'ano' is absent, the return format, and whether historical years are supported. These gaps are notable because there is no output schema to fill them.

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

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

With 0% schema description coverage, the description must compensate for the undocumented 'ano' parameter. It partially does through the phrase 'de um ano', which signals that the parameter is a year. Yet it does not specify the expected format, valid range, optionality behavior, or unit of the result, leaving the agent to infer too much for a parameterized call.

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 resource and scope clearly: 'Salário mínimo nacional vigente de um ano' identifies the tool as a lookup for a given year's national minimum wage. It also positions the tool within the sibling family by saying it is the 'Base para dosimetria, pensão...' which distinguishes it from the calculation-focused siblings. However, it lacks an explicit verb and does not name a sibling directly, so it doesn't fully reach the top tier.

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 'Base para dosimetria (dia-multa), pensão por % do SM e mínimo existencial' gives clear usage context: this tool supplies the minimum-wage baseline needed for those other calculations. But it never explicitly states when to use this tool versus alternatives like calculo_dosimetria or calculo_pensao, nor does it mention exclusions or fallback scenarios.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds the computational scope, including the parameterizable existential minimum (R$600 default) and the 5-year plan horizon. This is useful context but does not disclose side effects, error behavior, or dependencies beyond what annotations imply. 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 that front-loads the legal framework and then lists the computed metrics. There is no filler; every phrase adds meaning, and the information is organized for quick scanning.

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?

Since there is no output schema, the description's listing of output metrics is valuable. Yet it does not specify the return format or clarify how the required inputs renda_liquida and dividas relate to the calculation. It provides sufficient domain context but leaves operational details such as units and precise input expectations to inference.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It partially does: it explains minimo_existencial is parameterizable with an R$600 default and implies prazo_meses corresponds to a plan of up to 5 years. However, it does not describe renda_liquida or the structure and meaning of dividas, leaving important gaps.

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

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

The description names the specific legal domain (Lei 14.181/2021) and enumerates the calculation outputs: percentage of income committed, existential minimum, available income, and payment capacity over up to 5 years. This clearly identifies what the tool does even without an explicit verb. It is also easily distinguishable from sibling calculo_* tools because of the superendividamento subject matter.

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 the tool is for over-indebtedness analysis, giving an agent a reasonable idea of when to use it. However, there is no explicit guidance on when to select this tool over sibling calculation tools, nor any exclusions or mention of 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 indicate readOnly, idempotent, and non-destructive behavior, and the description adds valuable behavioral rules: counting overlapping periods once, applying special-activity conversion factors only up to 13/11/2019, and returning total time plus whether old-time thresholds are met. 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?

The description is two dense sentences with no filler. The main calculation behavior is front-loaded, followed by the conversion rule and the return value, making it easy to parse quickly.

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 lack of an output schema, the description covers the essential return semantics (total time and threshold attainment) and the key calculation rules. It omits some input-format details and explicit sexo mapping, but the schema enums and the threshold notation supply enough context for a read-only calculation tool.

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

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

With 0% schema description coverage, the description must compensate, and it does partially by explaining how vinculos are summed and special activity is converted. However, it does not explain the sexo parameter or the expected date formats, leaving the agent to infer from enums and the 35H/30M threshold hint.

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 sums CNIS contribution links, handles concurrent periods once, and converts special activity to common using EC 103/2019 factors. This clearly distinguishes it from the many sibling calculo_* tools, which target different legal calculation domains.

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 such as CNIS, the EC 103/2019 cutoff, and the old-time thresholds (35H/30M), which implies it is for contribution time calculations. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, so the guidance is 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?

The description goes beyond the annotations by disclosing that the calculation includes INSS and IRRF discounts using 2026 tables and that indemnification-type amounts are exempt. This adds meaningful behavioral context about what the tool computes. It does not describe output shape or exact method details, but the readOnlyHint and idempotentHint already cover the safety profile, and the description does not contradict them.

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

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

The description is two dense sentences with no filler or repetition. It front-loads the main subject and then adds a clarifying statement about tax-exempt indemnification amounts. Every phrase contributes useful domain 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?

This is a complex labor-law calculation with 9 parameters, no output schema, and zero schema descriptions. The description gives a solid high-level overview but omits critical invocation details such as date formats, how aviso and motivo enums affect the result, the meaning of projetar_aviso, and what the tool returns. An agent would need external domain knowledge to call this correctly and interpret the result.

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 by explaining parameters such as salario, admissao, demissao, aviso, motivo, saldo_fgts, dependentes, projetar_aviso, and ferias_vencidas. It does not map any parameter to its meaning or expected format. The domain context helps infer some roles (e.g., saldo_fgts relates to the FGTS fine), but this falls short of adequate parameter guidance for a 9-parameter tool.

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

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

The description clearly identifies the resource as Brazilian CLT termination pay/labor settlement calculation and enumerates the main components (salary balance, notice, 13th salary, vacation, FGTS penalty). It lacks an explicit verb like 'calculates', but the noun phrase plus tool name makes the purpose unambiguous. It does not explicitly differentiate from sibling tools such as calculo_fgts, but the scope is still clear.

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

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

The phrase 'Verbas rescisórias / liquidação trabalhista (CLT)' implies the tool should be used for CLT termination calculations, so usage is inferable. However, it does not state when not to use it or point to alternatives like calculo_fgts for FGTS-only scenarios. There is no explicit when/when-not guidance, only 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's job is lighter. It adds value by disclosing exactly what the response will contain under both connected and missing-credential scenarios. No contradictions with annotations.

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

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

Two compact sentences deliver the core purpose, the success condition, and the failure condition. The primary statement is front-loaded and every sentence earns its place.

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

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

For a parameterless read-only status tool, the description is complete. It describes both possible outcomes, explains the meaning of authenticated/pending states, and includes the URLs an agent would need. No output schema exists, but the description sufficiently covers the return behavior.

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 appropriately focuses on behavior rather than parameters, and there is no schema detail to compensate for.

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: 'Returns connection status and URLs.' The conditional outcomes clarify the tool's function. However, it does not explicitly differentiate itself from the sibling tool 'authenticate', which is closely related.

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 is useful by describing the two possible states of connection status. It does not explicitly state when to use this tool instead of 'authenticate' or any other sibling, so the routing guidance is only implicit.

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

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

Goes far beyond the annotations: explains that invoke runs tools even when not installed, does not bloat the tool list, returns connect/checkout links when credentials or payment are missing, and requires admin for writes. The description aligns with readOnlyHint=false and openWorldHint=true, with no contradiction to 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 long but every sentence adds value for a 14-action, 23-parameter dispatcher. It is front-loaded with purpose and core flow before diving into invoke/install distinctions and prompt library. A bulleted structure and grouping of related actions would improve scannability, but the density is justified.

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, no output schema, and zero schema descriptions, the description covers the primary flows, auth, billing, and the prompt library well. It lacks explicit return-value details for most actions and does not enumerate required params per action, which an agent would still need to discover or infer for edge cases.

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

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

Schema coverage is 0%, so the description carries nearly the whole burden. It explains the most important parameter, 'action', and connects 'mcp_id', 'tool_id', and 'arguments' to the search/describe/invoke flow. However, several params like cancel_reason, prompt_vars, prompt_targets, request_details, and report_context are left for the agent to infer from their names.

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 clear verb ('run', 'discover', 'install') and resource ('mcp.ai marketplace', 'catalog of every MCP/tool'). It distinguishes itself from sibling calculators and support tools by defining its core flow: search → describe → invoke. It also explains the prompt-library sub-domain, leaving no ambiguity about what the tool does.

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

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

Gives explicit routing guidance: prefer invoke for one-off use, use install only to make an MCP permanent; use search_prompts/get_prompt/publish_prompt for prompt text. It states prerequisites such as 'writes require workspace owner/admin' and explains when invoke returns a connect or checkout link and to retry after the user opens 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 cover read-only, destructive, and idempotency hints. The description adds useful behavioral context by saying the conversation array is needed for reproduction, but it does not clarify what happens after submission, whether a response is returned, or any side-effect details beyond 'send feedback.'

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, front-loaded sentences with no filler. The purpose statement comes first, and the reproduction-data instruction is concise and actionable.

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 three parameters and no output schema, the description is under-specified. It covers the main purpose and one parameter, but leaves the required message field undefined and gives no format example or clarification for context or the conversation string.

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 only mentions the conversation parameter, and even then it calls it an 'array' while the schema types it as a string. The required 'message' parameter and the optional 'context' parameter are entirely undocumented in the description.

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 specific actions: reporting a bug, missing feature, or sending feedback. This distinguishes it from the sibling calculation, authentication, and connection 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 intended usage is inferable from the action verbs, and the instruction to include the conversation array provides some practical guidance. However, there are no explicit when-to-use or when-not-to-use conditions, alternatives, prerequisites, or exclusions.

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

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

Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds useful specificity by stating that both MCP platform and adapter versions are reported. It does not describe the exact response shape, but for a zero-parameter version getter this is a minor gap.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to the tool's meaning, and there is no redundancy with the schema or annotations.

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 very simple, zero-parameter, read-only version lookup. The description tells the agent exactly what information the tool provides. No output schema is present, but the return content is self-evident from the description, so nothing essential is missing.

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

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

The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics to document. Following the rubric, a zero-parameter tool receives a baseline score of 4.

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 ('Show') and explicitly names the resource ('current MCP platform and adapter versions'). It clearly distinguishes this tool from the calculation and authentication siblings, leaving no ambiguity about its function.

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 imperative phrasing clearly implies this tool is used when version information is needed. None of the sibling tools perform version retrieval, so no exclusion is strictly necessary. It lacks an explicit when-not-to-use statement, but the context is unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by specifying what 'state' means: installed MCPs, connection status, accounts, and catalog tool counts. It does not contradict any annotations and there appears to be no hidden mutation or side effect.

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

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

The description is a single sentence that front-loads the core purpose and immediately specifies the meaningful contents of the result. There is no filler, repetition, or unnecessary detail.

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

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

For a zero-parameter read-only state inspection tool, this description is complete. There is no output schema, so the description carries the burden of explaining what the agent will receive, and it does so concretely by listing the four categories of returned information.

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

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

The tool has zero parameters and 100% schema description coverage, so there is nothing for the description to clarify about inputs. The description appropriately focuses on the return content instead of inventing parameter guidance.

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

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

The description states a clear verb ('returns') and a specific resource ('current toolkit state'), then enumerates exactly what information is included: installed MCPs, connection status, connected accounts, and catalog tool counts. This distinguishes it from sibling tools like show_version 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 makes it clear this is an informational state-reading tool, which implies it should be used to inspect toolkit status. However, it does not explicitly state when to prefer it over alternatives or provide any 'use this when...' guidance. The context is adequate but not explicit.

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