Cálculo Trabalhista

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

It discloses persistence semantics: config header yields a permanent non-expiring connection, while a pasted token yields a session-only login. It also reveals that no-arg calls return the link. This adds meaningful behavioral context beyond the annotations' idempotent and non-destructive 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 sentence carries useful information, and the recommended 'best' approach is placed early. It could be slightly more polished but is not padded.

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

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

For a tool with one optional parameter and no output schema, the description covers both login modes and the fallback no-arg behavior. It does not explain post-authentication effects on other tools, but that is reasonably implicit for an auth helper.

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 fully by explaining the only parameter: token is a JWT, is optional, and should be passed only after the user pastes it. It even gives the exact payload shape.

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 positions the tool as an authentication mechanism for IDE agents, describing a browser login flow with access tokens. It identifies the resource ('access token', 'login link') and the action, though it does not explicitly contrast it with the sibling 'connect' tool.

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

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

It gives explicit conditional instructions: call with no args to get a link, call with { token: '<jwt>' } for session-only login, or configure a header for a permanent connection. This is a clear decision tree for invocation, even if it does not discuss when to use an alternative 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 establish read-only, idempotent, non-destructive behavior. The description adds the material calculation rules: index-based adjustment, monthly correction of overdue installments, 1% monthly late interest, penalty, and a per-month plus total return. It does not disclose how optional parameters like data_calculo or periodicidade_meses alter the 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?

Two efficient sentences: the first states the scope and rules, the second the return format. No filler or repetition of schema information.

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

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

For a read-only calculation with strong annotations, the remaining gaps are optional parameter semantics and the absence of an output schema. The description still gives enough context for an agent to invoke the tool for the standard use case.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains the main domain concepts (initial rent, contract start, overdue period, index, interest, penalty) but does not map them to specific parameter names or explain optional fields such as periodicidade_meses, data_calculo, and the indice enum values.

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

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

The description names a specific resource (overdue rent) and a precise legal basis (Lei 8.245/91), then enumerates the operations: reajuste, monthly correction, late interest, penalty, and output. This clearly distinguishes it from the many 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 clearly defines the target case: overdue rent under the Brazilian lease law, with indexation and monetary correction. It does not explicitly list exclusions or alternative sibling tools, but the legal and factual scenario is enough to route an agent to the correct calculator.

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, so the description does not need to repeat that. It adds valuable behavioral caveats: SELIC already includes correction plus interest, and the post-September 2024 civil regime uses IPCA + legal rate. It also states the output includes per-parcel breakdown and totals, going 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 and front-loaded: the first sentence states the main purpose and output, and the second conveys high-value legal warnings. No sentences are wasted, and the critical caveats are emphasized effectively.

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

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

For a tool with no output schema, the description appropriately mentions the return shape. The legal-regime warnings are especially important for correct invocation. Still, with 11 parameters and no parameter descriptions in the schema, a bit more detail on the remaining inputs 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 description coverage is 0%, so the description must compensate. It does explain the role of indices, interest, fine, and fees, and gives a specific warning about SELIC and juros. However, it does not clarify several parameters like pro_rata, data_calculo, periodicidade_juros, multa_incide_sobre_juros, or honorarios_tipo, leaving meaningful gaps for a tool with 11 parameters.

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

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

The description clearly names the tool's function ('Atualização monetária / liquidação de débito judicial') and the concrete action ('corrige parcelas por um índice oficial... aplica juros, multa e honorários'). It also specifies the return value ('Retorna detalhamento por parcela e totais'), which differentiates 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 about when to use the tool: for monetary correction and judicial debt settlement with official indices. It also adds important legal guidance about SELIC and post-2024 civil rules, giving the agent actionable constraints. However, it does not explicitly name alternatives or state when not to use this tool.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds legal context and the three-phase calculation structure, but it does not disclose output format, edge-case handling, or parameter constraints. There is no contradiction with annotations.

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

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

The description is a single dense sentence that front-loads the core purpose, legal basis, and the three-phase methodology. It contains no filler, and each parenthetical adds relevant legal specificity.

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

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

