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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well. It flags that this is a mutation ('WRITE'), creates a real financial instrument, and carries a severe consequence if used carelessly. The explicit approval requirement and the spending-limit warning go well beyond a generic 'create' description, though it stops short of covering failure modes or irreversibility.

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 three sentences with no filler. The action and risk are front-loaded, and the parenthetical about the entire account balance earning its place by preventing a catastrophic mis-call. Every sentence adds critical information.

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

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

For a high-stakes mutation with five parameters, no output schema, and no annotations, the description covers the essential decision and invocation needs: what it does, the mandatory approval, and the unmissable spending-limit requirement. The only notable gap is not explicitly telling the agent to source bank_account_id from lemma_list_bank_accounts, but the overall safety-critical guidance makes this a minor omission.

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 60%, so the schema already documents confirm, reference, and spending_limits. The description adds valuable context for spending_limits by explaining why at least one is required, but it does not compensate for the undocumented bank_account_id and nickname parameters. An agent would still need to infer what those refer to, though 'drawing on a Lemma bank account' hints at bank_account_id.

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 stark 'WRITE -- CREATES A REAL FINANCIAL INSTRUMENT' and then names the exact action: 'issue a virtual debit card drawing on a Lemma bank account.' It uses a specific verb and resource, and the contrast with sibling tools like lemma_get_card, lemma_delete_card, and the move-money tools is immediately clear.

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

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

The description gives clear operational prerequisites: at least one spending limit is REQUIRED, and explicit user approval is required before every call. It explains why the limit is mandatory by warning that a card without limits could spend the entire account balance. It does not explicitly name alternatives, but the context makes it evident this tool is for the creation step, not retrieval or deletion.

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 provided, the description carries the full disclosure burden, and it does so well: it clearly warns that the tool 'Creates a REAL payment destination' and that saved recipients are 'IMMUTABLE once created'. It also discloses the absence of an update API and the manual email-based archiving path, so an agent understands the operation is permanent and not reversible through normal API calls.

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

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

The description is dense but well-structured: it front-loads the action and then immediately surfaces the highest-risk warnings. Every sentence earns its place, especially the immutability, no-update-API, email-archiving, and double-check guidance. There is no filler or redundant boilerplate.

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

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

The description is strong on behavioral warnings and workflow placement, but it never states what the successful call returns—for example, an external account ID to be used with lemma_move_money_externally. Since there is no output schema, this return-value gap is meaningful. It also leaves some parameter semantics to the schema, which only partially covers them, so the overall context is not fully complete for an agent.

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 schema already covers key parameter semantics such as the confirm approval gate, reference idempotency, routing number format, and holder address constraints. The description adds the actionable warning to 'double-check routing/account numbers before confirming', but it does not explain the meaning or format of entity_id, account_number, nickname, or holder_type. With schema description coverage at 56%, the description compensates only partially and relies mostly on the schema and required fields.

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 starts with 'save a new external bank account (saved recipient) for an entity', which is a specific verb and resource that clearly differentiates this creation tool from the sibling get/list tools. It also positions it as the 'required first step before any external transfer', reinforcing its place in the workflow. There is no ambiguity with lemma_create_card or lemma_move_money_externally.

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

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

The description explicitly tells the agent when to use this tool: before any external transfer, as the required first step. It also warns that there is no update API and that archiving must be done by emailing the Lemma team, which effectively tells the agent what not to expect from or attempt via the API. However, it does not explicitly name alternatives for inspecting existing recipients, such as lemma_list_external_accounts.

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 provided, the description carries the full transparency burden. It discloses that the operation is permanent, destructive, write-only, idempotent, and gated on user approval. This is strong behavioral disclosure for a delete tool, though it does not cover failure/error behavior or what happens on repeat calls to an already-deleted card.

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 tightly packed with useful facts: WRITE, PERMANENTLY, card cancellation, idempotency, and approval requirement. Every clause adds information and the most critical constraint is front-loaded.

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 simple two-parameter delete with no annotations and no output schema, the description covers the essential invocation requirements: irreversibility, idempotency, written nature, and user approval. A minor gap is not describing the response or success outcome, but that is not necessary 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 coverage is only 50% because card_id has no schema description. The description compensates by identifying the target as 'a real card' and requiring 'explicit user approval,' which maps naturally to card_id and confirm. It could explicitly say 'set confirm=true,' but the meaning is sufficiently recoverable.

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: 'PERMANENTLY cancels a real card so it can no longer be used.' It clearly marks the operation as WRITE, which distinguishes it from read-focused siblings like lemma_get_card and lemma_get_card_iframe, and from lemma_create_card which creates rather than deletes.

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

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

