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 an important behavioral limit by specifying the check is mathematical (checksum only, not registry lookup), which is real value. However, it says nothing about permissions, error behavior, or what an invalid input yields.

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 zero filler, and the scope qualifier is placed front and center. Nothing 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?

An output schema exists, so return-value explanation is not required. Still, for a tool whose whole purpose is a binary check, the description never says what the check implies (e.g., checksum validity vs. account existence) or the input format, leaving modest 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?

With 0% schema description coverage on a single parameter, the description must compensate. Calling it an 'ABA routing number' implies the domain and expected identifier type, but it omits the 9-digit format and whether separators are accepted, leaving a gap the schema does not fill.

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 (Check) and resource (ABA routing number) and narrows the scope to the mathematical check digit, which cleanly separates it from siblings like validate_ach_file or parse_ach_file. It does not name a sibling explicitly, so it stops short of a 5.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The narrow scope implies this is a format-level check rather than full account validation, but the agent must infer that from 'check digit' alone, which is thin.

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 one genuinely useful trait beyond the schema: output is masked at the field level, and one schema parameter (reveal_sensitive) implies masking is the default. However, it says nothing about auth requirements, what happens when left_content or right_content is null (both default to null with no required params), or the effect of reveal_sensitive.

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 front-loaded sentence that states the action, the operands, and the output semantics with zero filler. Every word 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?

An output schema exists, so return values need not be explained, and the description correctly focuses on behavior. But for a 3-parameter tool with 0% schema description coverage and no annotations, the omission of null-handling and reveal_sensitive semantics leaves an agent guessing on the 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 description coverage is 0%, so the description must compensate and largely does not. It implies the two 'contents' map to left_content/right_content and that masking relates to reveal_sensitive, but it never explains the nullable defaults, what happens if only one side is supplied, or what reveal_sensitive actually unmasks.

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 ('Compare') and resource ('two ACH contents') plus the shape of the output ('masked field-level differences'). It is clearly distinguishable from siblings like parse_ach_file, summarize_ach_file, and validate_ach_file. It stops short of explicitly naming which sibling it complements or differs from.

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 guidance on when to use this versus parse_ach_file, summarize_ach_file, or validate_ach_file, and no preconditions stated. The reader must infer that this tool is for comparing two files rather than inspecting one.

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, yet it says nothing about whether this is a read-only operation, what input it needs (path, content, or batch_number) to locate the totals, what happens when all three optional parameters are omitted, or what the explanation contains. Only the core intent is conveyed.

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 efficient sentence with the key concept (stated versus recomputed) front-loaded and no wasted words. It is perhaps too terse for a three-parameter tool, but 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-value documentation is not required, but with zero annotations, 0% parameter coverage, and three optional parameters, the agent cannot tell how to invoke the tool or what makes a valid call. For an ACH control-total diagnostic, this leaves a large 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?

Schema description coverage is 0% across three parameters (path, content, batch_number), so the description must compensate and does not. It only loosely gestures at 'batch and file' totals, leaving it unclear whether path and content are alternative sources, which one takes precedence, or how batch_number scopes the analysis.

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 (explain) and resource (stated versus recomputed batch and file control totals), which is distinguishable from the sibling repair_control_records_tool that fixes rather than explains. It falls short of a 5 only because it does not explicitly contrast itself with that sibling.

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 word 'explain' versus the sibling 'repair' tool suggests this is for diagnosing a totals mismatch rather than fixing it. There is no explicit when-to-use statement, no prerequisites, and no named alternative.

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 must carry the behavioral burden. It usefully discloses that the output is synthetic, balanced, and must never be transmitted, but it does not explain file generation side effects, permissions, or whether the result is written to disk versus returned as content.

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

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