For a 9-parameter legal calculation tool with no output schema, the description is too thin. It omits parameter-level semantics, fraction units, input constraints, and return-value expectations, leaving an agent under-equipped to invoke it with confidence without external documentation.

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

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

With 0% schema description coverage, the description carries the burden of explaining nine parameters, but it only maps broad legal concepts and vaguely mentions 'Frações configuráveis.' It does not clarify the meaning of pena_min_anos/pena_max_anos, how agravantes/atenuantes numbers are counted, the fraction format, or the structure of causas_aumento/causas_diminuicao arrays.

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

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

The description clearly identifies the tool as a Brazilian criminal sentence dosimetry calculator using the three-phase system under art. 68 CP, naming each phase and its legal reference. This makes its purpose unmistakable and distinguishes it from the other calculo_* siblings, though it does so without explicitly naming an alternative tool.

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

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

The legal content makes the intended use reasonably clear: calculating criminal sentences according to the trifásico system. However, the description gives no explicit guidance on when to choose this tool over related alternatives, nor does it state exclusions or prerequisites.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that: it works 'por depósito', accepts manual deposits, mentions the roadmap for OCR statement input, and specifies the interest component. This goes beyond the structured annotations.

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

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

The description is concise and front-loaded with the purpose, followed by the calculation logic and input mode. It uses two sentences with no filler. Slight awkwardness in the noun-phrase opening and the parenthetical roadmap prevents a perfect 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 calculation tool with 4 parameters, no output schema, and 0% schema description coverage, the description conveys the core algorithm and input mode but omits the return format, the role of 'data_calculo', and whether the 3% interest is applied by default. These are meaningful gaps for an agent trying to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does by clarifying 'depósitos' as manual deposits and naming inflation indices and 3% a.a. interest, which maps to 'indice' and 'incluir_juros_3aa'. However, it does not explain 'data_calculo' or the format/behavior of the required 'depositos' array beyond what the schema already shows.

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

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

The description identifies a specific verb ('calcula'), a specific resource (FGTS correction), and the exact calculation (difference between inflation-index correction and TR correction, plus 3% a.a. interest). This clearly distinguishes it from the many other 'calculo_*' sibling tools.

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

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

The description gives clear contextual clues—FGTS, TR-to-INPC/IPCA-E thesis, STF—that imply when the tool should be used. However, it does not explicitly state when to use this tool instead of alternatives like calculo_indice or calculo_revisional, nor does it mention any exclusions or prerequisites.

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, covering the safety profile. The description adds meaningful behavioral detail beyond that, such as the BACEN/IBGE date convention and the two output modes depending on `valor` and `incluir_valores`. 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 compact and well-structured: the first sentence states the core purpose and date convention, and the second covers the two conditional behaviors. Every clause adds information, with no redundant 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 no output schema, 0% schema description coverage, and six parameters, the description is incomplete. It fails to explain the `pro_rata` behavior, the expected date format, what happens when `data_final` is omitted, or the shape of the returned data. An agent would likely need additional trial and error to invoke this correctly in all intended 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 description coverage is 0%, so the description must compensate, but it only explains `valor` and `incluir_valores` explicitly. The `pro_rata` parameter is not mentioned, and `indice`, `data_inicial`, and `data_final` lack detailed semantics beyond the general 'entre duas datas' context. This leaves significant ambiguity for a six-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 a specific action ('Consulta de índice oficial') and resource: the official index correction factor between two dates. It also adds a precise month convention (initial month excluded, final month included), which makes the purpose unambiguous. It does not explicitly differentiate itself from siblings, but the unique index-focused scope is clear enough among the 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 useful conditional guidance: if `valor` is provided, it returns the corrected value; if `incluir_valores` is true, it returns monthly variations. However, it does not explain when to prefer this tool over alternative calculation tools or when not to use it. Usage context is implied rather than explicitly contrasted with 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?

