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

With no annotations, the description carries the full burden and does meaningful work: it declares the amortization system (Price), the compounding model (juros compostos), and explicitly enumerates what is excluded from the result (IOF, fees, insurance). It does not disclose rounding behavior, which matters for a financial calculation.

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

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

Three short sentences with zero filler; the computation method is front-loaded and the unit clarification and exclusions follow in order of importance. Nothing is redundant.

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

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

For a pure computation tool with 3 required numeric params, full schema coverage and an output schema, the definition covers method, rate unit and result scope. The only meaningful gaps are rounding/precision conventions and the absence of any annotations, which the description partly offsets.

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 100%, so all three parameters are already documented, establishing a baseline of 3. The example '1.99' usefully reinforces that the rate is a percentage (not a decimal fraction), but that repeats what the schema already says ('Taxa de juros em % ao mês').

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 and resource ('Calcula parcelas fixas') and names the exact method used ('tabela Price com juros compostos'), which is the key disambiguator versus other amortization systems. An agent can tell precisely what computation this tool performs without consulting the schema.

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

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

The description scopes the result ('Não inclui IOF, tarifas nem seguros'), which implicitly tells the agent when the output is or isn't sufficient, and clarifies the rate unit. However, it never states when to prefer this tool over alternatives or what preconditions apply (e.g. rate must be non-negative, max 1200 installments).

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?

No annotations are provided, so the description carries the full burden. It does disclose a genuinely useful behavioral detail: the bands come from an external JSON resolved via the MCP_FAIXAS_PATH environment variable or the caminhoConfig parameter. However it does not say what happens when the file is missing, malformed, or when the salary falls outside all bands, which are the main failure modes an agent would want to anticipate.

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

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

A single sentence that front-loads the core purpose and then adds the configuration caveat, with no filler. It is efficient, though the parenthetical config detail makes the sentence slightly heavy for a two-parameter tool.

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

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

An output schema exists, so the return shape need not be explained, and the input schema fully documents both parameters. For a simple lookup tool the description is nearly sufficient, with the only real gap being error behavior around the external config file.

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 100%, so both parameters are already documented in the schema, setting a baseline of 3. The description adds a little value by naming the environment variable MCP_FAIXAS_PATH that the configurable file may come from, which the schema does not mention, but it does not clarify precedence between the env var and the parameter.

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 and resource: it tells which salary band ('faixa') a salary falls into, and names the data source (a configurable JSON of bands). That is unambiguous and no sibling tool does anything similar, so no differentiation is needed. It stops just short of 5 because the phrase is dense and the notion of 'faixa' is left to the config file to define.

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

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

The description implies the use case (classifying a salary against bands) but never states when to use it versus alternatives or any precondition such as the config file needing to exist. With unrelated siblings there is no routing ambiguity, so implied usage is adequate rather than deficient.

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

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

With no annotations, the description carries the behavioral burden and discloses key traits: it generates a static EMV BR Code with CRC16, allows payer-entered amount when no value is supplied, and normalizes/truncates name and city. It does not discuss side effects or error conditions, but the output schema covers return values.

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 and front-loads the core purpose before adding behavioral details. No sentence is wasted.

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 schema and output schema are rich and already document parameters and returns. The description supplies the critical generation behavior and normalization details, though it does not cover error handling or 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 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: optional 'valor' means the payer supplies the amount, and 'nome'/'cidade' are ASCII-normalized and truncated to 25/15 characters.

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: 'Gera o payload Pix estático (BR Code, padrão EMV) com CRC16.' It clearly identifies the tool as a Pix payload generator, distinguishing it from validation-focused siblings such as validar_pix.

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

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

The description explains the conditional behavior when 'valor' is omitted: 'Sem valor, o pagador informa o valor.' However, it does not explicitly say when to use this tool versus alternatives like validar_pix, so usage is implied rather than fully guided.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses that validation is local/check-digit based and that the bank is not queried. It does not describe error behavior or the exact result format, but an output schema exists to cover return values.

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

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

Two sentences, both front-loaded with the essential operation and the key limitation. There is no filler, and the most important constraint (no bank consultation) is stated directly.

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

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

For a single-parameter validation tool with an output schema, the description covers what is validated, which formats are accepted, and the major limitation that it does not check payment or due status. Nothing critical is missing for correct invocation.

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

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

Schema coverage is already 100%, but the description adds meaningful domain constraints: the input must correspond to a 47- or 48-digit linha digitável, depending on boleto type. The schema separately handles punctuation and spacing, so this is a useful complement rather than a repetition.

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: 'Confere os dígitos verificadores da linha digitável'. It also distinguishes the two supported boleto formats (47 digits for bancário, 48 for arrecadação/convênio), which is more precise than the title alone.

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 frames the intended use as checking check digits and explicitly excludes bank lookup, so the agent knows not to use it for payment status. It does not name alternative sibling tools such as validar_documento, but the usage boundary is still 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the validation mechanism (check digits), the accepted input formats, and that the output is the formatted number — genuine value. It does not say what happens on an invalid document (error vs. boolean), which is the key behavioral question for a validator.

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

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

Two short sentences, front-loaded with the core action and augmented with the one detail that matters (input formatting). 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?

With an output schema present, the return value needn't be explained, and the description covers input formats and validation logic. The only real gap is failure behavior for invalid documents, which no annotation covers.

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 100% and the single parameter is already documented as 'CPF ou CNPJ, com ou sem máscara'. The description goes slightly beyond it by giving the digit counts (11/14) and naming the validation rule, which helps an agent pre-validate input before calling.

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 (validar) and specific resources (CPF de 11 dígitos / CNPJ de 14 dígitos), plus the mechanism (dígitos verificadores) and the shape of the result (número formatado). This clearly distinguishes it from siblings like validar_pix and validar_boleto, which validate different artifact types.

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 input context clear (accepts with or without punctuation) but never says when to prefer this over validar_pix or validar_boleto, nor what to do when a document is invalid. Usage is implied by the resource name rather than routed explicitly.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses that CRC16 verification and required-field checking occur and what is extracted, which implies a read-only validation. It does not describe outcomes for invalid payloads (error vs. validity flag) or any side effects, leaving a real 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?

A single sentence, front-loaded with the verification action and ending with the extraction outcome. No redundant or filler text.

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

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

An output schema exists, so return values needn't be explained, and the single parameter is fully documented in the schema. The description covers the core behavior and extraction output; only failure-mode behavior for invalid payloads 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?

There is a single parameter with 100% schema description coverage ('Texto do Pix copia e cola'), so the schema does the documentation work. The description references the payload concept but adds no format details, syntax, or size constraints beyond the schema — the baseline 3 applies.

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 two specific verbs ('Confere' and 'extrai') on a concrete resource ('payload Pix') and enumerates the extracted fields (chave, nome, cidade, valor). This clearly separates it from generation-oriented siblings like gerar_pix without ambiguity.

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

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

Usage is implied by the purpose: an agent can infer the tool applies to a Pix copia e cola string. However, there is no explicit statement of when to prefer this over gerar_pix or validar_boleto, nor any exclusion or prerequisite guidance.

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