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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact — that the call is free — but says nothing about whether the value is live or cached, or about any rate limiting on repeated polling.

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 fragments, front-loaded with the resource and followed by the cost note. Nothing is wasted, though the extreme terseness leaves room for a clarifying clause at no real length cost.

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, an existing output schema, and annotations covering safety, the definition is functionally sufficient to call the tool. It stops short of explaining what a credit represents or when the balance matters, leaving an agent without context for interpreting or acting on 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the empty schema already conveys. Baseline 4 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?

States a specific resource and what it reports: the remaining credit balance on the KeyFlint license. An agent can identify it as a balance-lookup tool immediately. It does not differentiate itself from the adjacent 'pricing' sibling, which is the one tool an agent might plausibly confuse it with.

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 only implied — the 'Remaining credits' framing suggests calling it to check a balance, and 'Free' hints it can be called without consuming credits. There is no explicit when-to-use statement, no prerequisite, and no comparison to alternatives such as 'pricing'.

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

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

Annotations already declare readOnly, idempotent and closed-world, so the description's added value is what it says beyond that: Spanish-Excel output defaults, protection of free-text cells against spreadsheet formula injection, and the fact that integrity issues are returned alongside the CSV. Those are genuine behavioral facts an agent could not get from the annotations or schema.

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

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

Two short sentences, front-loaded with the conversion and output shape, followed by the defaults and safety notes. Every clause carries information; 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?

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. However, with four undocumented input parameters at 0% coverage, the description leaves the content-vs-content_base64 input choice unexplained, which is a real gap for calling the tool correctly.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it only partly does. It implies the delimiter (';' separator) and decimal_comma defaults, but never explains the critical distinction between 'content' and 'content_base64' — an agent has no guidance on which input field to populate.

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 ('Convert a Norma 43 statement to CSV') and even specifies the output grain ('one row per movement, with IBAN, running balance and concept names'). It does not explicitly distinguish itself from the sibling parse_norma43, so the CSV-vs-parsed-object distinction must be inferred.

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 only implied: the tool is for turning a Norma 43 statement into CSV, and the mention of Spanish Excel defaults hints at the intended audience. There is no explicit 'use this when... use parse_norma43 instead when...' routing, which matters given a closely related sibling exists.

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/closed-world, but the description adds real behavioral detail: it enumerates the validation rules (record 33 counts and totals, opening + movements = closing, record 88 record count, dates, signs, formats), explains that `valid` is false on any error and that issues name their line. It does not say whether truncation by max_movements is surfaced in the result, which is the one behavioral ambiguity left.

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?

Front-loaded with the one-line purpose, then output shape, then validation behavior, then a compact Args block. Dense but every sentence carries information; the only mild redundancy is restating what the output schema already declares about returned fields.

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 parser with a real output schema, the description supplies everything an agent needs: input encoding options, output granularity control, movement capping, and the meaning of the `valid` flag and per-line issues. Nothing required to invoke it correctly 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?

Schema description coverage is 0%, so the description must carry the burden and it largely does: all four parameters are explained with purpose, defaults (2000, max 20000) and the encoding rationale for the base64 variant. It does not state precedence or mutual exclusivity between content and content_base64 when both are empty, which matters given zero required 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?

States a specific verb and resource ('Read a Spanish Norma 43 ... bank statement into structured JSON') and names the format variants (Cuaderno 43 / AEB43 / CSB43) so the agent knows exactly which input domain it covers. It also implies the boundary against the norma43_to_csv sibling by promising structured JSON 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?

Gives clear conditional guidance on parameter choice: use content_base64 'for CP850/Latin-1 files with Ñ and accents', and include_movements=False for a totals-only pass. It never explicitly routes the agent away from norma43_to_csv or reconcile_movements, so the sibling selection is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one behavioral fact — 'Free' — suggesting calling this tool costs no credits, which is genuinely useful context, but it is ambiguous (free tool vs. free credits) and says nothing about rate limits or how prices are kept current.

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 fragments with no wasted words. The terseness does cost some precision — 'Free.' is a bare fragment whose referent is unclear — but structure is efficient.

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

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

An output schema exists, so return values need not be described, and a parameterless informational tool has little else to specify. The remaining gap is the ambiguity of the pricing units and of 'Free', which a slightly fuller sentence could resolve.

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 takes zero parameters, so the baseline is 4; with nothing to document, the schema and description together are sufficient. No meaningful parameter context is missing.

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 (credit price of each tool) and a secondary output (where to buy credits), which is distinguishable from the sibling credits_balance that reports a balance rather than prices. It is telegraphic but an agent can tell what it returns without reading 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?