The annotations already declare read-only, idempotent, and non-destructive behavior, and the description adds substantial behavioral detail on top: the underlying formula, per-spouse quota, torna for imbalance, and the ability to override the regime default through entra_partilha. This goes far beyond the annotation booleans.

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 efficient: two sentences deliver the purpose, formula, output concept, and a usage tip with no filler. The most important scoping information appears first, and the actionable override instruction is cleanly separated at the end.

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 nested arrays, four parameters, no output schema, and no property descriptions, the high-level formula and override rule are useful but incomplete. It does not explain how each regime maps to the legal flags or what the result structure looks like, though the clear domain and self-explanatory Portuguese field names reduce the risk.

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%, but the description does give meaning to the main parameters: regime selects the legal rule, bens and dividas feed the mass calculation, and entra_partilha overrides defaults. However, several nested legal flags such as oneroso, heranca_doacao, adquirido_na_constancia, anterior_casamento, incomunicavel, and titular are left unexplained, so an agent must rely on field names and legal background.

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 is specific and domain-rich: it states the tool computes divorce asset division under a Civil Code property regime, including shareable mass, each spouse's quota, and equalization payment. This clearly differentiates it from sibling calculo_* tools such as pensao, FGTS, and trabalhista, which address different 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?

It provides clear application context: use for divorce asset partition when a Civil Code regime applies, and it explains how to override the default inclusion of assets via entra_partilha. It does not explicitly name excluded cases or compare with alternatives, but the intended use is obvious enough that an agent can choose it without confusion.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable algorithmic transparency: it discloses the per-month calculation, the three calculation modes, subtraction of payments, and the INPC correction plus 1% monthly interest from each due date.

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

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

The description is a single dense sentence with no filler. It front-loads the purpose, then packs the calculation rules into parentheticals and clauses, giving maximum information per word.

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

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

The description covers the main calculation flow well, but with 9 parameters and no output schema, some gaps remain. It does not explain what the tool returns, nor explicitly clarify whether juros and indice parameters override the stated INPC/1% defaults, nor define data_calculo. These are meaningful gaps for a complex financial 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 carries the full burden for parameter meaning. It successfully explains the main concepts: forma modes, payment subtraction, correction/interest, and the period. Some parameters like data_calculo and the precise role of referencia remain implicit, but the core relationship between inputs and the calculation is clear.

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'), cites the legal basis (art. 528 CPC), and details the exact calculation scope: monthly due amount, payment subtraction, correction, and interest. This clearly differentiates it from sibling calculation tools like calculo_trabalhista or calculo_revisional.

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

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

The description gives strong contextual grounds for when to use this tool: overdue alimony under art. 528 CPC. It does not explicitly name alternative tools or state when not to use it, but the subject matter is specific enough that an agent can reliably route to it among the many 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 declare the operation is read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail by explaining the computation process: applying percentage factors, discounting remission (work/study) and pretrial detention, and returning a progression date. This goes beyond what the annotations alone convey and clarifies the tool's internal logic.

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 core subject and legal basis, then packs the mathematical and legal factors efficiently. Every clause adds useful information, and there is no repetition or filler.

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

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

For a complex legal calculator, the description covers the main factors and return value well. It names the applicable law, the calculation dimensions, the deductions, and the output. The main gaps are the absence of explicit references to the required sentence length and start date parameters, and the lack of percentage values—though these are likely legal rules rather than tool-specific knowledge.

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 burden of explaining parameters. It does map several parameters implicitly: reincidente, hediondo, violencia, resultado_morte, horas_estudo, and dias_trabalhados relate to the named factors. However, it does not explicitly explain the two required parameters (pena_anos and inicio_cumprimento), date formats, or units, leaving partial ambiguity for a complete invocation.

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

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

The description clearly identifies the tool's purpose: calculating prison regime progression (progressão de regime) and returning the progression date. It names a specific legal basis (LEP art. 112, Lei 13.964/2019) and enumerates the key factors involved, which distinguishes it from sibling calculation tools like calculo_dosimetria or calculo_trabalhista.

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

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

The description makes the applicable scenario obvious: computing regime progression for prisoners based on legal criteria such as reincidence, heinous crime, violence, and death result. It does not explicitly name alternative tools or exclusion conditions, but the legal context and factor list are clear enough for an agent to select this tool over the sibling calculators.

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 disclose that the tool is read-only, idempotent, and non-destructive, so the bar for additional behavioral disclosure is lower. The description adds meaningful behavior by stating that it sums corrected discount installments and applies the administrative STF framework, but it does not describe return values, error conditions, or edge cases.

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

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