It provides clear operational context: this is a write/destructive action, it is idempotent so no idempotency key is needed, and it requires explicit user approval before every call. It does not explicitly name alternatives or when-not-to-use conditions, but the usage context is strong and unambiguous.

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 behavioral burden. It explains the two output modes (write to file via save_to, or base64-inline for small PDFs), but the qualifier 'small PDFs' is unexplained and behavior for larger PDFs is left ambiguous. It also does not mention authentication or error cases.

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

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

Two sentences with no filler. The main purpose is front-loaded, and the conditional save_to behavior is stated clearly and compactly.

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 simple two-parameter download tool, the description covers the core operation and return behavior reasonably well. Since there is no output schema, it would benefit from clarifying what happens with larger PDFs and what success/error responses look like, but it is otherwise sufficient for straightforward use.

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 50%; account_id lacks a schema description. The description adds meaningful semantics for save_to (absolute path, file-writing behavior) and implies account_id through 'bank account's settlement instructions', but it does not fully compensate for the undocumented required 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 an explicit verb ('Download'), a specific resource ('a bank account's settlement instructions'), and the output format ('PDF'). This clearly distinguishes it from sibling get_* tools by naming the exact artifact being produced.

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

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

The intended use is implied: call this when you need a bank account's settlement instructions as a PDF. It does not explicitly mention alternatives or when not to use it, though it does provide useful output-handling guidance via save_to versus inline return.

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 full behavioral burden. It clearly signals a read operation via 'Get', indicates a single-object result via 'one', and discloses the possible transfer statuses (pending/submitted/settled/returned/canceled/rejected), which is useful context beyond the tool name.

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 communicates the action, resource, lookup key, and relevant statuses. Every element earns its place with no filler.

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

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

For a simple get-by-ID tool with one parameter and no output schema, the description covers the essential invocation context. The status list enriches the expected result context, though it does not specify the full return structure or error behavior, which would be useful but not critical.

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

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

Schema description coverage is 0%, so the description must compensate. It only says 'by ID', which adds little meaning beyond the parameter name ach_transfer_id. It does not describe the ID format, where to find it, or any constraints on the value.

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

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

The description uses a specific verb ('Get') and resource ('one outbound ACH transfer by ID'), immediately distinguishing it from siblings like lemma_get_inbound_ach_transfer. The status list adds further precision about what the tool handles.

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 'by ID' implies this tool is for fetching a single transfer when an ID is known, and the 'outbound' qualifier distinguishes it from inbound-transfer siblings. However, there is no explicit guidance about when to prefer this over related tools such as lemma_get_transaction or lemma_list_inbound_ach_transfers.

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 disclosure burden. It adds useful behavioral context by naming the returned fields and confirming it is a single-account read, but it does not mention error behavior, authorization requirements, or whether balances are 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?

The description is a single efficient sentence with the operation, scope, and key returned data front-loaded. There is no filler or redundant phrasing.

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 simple one-parameter read tool with no output schema, the description covers the action and the main return data. It does not explicitly state the role of account_id or describe not-found behavior, but the tool's simplicity makes the definition mostly complete.

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

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

Schema description coverage is 0% and the description does not explain the account_id parameter at all. The meaning is inferable from the tool name, but the description adds no explicit semantics about what identifies the bank account or how to obtain the ID.

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: 'Get one bank account', and lists the returned fields (name, account/routing number, balances). This clearly differentiates it from sibling tools like lemma_list_bank_accounts and lemma_get_external_account.

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 a single-record fetch by ID rather than a list operation, but it never explicitly says when to use this tool over lemma_list_bank_accounts or other getters. There is no mention of alternatives or exclusion conditions.

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?

There are no annotations, so the description carries the burden of conveying behavior; 'Get' and 'by ID' communicate a read-only, single-record lookup with no side effects. It does not disclose not-found behavior, authorization needs, or return shape.

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, front-loaded sentence contains only essential information: action, resource, cardinality, and lookup key. There is no filler or redundancy.

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

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

