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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint false), and the description still adds real behavioral detail: one entry per movement, deterministic counterpart resolution from the first matching rule, and an explicit no-guessing fallback to `suspense_account` with the movement surfaced in `unmatched`. It does not mention whether the output is returned inline or as a file, but an output schema exists to carry that.

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 outcome, then the entry-mapping rule, then a scannable Args block; nearly every clause earns its place. The content/content_base64 pairing and the long embedded rules example add length, though both carry genuine selection-relevant detail.

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

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

For a 14-parameter conversion tool with annotations and an output schema, the description covers the decision-critical parts (input format, rule resolution, fallback behavior). The remaining gap is the handful of undocumented format/length knobs, which an agent could not confidently set without opening the schema.

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 does for most of the 14 params: bank_account (with a concrete example), target_format values, content vs content_base64 (including why base64 for CP850/Latin-1), rules structure, bank_accounts keying, use_value_date, suspense_account default, start_entry_number. Several parameters — a3_format, company_code, decimal_comma — are never explained anywhere, which keeps this from a 5.

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 ('Turn a Norma 43 ... bank statement into journal entries ready to import') and immediately pins down the mapping semantics (abono -> Debe bank, cargo -> Haber bank). It is distinguishable from siblings like detect_format (format sniffing) and validate_journal (checking), and it cross-references convert_journal for the account resizing options.

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 clear: this is the tool for .n43/Cuaderno 43 inputs, and rules are applied in order with first-match-wins made explicit. The exclusions are weaker — nothing states when to prefer detect_format or build_journal instead, and the reference to convert_journal for account_digits/account_split is passed off rather than explained.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds a genuinely useful behavioral fact: an unbalanced entry is refused before any charge, and the error reports the difference. That is real failure-mode disclosure beyond structured fields, though how the output file is delivered is left to the output 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?

The text is short, but the inline JSON example is jammed into a prose paragraph and wraps awkwardly, making the entry shape harder to parse than a code block would be. The sentence 'Entries must balance: an unbalanced entry is refused before any charge, with the difference' ends on a dangling fragment.

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 tool, the description covers only the entries payload; the required target_format and the seven formatting/accounting options that determine the generated file are unexplained, leaving an agent unable to construct a valid call without guessing. The existence of an output schema excuses it from explaining return values, but the input gaps remain severe.

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% across 9 parameters, and the description only explains `entries` (with its account/debit/credit/concept fields and optional number). The required `target_format` has no enum and no explanation of valid values, and a3_format, fiscal_year, company_code, account_split, decimal_comma, account_digits, and start_entry_number are entirely undocumented in both places.

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 concrete verb and resource: composing journal entries into an import file, with an inline example of the entry shape. It is clear what the tool produces, but it never distinguishes itself from siblings like convert_journal or validate_journal, so an agent must infer the boundary.

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 via the parenthetical '(e.g. from invoices or a payroll summary)', which hints at the upstream source of entries. There is no explicit statement of when to call build_journal versus convert_journal, validate_journal, or bank_to_journal, nor of any 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, idempotentHint, and closed-world, so the safety profile is covered; the description adds genuinely useful behavior not in the annotations: strict refuses to emit output on validation errors, Latin-1/CP1252 encoding handling via content_base64, ContaPlus requiring entry numbers versus A3 not, and decimal-comma conventions. It stops short of describing what the returned artifact looks like, but an output schema exists so that gap is cheap.

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 purpose and format table are front-loaded, and the Args block is dense with zero filler given 15 parameters. Minor deductions for cramming two unrelated parameters onto one line ('company_code ... a3_format: 5 ... or 4 (256, old)') and unexplained shorthand such as 'apuntes tipo 0' and '142 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 15-parameter, 0%-schema-coverage conversion tool, this is complete: every parameter has meaning, each format's origin is named, encoding and numbering constraints are flagged, and the validation-on-failure contract is stated. Return values are legitimately omitted because an output schema is supplied.

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% across 15 parameters, so the description carries the full burden and does so almost completely: it documents target_format values, content vs content_base64 encoding nuance, source_format auto-detection, account_digits resize semantics with '430.1' expansion, account_split insertion point with an example, account_map example, start_entry_number, company_code range, a3_format record sizes, column_map keys enumerated in full, csv_delimiter behavior, decimal_comma, fiscal_year, and strict.

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

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