Usage is only implied: an agent would consult this to learn per-tool credit costs or where to top up. There is no explicit when-to-use statement, no mention of credits_balance as the alternative for checking remaining credits, and no stated 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?

Beyond the readOnly/idempotent annotations, the description discloses the actual matching behavior: 1:1, 1:N and N:1 support, a 0-100 score with alta/media/baja confidence, the evidence dimensions used, and the critical rule that ties are never guessed but returned under `ambiguous` and weak candidates under `suggestions`. That is exactly the operational context an agent needs to trust and act on results.

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

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

Purpose is front-loaded in one sentence, then the data model, sign convention, matching behavior, and finally a compact Args block. The length is justified because the underlying schema contains zero descriptions, so no sentence is 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?

For a reconciliation engine with eight parameters, an output schema, and no schema descriptions, the definition covers inputs, semantics, scoring behavior, and result buckets (matches, ambiguous, suggestions). Nothing an agent needs to invoke it correctly or interpret the output appears to be 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?

Schema description coverage is 0%, so the description carries the full burden, and it does: it documents the shape of `expected` and `movements` items, item caps (5000), the date window default and max (10/180), tolerance as a string with a bank-fees example, grouping behavior ('1 disables grouping, max 5'), and the min_score default. Only the max_group_size default is omitted, which is a minor gap.

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

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

The first sentence states a specific verb and resource ('match bank movements to expected items') plus a key trait ('deterministically'), and the following paragraph defines both input sides and sign convention. It does not explicitly differentiate itself from siblings like parse_norma43 or norma43_to_csv, so an agent must infer that this is the matching step rather than the parsing step.

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

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

It clearly states the two alternative input paths ('content' / 'content_base64' for a Norma 43 file versus a 'movements' list) and what the expected side should contain, which is the main usage decision. It stops short of explicit exclusions or telling the agent when to prereq-parse with a sibling instead of passing the raw file here.

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 openWorldHint=false, so safety is covered. The description adds genuinely new context: the output is deterministic and derived per EPC262-08, and the call is free — a useful cost signal given the presence of pricing/credits_balance siblings. It omits error behavior for an invalid NIF.

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, front-loaded lines: purpose, output format, and downstream use. Nothing is redundant, and the format specification is compactly encoded in a single template string.

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 and rich annotations already present, the description supplies the remaining essentials: what is produced, per which standard, and why. It could be stronger by specifying accepted NIF formats and what happens on an invalid input, but it is sufficient to invoke 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 coverage is 0%, so the description must carry the load, and it does partly: it explains the business_code as a 3-character code defaulting to '000', which the bare schema does not. The NIF parameter's expected format is left unstated, which is the main residual gap.

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

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

States a specific verb ('Compute') and a precise resource ('Spanish SEPA creditor identifier (AT-02)') derived from a named input ('from a NIF'). This clearly separates it from siblings like validate_identifier (which checks rather than generates) and parse_norma43.

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 a concrete application context: needed to issue SEPA direct debits (adeudos/remesas de recibos, Cuaderno 19.14). It does not, however, explicitly state when-not to use it or point to an alternative sibling such as validate_identifier for checking an existing ID.

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 readOnly, idempotent and closed-world, so the bar is lower; the description still adds real behavior: the ES inner CCC check, automatic kind detection, and the fact that failures return the expected control digits rather than erroring out. It also flags 'Free', which matters given a pricing/credits_balance sibling set. Minor gap: no statement about input length limits or non-identifier 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?

Front-loaded with purpose, then supported kinds, then return behavior, then args — a sensible order with no filler sentences. The backtick-marked tokens and 'Args:' block are slightly markdown-heavy for the amount of content, but 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?

Output schema exists so return values need not be explained, yet the description still summarizes them usefully. For a two-parameter pure-validation tool, the only real omission is behavior on unrecognizable input (return invalid vs. raise), which the 'when wrong, expected control digits' phrasing only partly resolves.

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% and the schema has no enum for `kind`, so the description carries the full burden and does: it gives the accepted `kind` values (auto | iban | ccc | nif | creditor_id | reference1) and states that `value` tolerates spaces and dashes. This is meaning the agent cannot get from the 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?

Opens with a specific verb+resource ('Validate a Spanish/EU banking identifier') and enumerates exactly which identifier families are covered (IBAN/SEPA, CCC, NIF/NIE/CIF, AT-02 creditor ID, Norma 43 Referencia 1). It does not explicitly differentiate itself from the sibling sepa_creditor_id, which is the one tool an agent could plausibly confuse it with.

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 enumeration of supported formats and the 'Free' note, but there is no explicit statement of when to call this versus sepa_creditor_id or parse_norma43, nor any prerequisite or exclusion guidance.

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