For a one-parameter getter with no output schema, the description communicates the core call shape completely: provide a book transfer ID and receive that transfer. Minor gaps such as error behavior and exact return fields are secondary at this complexity.

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

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

Schema description coverage is 0%, but the single parameter is self-descriptive and the description reinforces that it is the identifier for the lookup. It adds little beyond the schema's required book_transfer_id property, though the low parameter count limits the risk.

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 ('Get'), a specific resource ('internal book transfer'), and a retrieval scope ('by ID'). This distinguishes it from sibling tools like lemma_get_transaction and lemma_get_inbound_ach_transfer, which target different resources.

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 'by ID' implies the tool should be used when the agent already has a book_transfer_id and needs a single record. However, it gives no explicit guidance about when to prefer this over related getters or when not to use it.

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 full burden. 'Get' and the listed return fields make clear this is a read operation returning a detailed snapshot of card data. It could add error behavior or permission expectations, but the described behavior is transparent and not misleading.

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 conveys the operation, resource, identifier, and the important returned fields. There is no unnecessary repetition of schema details or filler.

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

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

For a simple one-parameter getter with no output schema, the description gives a fairly complete picture of what will be returned. It would be stronger with explicit usage boundaries relative to sibling tools, but the core invocation context is sufficient.

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 compensate. It confirms that card_id is the identifier of the card to fetch ('by ID'), which adds some meaning beyond the bare string schema. Still, it does not specify the ID format, source, or expected example value, so compensation is only partial.

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

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

The description uses a specific verb ('Get') and a specific resource ('issued virtual debit card by ID'), then enumerates the returned attributes: nickname, last 4, status, authorization controls, and spending limit. This clearly distinguishes it from sibling tools like lemma_get_card_iframe, lemma_create_card, and lemma_delete_card.

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 obvious use case: retrieve a card's details by its card_id. However, it does not explicitly state when to prefer this over sibling tools or when not to use it, such as when the card iframe or card lifecycle operations are needed.

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 provided, the description carries the full burden and does so well. It discloses that the URL is short-lived, exposes real card credentials, and carries a security warning about not logging or storing it. This is exactly the kind of behavioral context an agent needs.

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 concise sentence with the sensitive warning front-loaded. Every clause adds operational value: what the tool returns, its sensitivity, its expiration, and handling instructions. No wasted words.

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 simple one-parameter tool with no output schema, the description covers the essential context: purpose, return value, sensitivity, expiration, and usage restrictions. Nothing necessary for a cautious agent 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 compensate for documenting the card_id parameter, but it does not. The parameter name is self-descriptive, but no additional meaning, format, or relationship to the card is provided.

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

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

The description clearly states the tool retrieves a short-lived iframe URL that renders the card's full PAN/CVV. It is specific about the resource and purpose, but it does not explicitly differentiate itself from sibling tools such as lemma_get_card, so it falls just 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?

The description provides explicit conditional usage: 'only fetch it when the user explicitly needs to view card details' and adds a strong 'never log or store it' caution. It gives clear context for when to use the tool, though it does not name alternative sibling tools.

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 of behavioral transparency. The verb 'Get' makes clear this is a read operation, but the description does not address not-found behavior, permissions, or whether cached or current data is returned.

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, short, front-loaded sentence with no filler. Every word contributes to identifying the operation and the target resource.

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

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

For a one-parameter fetch operation, the core call context is present and sufficient for tool selection. However, with no annotations or output schema, return shape, error cases, and edge behavior remain implicit, leaving the description adequate but not fully complete.

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

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

The schema has 0% description coverage and only defines check_deposit_id as a string. The phrase 'by ID' ties that parameter to the lookup key, but adds no format, origin, or validation details; this is minimally acceptable for a single self-descriptive 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?

The description uses a specific verb ('Get'), names the resource ('check deposit'), and specifies the scope ('one ... by ID'). This clearly differentiates it from sibling tool lemma_list_check_deposits, which would be used for retrieving multiple check deposits.

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 wording implies the tool is for retrieving a specific check deposit when its ID is already known. It does not explicitly mention alternatives or state when not to use this tool, so the usage guidance is only implied rather than explicit.

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 of behavioral disclosure. It hints at the returned fields but does not state failure behavior (e.g., 404/null on missing entity), auth requirements, or any side effects. For a read operation this is a notable 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?