The description is two sentences with no filler. The main purpose is front-loaded, followed by the specific legal context, 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?

Despite good annotations and a focused purpose, the description is incomplete for invocation: there is no output schema, no parameter-level explanation, and no detail on how indice or data_calculo affect the calculation. An agent would struggle to construct a correct request beyond providing descontos.

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 the role of indice, data_calculo, or the structure of descontos items. The phrase 'soma as parcelas descontadas corrigidas' hints that descontos contains the discounted installments and that some correction index applies, but this is too implicit to guide correct parameter usage.

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 computes restitution of undue INSS discounts by summing corrected installments. It also distinguishes itself from sibling calculo_* tools by naming the exact INSS codes (280/304/310/378) and the STF administrative agreement (ADPF 1.236).

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 this tool applies: undue INSS discounts, associative fraud, and administrative reimbursement via the STF agreement. It does not explicitly name alternatives or state when not to use this tool, but the legal and factual framing strongly narrows the appropriate use case.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context beyond annotations: it performs a 'busca ao vivo' by modalidade+mês, and emphasizes that the BACEN average rate is 'referência, não teto (STJ)', which is an important legal-behavioral nuance.

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

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

The description is two tight sentences with no filler. It front-loads the tool's purpose and operation, then adds an important legal caveat. Every sentence earns its place.

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

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

For a tool with 8 parameters and no output schema, the description is too sparse. It explains the method conceptually but leaves out parameter semantics, output shape, and edge-case guidance. The legal caveat and live-lookup note are valuable, but they do not fully compensate for missing operational 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?

Schema description coverage is 0%, so the description carries the full burden, but it only partially maps concepts to parameters. It mentions modalidade, mês, Price/SAC, and excess per installment, but does not explain optional parameters like taxa_bacen_am or data_contrato, nor provide formats or units for required fields such as taxa_contratada_am and parcela_paga.

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 specific purpose: 'Revisional de contrato bancário' and states the exact operations: 'recalcula o financiamento pela taxa média de mercado do BACEN' and 'apura o excedente por parcela (Price ou SAC)'. This is more specific than the generic sibling names like calculo_fgts or calculo_aluguel, so an agent can distinguish it.

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

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

The description gives a clear context for use: bank loan revision calculations using BACEN average rates and Price/SAC systems. It does not explicitly mention when not to use it or name alternatives, but among the sibling tools, none clearly overlap with this specific bank-contract revision scenario.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, lowering the burden on the description. The description adds useful calculation context ('5% limits' and 'corrected restitution of discounts') but does not disclose output structure, edge cases, or how the legal thesis affects the result.

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 two sentences that carry meaningful domain information without padding. The 'Tese' sentence adds useful legal context, though it is not strictly operational.

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 5 parameters including a nested descontos array, the description should clarify input meaning and expected return value. It provides a high-level legal and calculation theme but leaves the agent without enough operational detail to invoke the tool correctly or interpret its 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, but it does not explain the individual parameters: beneficio_mensal, descontos format, tipo RMC vs RCC, or data_calculo. It only names 'descontos' in passing, which is insufficient for an agent to correctly populate the required inputs.

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

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

The description identifies the exact legal/administrative subject: RMC/RCC reserve of consignable card margin for INSS codes 217/268, with 5% limits and corrected restitution. It does not use an explicit verb like 'calcula', but the resource and domain are specific enough to distinguish 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?

Clear context is provided: this tool is relevant when the case involves RMC/RCC, INSS codes 217/268, the 5% limit, or the thesis of a revolving card disguised as consigned that never amortizes. It does not explicitly name alternatives or say 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 cover read-only, idempotent, non-destructive behavior. The description adds value by exposing the exact formula, the 60% + 2% coefficient rule, the 20H/15M threshold, and the floor/ceiling behavior via salário mínimo and teto INSS. 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?

One dense sentence that front-loads the resource name and formula and contains no filler. Every phrase contributes semantic information about the calculation.

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

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

The formula is sufficiently detailed for the core calculation, but there is no output schema and the description does not explain return value shape or what happens when the optional salario_minimo/teto_inss are not provided. It also lacks usage context beyond the formula, leaving meaningful gaps for an agent selecting and invoking the 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?