The description opens with a specific verb and resource ('Convert a libro diario ... between Spanish accounting programs') and enumerates the four target formats with concrete product identifiers (a3ASESOR, Sage ContaPlus CSV, XDiario.txt, generic CSV). An agent can immediately tell this is a pure format-transformation tool, distinct from siblings like validate_journal, detect_format, and build_journal.

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 rather than stated: it explains that source format is auto-detected and that strict mode prevents the target program from rejecting output, which hints at when to keep strict default. However, it never says when to prefer validate_journal, detect_format, or build_journal over this tool, nor what to do when conversion fails.

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 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 readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds one piece of genuinely new behavioral information — that the call is free (no credit cost) — which matters given the pricing/credits_balance siblings. It does not disclose behavior on empty or malformed input, or whether content or content_base64 takes precedence.

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 front-loaded sentence with the useful output enumeration first and the cost note last; nothing is wasted. The trailing 'Free.' fragment is slightly abrupt but carries real decision-relevant information.

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

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

An output schema exists, so return values need not be explained. Still, with two optional, undocumented, empty-defaulted content parameters, the definition leaves an agent unsure which field to populate and what happens when detection fails.

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 both parameters are undocumented, so the description must compensate. 'A file' only vaguely implies file content; it never explains the distinction between content and content_base64, nor that both default to empty strings and neither is required. This is a real gap for a two-input 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?

Names a specific verb (detect) and resource (accounting import format) and enumerates the exact possible results (a3, contaplus_csv, contaplus_ascii, csv), which lets an agent distinguish it from the convert/validate siblings at a glance. No explicit sibling contrast is stated, so it stops short of 5.

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

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

The word 'Free' implies this is a cheap pre-flight step before convert_journal, validate_journal or build_journal, and the pricing/credits_balance siblings give that context. However, no when-to-use or when-not-to-use condition is stated explicitly, and there is no mention of what to do if detection is ambiguous.

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?

Annotations already declare readOnlyHint, idempotentHint and a closed-world scope, so safety and repeatability are covered. The description adds genuinely useful context not in the annotations: the operation is free (relevant given the pricing and credits_balance siblings) and the exact output shape via examples. It omits what happens when `digits` is shorter than the current code length or when the input has no separator, which are the real behavioral questions for a padding tool.

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 short sentence plus two compact examples, with the core action front-loaded and no filler. The examples earn their place by encoding behavior that the prose would otherwise need several sentences to convey.

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?

Because an output schema exists, the description needn't explain return values, and the examples make the mapping fairly clear. For a simple read-only transform this is close to adequate, but the undocumented `split` parameter and the unstated truncation behavior leave an agent guessing on a non-default call.

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% for all three parameters, so the description carries the full burden and only partially meets it. The example '4300001 (7) -> 43000001 (8)' implicitly reveals that `digits` is the target length, but the optional `split` parameter (default 4) is never explained — the '430.1' example hints it governs separator handling without stating so.

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 verb and resource ('Resize or expand a Spanish subaccount code') and backs it with two concrete transformation examples, so the agent knows the tool reformats/pads an accounting code rather than validating or converting a journal. It stops short of 5 because 'resize or expand' is slightly ambiguous about whether shrinking is permitted, and no sibling is named as the 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?

There is no statement of when to reach for this tool versus siblings such as detect_format or validate_journal, and no prerequisites (e.g., must the account already exist, must the format be Spanish). The only usage signal is implicit in the two examples.

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

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

Annotations already cover the safety profile (readOnly=true, idempotent=true, closed-world), yet the description still adds real substance: the exact categories of findings reported (imbalances with the difference, debit/credit anomalies, non-numeric or out-of-PGC accounts, subaccount length inconsistencies, dates outside fiscal_year), the `valid` flag semantics, and the 50-entry cap on include_entries. It does not state whether validation stops at the first error class or reports all of them, which keeps it off a 5.

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 purpose, then a compact enumeration of findings, then two short sentences on output behavior. Every sentence carries information; the only mild density cost is that the error list is run together in prose rather than separated, slightly slowing parsing.

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 output schema means return values need not be re-explained, and the reported error classes are well covered. However, for a 7-parameter tool with no schema text, the description leaves the input side underspecified — content vs content_base64, source_format values, and column_map structure are all unexplained, which is enough to cause a malformed call.

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?

Seven parameters with 0% schema description coverage, and the description only gives meaning to two of them: fiscal_year (dates outside it are flagged) and include_entries (returns the first 50 entries). The core inputs content, content_base64, column_map, csv_delimiter and source_format ('auto' default) are undocumented in both the schema and the description, leaving an agent to guess at payload format and delimiter/column-mapping behavior.

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 ('Check a journal file') plus the exact validation domain (A3/ContaPlus import rules) and the point in workflow where it applies ('before you send it'). Against siblings like convert_journal, build_journal and detect_format, an agent can tell this is the pre-flight validator without opening any 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?

'before you send it' implies the right moment to call it, and the enumerated error classes imply what it is for. But it never names alternatives such as convert_journal or detect_format, and says nothing about when not to use it (e.g. after a file is already known-good, or when a conversion is needed first).

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