One compact sentence with no filler. The core behavior is front-loaded, and the parenthetical field list is relevant without being 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 single-param, simple lookup tool, the description is minimally adequate. However, there is no output schema or annotations, and the description does not mention error cases or return shape, so an agent cannot fully anticipate edge 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 100% and the only parameter is documented in the schema. The tool description adds no additional meaning about the entity_id format, source, or constraints beyond what the schema already provides, so a baseline 3 is appropriate.

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

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

States a specific verb ('Get'), a resource ('entity'), and the key qualifier ('by ID'), plus field hints (name, legal structure, NPI, address). It clearly identifies what the tool does and is distinct from sibling list/get tools, though it doesn't explicitly name any sibling it is not.

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 guidance on when to use this tool versus alternatives. 'By ID' implies you should call it when you already have an entity_id, but there is no explicit when/when-not or mention of sibling tools like lemma_list_entities for discovery.

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 burden of signaling behavior. The verb 'Get' clearly indicates a read-only operation, and the parenthetical adds useful domain context. However, it does not mention response shape, null/absence behavior, permissions, or side effects.

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 sentence that leads with the verb and resource, and the parenthetical explains the domain term without added fluff. Every part earns its place.

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

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

For a simple one-parameter read-only getter, the description sufficiently conveys what is returned and for whom. Minor gaps such as null handling or the exact address field format are not disclosed, but the tool's low complexity makes the description largely complete.

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

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

The schema has 0% description coverage, so the description must compensate for the sole entity_id parameter. The phrase 'entity's' implies that entity_id identifies the entity whose lockbox is being fetched, but no format, source, or additional parameter semantics are provided.

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

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