Schema description coverage is 0%, so the description carries the burden. It effectively maps media_salarios to 'média dos salários de contribuição', tempo_contribuicao_anos and sexo to the coefficient thresholds, and salario_minimo/teto_inss to piso/teto. However, it does not specify units, default behavior when optional parameters are omitted, or value formats.

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

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

The description states a specific verb and resource: it computes the RMI (Renda Mensal Inicial) as average contribution salary times a coefficient. It also includes the EC 103/2019 context and the sex-specific thresholds, which clearly distinguishes 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 strongly implies use for post-reform RMI calculation, but it never explicitly says when to use this tool instead of a sibling such as calculo_pensao or calculo_revisional. There is no exclusion guidance or named alternative, so usage is only implied.

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

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

The annotations already declare the tool read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds that the value is dynamic and comes from IPEADATA, which is useful context. However, it does not disclose the output format, handling of invalid years, or behavior when the optional 'ano' parameter is omitted.

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 core result and then lists the concrete legal use cases. Every clause adds value, and there is no repetition of schema or annotation information.

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

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

For a one-parameter, read-only lookup, the tool is largely usable as documented, and the description supplies both the data source and the intended applications. With no output schema, however, it should state what is returned, such as a monthly R$ value, and how missing or invalid years are handled. These gaps prevent full contextual completeness.

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 says the minimum wage is 'de um ano' and the schema defines 'ano' as a number, allowing the agent to infer that the parameter is a calendar year. Given 0% schema coverage, the description partially compensates by linking the parameter to the returned value. It still lacks a valid range, format detail, or default behavior for an omitted year.

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

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

The description clearly identifies the resource: the current national minimum wage for a given year, sourced from IPEADATA. It also names concrete legal applications, which helps distinguish it from the sibling calculation tools. It lacks an explicit verb like 'returns' or 'calculates', but the intent is unambiguous.

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

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

The description explicitly states when this value is relevant: as the basis for day-fine dosimetry, percentage-based pensions, and the existential minimum. This gives an agent clear context for selecting the tool. It does not name exclusions or alternatives, but no sibling appears to be a close substitute.

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

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

Annotations already declare readOnlyHint true, idempotentHint true, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral context: the existential minimum has a default of R$600 and is parametrizable, and the plan horizon is up to 5 years. It does not disclose edge-case behavior such as handling of empty debt arrays or invalid inputs.

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 with no filler, and it front-loads the legal basis and main outputs. It is dense and somewhat fragmented, but every phrase contributes meaning.

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 lists the computed outputs, which is helpful given there is no output schema. However, it omits default values for prazo_meses, clarity on optionality, and the exact response shape. For a straightforward read-only calculator, it is adequate but has clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does: '% da renda comprometida' maps to renda_liquida and dividas, 'mínimo existencial (R$600, parametrizável)' maps to minimo_existencial, and 'plano de até 5 anos' maps to prazo_meses. It does not explicitly name parameter keys or explain credor/parcela roles, but it provides meaningful semantics 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 identifies the legal framework (Lei 14.181/2021) and lists the specific metrics computed: percentage of committed income, existential minimum, available income, and payment capacity. Although it uses a noun phrase rather than an explicit verb like 'calcula', it clearly distinguishes this tool from sibling calculation tools by subject and output.

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

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

Usage context is implied through the 'superendividamento' topic and the described outputs, so an agent can infer it is for over-indebtedness calculations. However, it never explicitly states when to use this tool over alternatives, nor does it mention exclusions or prerequisites.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral details: overlapping bonds are counted once, special activity is converted to ordinary time, conversion applies only until 13/11/2019, and the result includes a threshold indicator.

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 front-load the computation purpose, then the output. Every phrase adds information—concurrency handling, date cutoff, special-activity conversion, thresholds, and return value—with 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 complex calculation tool with no output schema and no parameter descriptions, the description gives the core algorithm, cutoff date, and return semantics. Yet it omits operational details such as date format, how the tipo enum maps to conversion factors, and special handling for PROFESSOR, which an agent would need for robust 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 parameter meaning. It clarifies vinculos as employment bonds whose periods are summed, sexo by referencing the 35H/30M thresholds, and special-activity values in the tipo enum. However, it does not explain the date format for inicio/fim or the meaning of the PROFESSOR enum value.

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 computation: summing vínculos while counting concurrent periods once, converting special activity to common time, and returning total time plus a threshold check. This clearly identifies it as a contribution-time calculator and distinguishes it from unrelated calculo_* siblings, though it does not explicitly name an alternative.

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

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