The description is a single front-loaded sentence with no wasted words. It communicates the core action and a critical safety constraint immediately.

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 10 parameters, no annotations, and no parameter descriptions in the schema, the definition is substantially incomplete for correct invocation. The output schema covers return values, but the description does not compensate for the missing parameter semantics or behavioral details needed to use a complex generator properly.

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 10 parameters with 0% schema description coverage, yet the description mentions none of them. It provides no meaning for seed, batches, sec_code, inject_errors, service_class, or any other parameter, leaving the agent entirely dependent on bare schema titles.

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: generate an ACH file. It also qualifies the output as 'balanced synthetic' and 'for testing, never transmission,' which clearly distinguishes it from sibling tools like validate_ach_file, parse_ach_file, and summarize_ach_file.

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

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

The phrase 'for testing, never transmission' gives clear context for when to use the tool and an explicit prohibition on using it for real transmission. It does not name alternative tools for other ACH-related tasks, but the usage boundary is otherwise 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 disclosure burden, and it says nothing about behavior: whether lookups are case-sensitive, what happens on an unknown code, whether the call is idempotent/read-only, or any rate limits. The presence of an output schema excuses it from explaining return values, but for a two-required-parameter tool with zero annotation coverage this is thin.

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 short sentence with the verb front-loaded and no filler; nothing is wasted. It is arguably too terse given the unanswered `kind`/`code` semantics, but as a conciseness measure it 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?

The tool is simple, read-only in nature, and has an output schema, so return-value detail is not required. What is missing for correct invocation is any definition of the `kind` values and the `code` format, which neither the schema nor the annotations supply.

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 there are no enums, so the description must compensate. It partially does by enumerating the five kind categories (return, NOC, transaction, SEC, service-class), which effectively hints at valid values for the `kind` parameter, but the `code` parameter's expected format (e.g., R01, a three-character code) is entirely undocumented.

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 gives a specific verb ("Look up") and resource (an ACH code) and enumerates the five code categories the tool covers: return, NOC, transaction, SEC, and service-class. That is enough to distinguish it from file-oriented siblings like parse_ach_file or validate_ach_file, though it never names an alternative explicitly.

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 when-to-use guidance, no prerequisites, and no mention of sibling tools such as check_routing_number (the other single-code lookup). The agent is left to infer that this is the right tool for decoding a code value.

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, and it is thin. It does not say whether a path or inline content is expected, what happens to sensitive fields when reveal_sensitive is false, or that parsing is read-only — all critical for a tool exposing a reveal_sensitive toggle. The pagination note is the only behavioral hint.

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 well-formed sentence with no filler, front-loading the verb and resource. It is efficient, though arguably too terse for six undocumented parameters.

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 six-parameter tool with zero schema descriptions, no annotations, and dual input modes (path or content), this description is not complete enough to invoke confidently. The output schema covers return values, but input semantics and safety-relevant behavior (reveal_sensitive) remain unaddressed.

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 six parameters, so the description must compensate and does not. It loosely gestures at record_types ('named ACH fields') and limit/offset ('bounded page'), but says nothing about the path-vs-content input choice or the highly consequential reveal_sensitive flag.

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 gives a specific verb ('parse') plus resource ('named ACH fields in a bounded page of records'), which separates it from summarize/validate siblings. However, it never names an alternative or clarifies what distinguishes 'parsing' from validate_ach_file or summarize_ach_file beyond a subtle implication.

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 when-to-use guidance and no mention of alternatives among the many ACH siblings (validate, summarize, diff, repair). The only contextual hint is 'bounded page of records', which implies paginated extraction but is not framed as usage guidance.

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 hints at a mode-dependent return ('content only in content mode') but does not say what 'repair' actually mutates, whether a file at 'path' is overwritten, whether it requires valid ACH structure, or what errors occur on malformed input.

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 short sentence is appropriately sized, but the second half ('returning content only in content mode') is ambiguous jargon that does not clearly earn its place, leaving the whole front-loaded but under-informative.

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, but for a mutation-style tool with 0% parameter coverage and no annotations, the definition omits the operation's effect on the target file, its inputs, and its failure behavior.

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

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