The description uses a specific verb ('Get') and a specific resource ('entity's lockbox mailing address'), and the parenthetical ('where payers send checks/EOBs') clarifies what a lockbox is. This clearly distinguishes it from siblings like lemma_get_entity and lemma_list_entity_mail.

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

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

The intended use case is implied: call this when you need the address where payers send checks/EOBs for an entity. However, it does not explicitly state when not to use it or compare it with alternative sibling tools.

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 provided, the description carries the behavioral disclosure burden. It communicates that the tool is read-only by using 'Get' and indicates what data is returned, but it does not describe not-found behavior, authentication requirements, or any peculiarities of the response. For a simple getter this is adequate but not rich.

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

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

The description is a single, front-loaded sentence that states the action, target, identifier, and representative return fields without any filler. Every word contributes to the agent's understanding.

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

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

For a one-parameter getter with no output schema, the description covers the resource, the lookup key, and expected response fields. It is nearly complete, though it could briefly note the relationship to list_external_accounts or clarify that only one record will be returned.

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

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

Schema description coverage is 0%, so the description must compensate. It adds that the ID identifies a saved recipient, but provides no format, source, or elaboration beyond the parameter name external_account_id, which is already fairly self-explanatory.

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 specifies a clear verb ('Get'), resource ('one saved recipient'), and access method ('by ID'), and lists the key returned fields. It is clearly distinguishable from the sibling list_external_accounts tool, which would be the plural/batch alternative.

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

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

The phrase 'one saved recipient by ID' implies this tool is for single-record retrieval when an external_account_id is available. It does not explicitly name list_external_accounts as the alternative for fetching all recipients, but the singular/plural contrast provides clear context.

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. The verb 'Get' signals a safe, read-only retrieval, and 'by ID' clarifies the lookup mechanism. However, it does not disclose error behavior, authorization needs, or whether the ID is platform-specific vs external.

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. Every word adds meaning: action, resource, cardinality, and lookup key. There is no filler, repetition, or unnecessary 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?

This is a one-parameter, low-complexity read tool with no output schema or nested objects. The description states the operation and the required input clearly. Minor gaps like explicit not-found behavior or routing to the list sibling are not critical at this level of complexity.

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 schema provides only the parameter name and type, and schema description coverage is 0%. The description adds the key semantic that the ID identifies a single inbound ACH transfer. It does not provide format or source guidance, but the parameter is self-descriptive enough for basic use.

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 action ('Get'), a specific resource ('inbound ACH transfer'), and the lookup scope ('one... by ID'). This clearly distinguishes it from sibling tools like lemma_list_inbound_ach_transfers and lemma_get_ach_transfer.

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 wording clearly implies this is the single-record lookup tool: use it when you have an inbound ACH transfer ID. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

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

Describes the key behaviors beyond schema: save_to writes to an absolute path, and small files are returned base64-inline. With no annotations, this is useful, though the notion of 'small' and the exact behavior for large files without save_to remain undefined.

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 front-load the core action and then add only the parameter behaviors that matter. No filler or restatement of the schema.

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 two-parameter download tool, the description covers input and primary output paths, but the small-file/large-file ambiguity and lack of an output schema leave a small but real gap. An agent could still call it correctly in the common case, but not with full certainty about large-file responses.

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?

Every parameter is given meaning beyond its string schema: file_id is the file identifier from the first sentence, and save_to is described as an absolute path with a conditional write behavior. This fully compensates for the 0% schema description coverage.

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?

Uses the specific verb 'Download' with a file resource addressed by file ID, and the lockbox-mail example anchors it in the domain. This clearly distinguishes it from the sibling get/list endpoints that return structured data rather than a binary 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?

Usage is implied rather than explicit: an agent can infer 'call this when you have a file_id and need the PDF,' and the lockbox example gives one scenario. There is no explicit when-not-to-use or alternative routing, so it falls short of full 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool returns X12 text inline and that the optional save_to parameter can direct output to a file for large ERAs, which goes beyond the 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 tight sentences front-load the action and resource, then add only the essential behavioral caveat about inline vs file output. There is no filler or redundancy.

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

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

For a simple two-parameter read tool with no output schema, the description covers the core behavior and the meaningful option. It could be more explicit about what happens when save_to is used, but it is otherwise complete enough 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 50%, so the description partially compensates by explaining when save_to is useful ('for large ERAs'). However, remittance_id has no schema description and the tool description does not add explicit meaning for it, though the parameter name is fairly self-evident.

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 ('Fetch'), a specific resource (a remittance's 835 ERA), and a concrete format ('raw X12'). This clearly differentiates it from sibling tools like lemma_get_pdf or lemma_get_transaction.

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

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

The description gives no guidance on when to prefer this tool over alternatives, such as lemma_get_pdf, and provides no exclusions or conditions. The only implied context is that raw X12 is the desired format, but no explicit routing information is given.

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 full burden. It usefully discloses the returned fields and the conditional nature of the linked card. However, it says nothing about not-found behavior, authentication needs, or whether the operation is strictly read-only, leaving the safety profile inferred only from the verb 'get'.

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 filler. The core action 'Get one transaction' appears first, and the parenthetical adds useful return-field detail without bloating the 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?

For a low-complexity single-parameter getter with no output schema, the description provides enough return-field detail to set expectations and enough action clarity to call the tool. It falls short of full completeness by not addressing invalid IDs or explicitly routing between this and the list-transactions sibling, but these are minor gaps for this simple tool.

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

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

Schema description coverage is 0%, so the description should compensate by explaining transaction_id. It does not explicitly describe the parameter; the meaning is only inferred from the parameter name and the phrase 'one transaction'. This is minimal compensation for a single required 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?

The description states a specific verb and resource: 'Get one transaction'. It also enumerates key returned fields, which clarifies what the tool does beyond merely repeating its name. The word 'one' distinguishes it from sibling list-style tools like lemma_list_transactions.

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 use when a single transaction is needed, contrasted with listing transactions. However, it never explicitly says when to prefer this over lemma_list_transactions or other getters, nor does it mention any exclusions or prerequisites. Usage context is present but only implicit.

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 provided, the description carries the behavioral disclosure burden. It does disclose a meaningful output trait: balances are in cents and *_dollars fields are annotated. However, it does not mention pagination behavior, ordering, authentication requirements, or whether the list is read-only beyond what the verb 'List' implies.

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

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

The description is a single, front-loaded sentence that immediately identifies the action and resource, then appends a valuable parenthetical about balance representation. There is no wasted wording or repetitive schema content.

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

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

For a simple list tool with full schema coverage, the description is serviceable: it names the required entity scoping and the distinctive balance format. But with no output schema and no annotations, it leaves gaps around pagination, response shape, and how this tool relates to the many sibling account-related tools.

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

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

The input schema covers all parameters with descriptions, so the baseline is 3. The description adds no parameter-level meaning beyond naming the entity relationship, and it does not elaborate on limit or cursor semantics beyond what the schema already provides.

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

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

The description clearly states the action (List), the resource (Lemma bank accounts), and the scope (for an entity). It also adds a useful output detail about balances and units. However, it does not explicitly distinguish this from the closely named sibling lemma_list_external_accounts or lemma_get_bank_account, so it stops short of full differentiation.

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

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

The description gives no guidance on when to choose this tool over alternatives such as lemma_list_external_accounts or lemma_get_bank_account. It only restates the entity constraint from the schema, with no mention of exclusions, pagination usage, or situations where a sibling would be more appropriate.

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 disclosure burden. 'List' conveys a non-mutating read, and the parenthetical hints at output concepts such as status, holds, and MICR payer details. However, pagination/cursor behavior is not disclosed, and the parenthetical could mislead by suggesting filter options that do not exist in the 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 description is one short, front-loaded sentence with a clear verb and resource, and there is no filler. The parenthetical compresses three pieces of information into an ambiguous fragment, reducing structural clarity. It is concise but not as clean or unambiguous as it could be.

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 simple optional-filter list call, the core action and account filter are present, and limit/cursor are described in the schema. There is no output schema, and the description only hints at returned fields without explaining that the result is a page or how to follow the cursor. It is minimally sufficient but leaves response-shape and sibling-selection details to inference.

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 67% because limit and cursor already have descriptions, leaving only account_id undocumented. The description adds that the optional filter is by account, which maps to account_id, but it does not clarify the account_id format or resolve the ambiguity around status/holds/MICR details. This meets the schema baseline but does not exceed it.

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: 'List check deposits', with an optional account filter, which distinguishes it from the singular lemma_get_check_deposit and other list family tools. The parenthetical '(status, holds, MICR payer details)' is ambiguous—it could mean returned fields or additional filters—so the purpose is not perfectly crisp.

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 explicit when-to-use guidance is provided, and no alternative tools are named. The description implies a list use case and an optional account filter, but it does not say when to prefer lemma_get_check_deposit instead or how this list relates to other list endpoints. The agent must infer selection from the tool name and sibling list.

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 provided, the description carries the behavioral disclosure burden. It discloses that results are scoped to API-key access and may contain multiple entities, which is useful context. It does not describe pagination or the return envelope, but the schema's limit/cursor parameters partially cover 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?

Two dense sentences with no filler. The core action and scope are front-loaded, and the second sentence adds high-value usage context about entity discovery and the possibility of multiple entities.

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

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

Given no output schema, the description provides enough context: it names the resource, the access scope, and the fact that IDs collected here feed other tools. It could mention response fields or pagination explicitly, but the schema already documents cursor/limit mechanics and the tool is simple.

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 the baseline is 3; npi, limit, and cursor are all fully documented in the schema. The description adds no parameter-specific details beyond the top-level scope context.

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 the verb 'List' and resource 'legal entities this platform API key has been granted access to', clearly identifying a read-only collection operation. The 'top-level scope' framing distinguishes it from entity-specific sibling tools, though it does not explicitly name an alternative.

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

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

Explains when to call it: as the entry point for discovering the entity/account IDs that most other tools require. It gives clear usage context and warns against assuming a single entity, though it does not name exclusions or specific alternative tools.

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 provided, the description carries the full behavioral disclosure burden. It usefully discloses that checks are included and that amounts are in cents with '*_dollars' annotated, but it does not mention ordering, pagination behavior, or the overall response structure.

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 sentence with no filler. It front-loads the primary action and resource, then adds the most decision-relevant detail about checks and amount units. Every word contributes value.

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

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

For a list operation with well-described parameters, the description covers the essential purpose, scope, and a key part of the return payload (checks and amount formatting). It is somewhat light on response shape since there is no output schema, but the main invocation context is sufficiently clear.

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 80%, so the schema already documents limit, cursor, and date parameters. The description adds meaning mainly for entity_id by tying it to 'received for an entity' and clarifies the output's check amounts, but it does not significantly deepen parameter semantics beyond 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?

The description clearly states the action ('List') and the resource ('lockbox mail received for an entity'), and adds a key output detail about checks. It is specific enough to understand the tool's core function, though it does not explicitly differentiate it from sibling tools like lemma_list_check_deposits.

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

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

The description implies usage for retrieving an entity's lockbox mail and associated checks, which gives clear context. However, it provides no explicit guidance about when to choose this tool over alternatives such as list_check_deposits or list_remittances, and no exclusions are mentioned.

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 burden, and it does disclose the key behavioral fact that this is a read-only enumeration of approved external destinations. It does not discuss pagination or ordering, but 'List' plus the restriction statement is reasonably transparent for this simple 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?

Two short sentences, with the primary action ('List saved recipients') front-loaded and the critical constraint in the second sentence. No filler or repetition.

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 simple list tool with a clear schema, the description is sufficient: it identifies the entity scope, the resource type, and the operational purpose. It does not state how returned accounts map to move_money_externally, but that is not required 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?

The description adds meaning to entity_id by tying it to 'an entity' and explains that results are saved recipients/destinations. The limit and cursor parameters are already well documented in the schema, so the description does not need to repeat them.

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?

Uses a specific verb ('List'), a clear resource ('saved recipients (external bank accounts)'), and an entity scope. The second sentence differentiates it from generic account listing by emphasizing these are the only allowed destinations for external transfers.

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?

Provides clear context: these accounts are the permitted destinations for external transfers, so an agent knows this is the tool to call when gathering external transfer recipients. It does not explicitly name alternatives like get_external_account or list_bank_accounts, so it stops short of full when-not 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 present, so the description carries the behavioral disclosure burden. It clarifies that the resource is inbound ACH transfers pushed or pulled by outside parties and that account filtering is optional. However, it does not mention ordering, status inclusion, pagination behavior, or response shape. The read-only nature is reasonably conveyed by 'List,' but richer behavioral context is absent.

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 filler. The parenthetical adds semantic clarity, and the optional account filter is stated efficiently. Every word contributes to understanding the 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?

For a low-complexity list tool, the description combined with the schema covers the core call semantics: resource, optional account filter, and pagination parameters. There is no output schema, and the description does not state return shape or ordering, but 'List' makes the primary return type predictable. Slight gaps around pagination behavior and response details keep it from a perfect score.

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 schema already documents limit and cursor, and the description adds meaning to the otherwise undocumented account_id by identifying it as an optional filter. It does not add detail for limit or cursor beyond what the schema provides, but that is acceptable given the schema descriptions. Overall the description modestly supplements the schema but does not fully compensate for the account_id 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 description states a specific verb ('List') and a specific resource ('inbound ACH transfers'), and adds clarifying meaning with 'money pushed/pulled by outside parties.' It also notes the optional account filter. However, it does not explicitly differentiate itself from sibling tools such as lemma_list_transactions or lemma_get_inbound_ach_transfer, so it is clear but not fully distinguished from alternatives.

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

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

There is no guidance about when to prefer this tool over the many sibling list/get tools. No when-to-use, when-not-to-use, or alternative selection criteria are provided. The intended usage is only implied by the verb and resource name.

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 provided, the description carries the behavioral burden. It clearly signals a read-only list operation and lists the kind of data returned, which is adequate. However, it does not disclose pagination behavior, default ordering, or whether the 835 availability field is simply a boolean or implies something deeper, so some behavioral context is missing.

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

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

The description is a single compact sentence that leads with the action and resource, then parenthetically lists the useful output fields. There is no redundant or filler content; every element 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?

The tool has 7 parameters and no output schema, and the description provides only a high-level list of returned fields. The schema covers parameter semantics, but the description does not explain pagination flow, result ordering, or how this tool relates to get_remittance_era. It is minimally viable but leaves an agent to infer several operational details.

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

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

Schema description coverage is 86%, so the input schema already explains limit, payer, cursor, updated_since, received_on_or_after, and received_on_or_before. The description adds no parameter-level meaning beyond naming the output fields. The required entity_id is left only as a property name, but that is acceptable given the high schema coverage.

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

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

The description uses a specific verb ('List') and a clear resource ('an entity's insurance remittances'), and it enumerates the returned fields (payer, payment amount, trace number, 835 ERA availability). It is not explicitly contrasted with siblings like lemma_get_remittance_era, but the list-versus-get distinction is apparent from the description.

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 states what the tool does but gives no guidance on when to choose it over related list tools such as lemma_list_check_deposits or lemma_list_transactions, nor does it mention prerequisite context such as needing an entity_id or how to obtain one. Usage must be inferred entirely from the tool name and purpose.

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 provided, the description carries the behavioral disclosure burden. It reveals that results are paginated, that amounts are in cents, and that *_dollars fields are annotated, which is valuable beyond what the schema shows. It does not describe ordering, filtering, or exact response fields, but for a list operation this is reasonably transparent.

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 entire definition is one well-formed sentence with key operational details front-loaded in a parenthetical. Every phrase conveys useful information: resource, scope, pagination, and unit of measure. There is no redundancy or filler.

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

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

The description covers the core facts an agent needs: what is listed, for which resource, that pagination applies, and how amounts are represented. There is no output schema, so a fuller description of return fields or ordering would be beneficial, but the definition is still adequate 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 description coverage is 100%, so every parameter already has a clear meaning in the input schema. The description adds no new parameter-level semantics beyond the overall pagination and amount-format context, matching the baseline expectation.

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

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

The description clearly states a specific verb ('List'), resource ('transactions'), and scope ('for a bank account'). It also adds essential context about pagination and amount formatting, which distinguishes it from sibling get/list tools like lemma_get_transaction and lemma_list_bank_accounts.

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 use when listing all transactions for an account and mentions pagination, but it does not explicitly name alternatives or exclusion conditions. An agent must infer that lemma_get_transaction is for a single transaction; no 'use X instead' guidance is given.

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 full behavioral burden, and it delivers thoroughly: it flags a mutating, irreversible-feeling real-money operation, discloses settlement delay, manual review for large transfers, and per-call human approval. It also warns about invalid destinations being rejected, which is beyond what the schema states.

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 dense, front-loaded sentences convey the risk warning, the core action, the key constraint, settlement timing, review threshold, and approval requirement. There is no filler or repetition of schema content that does not add operational value.

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

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

For a high-stakes write operation with 6 parameters, no annotations, and no output schema, the description covers prerequisites, constraints, side effects, timing, edge-case behavior, and human approval. An agent has enough to decide whether and how to invoke this 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 coverage is 100%, so the baseline is 3, but the description adds real parameter-level meaning: destination must be a saved external account ID from a specific sibling tool, arbitrary bank accounts are rejected, and large amounts trigger manual review. It also reinforces the confirm parameter's requirement for explicit user approval.

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 'WRITE -- MOVES REAL MONEY' and states the exact action: sending an ACH transfer from a Lemma account to a saved recipient. It clearly distinguishes this from internal transfers by specifying 'externally' and from account listing by naming lemma_list_external_accounts as the required source of destination IDs.

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

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

The description gives clear usage context: only saved recipients are allowed, arbitrary bank accounts are rejected, and the destination must be an external_account_id from lemma_list_external_accounts. It also states the approval requirement. It does not explicitly name internal-transfer alternatives, but the external/internal sibling distinction and the saved-recipient exclusion provide strong directional 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly warns that this is a WRITE operation that 'MOVES REAL MONEY', is not reversible by implication, and requires explicit user approval. This is critical and well-stated, though it could also mention effects like potential failure modes or response behavior; the idempotency behavior is covered in the reference parameter description.

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 sentence that front-loads the most important warning ('WRITE -- MOVES REAL MONEY') before explaining the operation and the approval requirement. Every phrase earns its place, with no filler or redundancy.

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

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

For a real-money mutation tool with no output schema and no annotations, the description covers the essential safety context: it is a write, it moves actual money, it is internal to owned accounts, and it requires explicit user approval. The schema richly documents the parameters, including idempotency via reference. Minor missing context includes potential error conditions and what the response looks like, but the core operational and safety information is present.

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 83%, so the schema already documents most parameters well. The description adds overall context about moving funds between owned accounts and requiring approval, but it does not add individual parameter meaning beyond what the schema already provides. This aligns with the baseline 3 for high schema coverage.

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 clear verb and resource: 'WRITE -- MOVES REAL MONEY' followed by 'instant, free book transfer between two Lemma accounts owned by this platform's granted entities.' It clearly identifies the operation as an internal money movement between owned accounts, which distinguishes it from the sibling lemma_move_money_externally without needing to open that tool.

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

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

The description gives strong contextual guidance by specifying that it applies to internal transfers between two Lemma accounts and emphasizing that explicit user approval is required before every call. It does not explicitly name alternatives or exclusions, but the scope and the approval precondition effectively route an agent toward correct use and away from external transfers.

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