The description establishes the tool's domain (CNIS contribution time) and the key conditions, such as special-activity conversion only through 13/11/2019 and the 35H/30M old-time threshold. It does not explicitly state when not to use the tool or point to a sibling alternative, but the usage context 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 cover read-only, idempotent, non-destructive behavior. The description adds useful computational context by specifying the 2026 INSS/IRRF tables, the legal basis of Lei 12.506/2011, and that indemnity components are exempt. No contradiction with annotations was found.

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 a dense but relevant list of covered items. The second sentence adds a distinct legal nuance without repetition or filler.

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

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

The tool has 9 parameters and no output schema, so more operational guidance is needed for correct invocation. The description gives a solid domain overview but omits field-level details, especially for projetar_aviso, date formats, and the structure of the returned calculation.

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

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

With 0% schema description coverage, the description needed to compensate by explaining the 9 parameters, but it only describes calculation components at a high level. It leaves unexplained important invocation details such as the meaning of projetar_aviso, the exact mapping of motivo to the 40%/20% FGTS fine, and the expected date or salary formats.

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

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

The description clearly identifies the tool as a Brazilian CLT severance/labor settlement calculator and enumerates the components it handles, such as salary balance, indemnified notice, proportional 13th, vacations, and FGTS fines. It lacks an explicit verb and does not explicitly distinguish itself from the overlapping sibling calculo_fgts, but the core resource is unmistakable.

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: whenever a CLT severance or labor settlement calculation is needed. It does not provide explicit exclusions, name alternatives, or explain when a user should prefer calculo_fgts for a standalone FGTS calculation.

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, so the description's main job is to add state-dependent details. It does so by describing what happens when all providers are connected versus when credentials are missing, including specific fields like authenticated and pending[]. This adds meaningful context beyond the annotations.

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

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

The description is two sentences and every sentence earns its place. The first sentence states the core function immediately, and the second provides the most useful conditional distinctions. There is no redundant or filler content.

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

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

Given that there is no output schema, the description carries the burden of explaining return values, and it covers the two most important scenarios well. It does not fully specify behavior for partially connected states or what pending[] contains when non-empty, but for a simple status tool with no parameters this is a minor gap.

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

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

The tool has zero parameters, so there is no parameter semantics to document. The description correctly focuses on behavior and return values instead of inventing irrelevant parameter details. With no input schema burden to carry, this is an appropriate baseline.

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 a specific verb and resource: it 'Returns connection status and URLs.' It also adds conditional behavior around authentication states, which makes the purpose easy to identify. It does not explicitly name a sibling for differentiation, but the contrast with authenticate is reasonably clear from the status-focused wording.

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: call this tool to check connection status and obtain URLs when credentials are missing. However, it does not explicitly say when to prefer this over authenticate or when not to use it. The conditional language provides some context but stops short of direct guidance or named 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?

The description adds meaningful behavior beyond the annotations: invoke runs uninstalled MCPs one-off, returns connect/checkout links on missing credentals or empty wallet, install makes tools persist in future sessions, and search/describe distinguish installed_in_toolkit vs installed_in_workspace. No annotation contradiction exists.

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

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

The description is long but densely packed and logically ordered: identity, core flow, invoke nuance, install versus invoke, permissions, then the prompt library. It is a single run-on paragraph rather than structured bullets, but every sentence carries functional 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?

For a 14-action, 23-parameter tool with no output schema, the description covers the critical paths: invoke edge cases, install semantics, authorization requirements, billing actions, and prompt publishing. However, the resume action and parameters like immediate and conversation are not explained, and exact return shapes for search/describe are left implicit.

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 description has to compensate. It doesso for the central action enum and tool_id selection, and explains the prompt-related flows, but several parameters such as immediate, tier_slug, conversation, and request_details are left to inference from names/defaults. Meaningful but not comprehensive.

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?