Schema description coverage is 0% for three parameters, so the description must compensate and largely does not. 'Content mode' obliquely gestures at the 'content' parameter, but 'path' and 'restore_trailing_spaces' receive no explanation in either schema or description.

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

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

States a specific verb+resource ('repair derived controls'), which in the ACH domain suggests recalculating control totals/records. However, it never distinguishes itself from siblings like explain_control_totals or validate_ach_file, and the trailing clause about 'content mode' muddies rather than sharpens the purpose.

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 use this tool versus alternatives such as validate_ach_file or explain_control_totals, nor prerequisites. The only guidance-like phrase, 'returning content only in content mode,' is cryptically worded and does not map to any named parameter or sibling.

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, but it does disclose that the status is for the 'local' server, implying a connectivity/health check. It does not state whether the call is read-only, what fields the status contains, or how failures surface – though output schema and zero-param simplicity limit the risk.

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, front-loaded sentence with zero filler. Nothing is wasted and the subject (server status) is stated immediately.

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

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

For a zero-parameter status probe with an output schema, the description is nearly complete – the output schema covers return values and no inputs exist. The only gap is the absence of usage context (when to probe).

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 no parameters, so the baseline of 4 applies. There is nothing for the description to clarify beyond what the empty schema already conveys.

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 ('Return') and resource ('the local achlens server status'). It is obviously distinct from all nine siblings, which operate on ACH files, though the description does not explicitly contrast itself with them.

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?

No indication of when to call this versus another tool, no prerequisites, and no mention of alternatives such as validate_ach_file or parse_ach_file. The agent must infer that this is a health/liveness probe.

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 not state that this is a read-only operation, does not explain the significance of reveal_sensitive=false, and does not disclose how path versus content are resolved, leaving key behavioral traits undocumented.

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 efficient sentence with the verb and scope front-loaded. No filler, though it is arguably too terse given the undocumented parameters.

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, but with no annotations, zero parameter documentation, and no usage guidance for a 3-parameter tool involving a sensitive-data toggle, the definition is not complete enough for confident 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% and the description mentions none of the three parameters. It does not clarify that path and content are alternative inputs or what reveal_sensitive controls, so the agent gets no semantic help beyond bare property names.

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

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

States a specific verb (summarize) and resource (ACH file) and enumerates the summarized facets (structure, totals, SEC codes, returns, NOCs), which distinguishes it from parse_ach_file and validate_ach_file. It does not, however, explicitly contrast itself with the closest siblings such as explain_control_totals.

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?

No when-to-use guidance, no prerequisites, and no mention of the alternative siblings. The agent must infer from the name alone whether to summarize, parse, or validate a file.

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 disclosure burden, yet it only hints at output shape ('structured findings and aggregate counts'). It says nothing about whether validation mutates the file, whether it is read-only, how rules/severity interact, or what happens when both path and content are 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?

A single tight sentence with the verb front-loaded and no filler. It is efficient, though its brevity is part of the under-specification problem captured in other dimensions.

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, but for a 5-parameter validation tool with zero annotation and zero schema-description coverage the definition is far too thin. An agent lacks the information to set rule_ids, min_severity, or the sensitive-data flag 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?

Five parameters with 0% schema description coverage, and the description explains none of them. The path/content alternative, rule_ids filtering, min_severity thresholding, and especially reveal_sensitive (a security-relevant flag defaulting to false) are all left completely undocumented.

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 ('Validate an ACH file') and notes the return shape (findings and aggregate counts), so the agent knows exactly what the tool does. However, it never distinguishes itself from siblings like parse_ach_file or summarize_ach_file, which an agent could easily confuse with validation.

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 guidance on when to choose this over parse_ach_file, summarize_ach_file, or repair_control_records_tool, nor any mention that exactly one of path/content must be supplied. The agent must infer usage entirely from the name.

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