States that the marketplace is the in-platform catalog of MCP/tools and the way to run them, and lays out the core search→describe→invoke flow. This clearly distinguishes it from the calculo/system siblings and from its own sub-actions.

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: use invoke for one-off use, install for permanent toolkit inclusion, subscribe/cancel for billing, request_mcp when nothing fits, and list_tools for what is currently callable. Also notes that write operations require workspace owner/admin.

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 this is a non-read-only, idempotent, non-destructive action. The description adds that the action 'sends' feedback, implying a side effect, and instructs including conversation data for reproduction. However, it does not disclose what happens after submission, whether a confirmation or ticket is returned, or any rate limits or prerequisites beyond the conversation array.

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 and the key invocation requirement. The most important instruction is front-loaded and there is no filler or repetition of schema content.

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

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

For a three-parameter tool with no output schema, the description gives the essential purpose and one important usage hint, but it leaves the 'context' parameter ambiguous and contradicts the schema's type for 'conversation'. The missing return/confirmation behavior is minor, but the parameter mismatch and undocumented 'context' make the description incomplete.

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

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

Schema description coverage is 0%, so the description carries full responsibility for explaining parameters. It explains message as the bug/feature/feedback content and conversation as reproduction context, but it calls conversation an 'array' while the schema declares it a string, which could lead the agent to pass the wrong type. The 'context' parameter is entirely unexplained.

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') with a clear resource ('a bug, missing feature, or send feedback'), so an agent can tell this tool is for issue reporting and feedback. It does not explicitly differentiate itself from siblings, which are mostly unrelated calculation/authentication tools, so it misses the top score only by not naming any alternatives.

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 states the intended use cases: reporting a bug, requesting a missing feature, or sending feedback. It gives a concrete usage instruction ('Include the conversation array with recent messages for reproduction'), but it does not state when not to use the tool or mention any alternative for non-reporting needs.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the output content (platform and adapter versions) but no further behavioral detail such as output format or external calls.

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

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

A single sentence with no filler. The verb 'Show' leads, followed immediately by the resource, making the purpose instantly clear.

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-input, read-only informational tool, the description is complete: it tells the agent exactly what information will be returned—current MCP platform and adapter versions. No output schema exists, but none is needed at this level of simplicity.

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 0 parameters and schema coverage is 100%, so there are no parameter semantics to explain. This meets the baseline for zero-parameter tools.

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?

States a specific verb 'Show' and a precise resource: 'the current MCP platform and adapter versions.' This clearly distinguishes the tool from the calculation and integration siblings by focusing on version output.

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

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

The intended use case—checking current MCP and adapter versions—is implied by the verb and object, but the description does not explicitly say when to use this tool instead of siblings like toolkit_info. No exclusions or alternative routing 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well established. The description adds context about what is returned (connection status, accounts, catalog counts) but does not disclose whether the data can be stale, whether it performs a live network check, or any potential latency. No contradiction with annotations exists.

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

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

The description is a single, front-loaded sentence that immediately states the tool's purpose and then lists the specific components of the returned state. Every word adds value and there is no filler or redundancy.

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

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

With no parameters, no output schema, and annotations covering the read-only/idempotent safety profile, the description is sufficient. It enumerates what the agent will learn from the tool: installed MCPs, connection status, connected accounts, and catalog tool counts. An agent has enough to decide when to call it and what to expect back.

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

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

The input schema has zero parameters, so there are no parameter semantics to describe. Per the baseline for zero-parameter tools, the description need not explain parameters. The description focuses on the return value, 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 uses a specific verb ('Returns') and names the exact resource ('current toolkit state') followed by a detailed breakdown of what that state contains: installed MCPs, connection status, connected accounts, and catalog tool counts. This clearly distinguishes it from sibling tools like calculo_* or authenticate, which perform different actions.

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 evident that the tool is for inspecting toolkit status, and with zero parameters it is trivial to invoke. However, it does not explicitly state when to prefer this over related tools like show_version or connect, nor does it provide any exclusion criteria. Usage context is implied rather than stated.

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