Tokenbooks - crypto and fiat accounting and payments

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

Annotations indicate a mutating, non-idempotent operation. The description adds useful behavioral context beyond that: it starts an initial sync and reports which addresses were added or skipped. It makes the side effects and partial outcome visible without contradicting the annotations.

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 sentences, each earning its place: action and outcome first, then the conditional integrationId rule, then exclusions and result reporting. No filler or redundant restatement.

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

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

With no output schema, the description covers the key behavioral outcomes and the critical integrationId conditional. It is slightly thin on what 'first sync' entails and how duplicate or partially invalid addresses are handled, but it is largely sufficient for an add tool with three parameters.

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?

Since schema description coverage is 0%, the description must carry the parameter semantics burden. It explains integrationId well, including the EVM special case, but leaves workspaceRef and portfolioRef essentially unexplained and does not detail address format expectations beyond 'EVM 0x address'.

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

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

The description opens with a specific verb and resource: 'Add one or more blockchain addresses' to a portfolio. It also clarifies scope by saying it does not configure exchange accounts, which helps distinguish it from other operations.

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 concrete routing guidance: omit integrationId for EVM 0x addresses across all EVM networks, and require it for other addresses. It also explicitly calls out an exclusion ('does not configure exchange accounts'), though it does not name a sibling tool as the 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?

Even with destructiveHint=true already present, the description adds real value by clarifying that this is a bulk asynchronous job, that unsaved edits are ignored, and that it returns a requestId for status tracking. It does not go into reversibility or failure modes, but it meaningfully supplements the annotations.

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?

It is a single dense sentence with no filler. The purpose comes first, and every subsequent clause adds important operational detail: destructiveness, unsaved-edit behavior, preview-first advice, and requestId tracing.

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 destructive bulk mutation with no output schema, the description supplies the critical information an agent needs: scope, side effects, preflight expectations, and how to observe the result. Together with the well-covered input schema and annotations, it is sufficiently complete for safe 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?

Both parameters have complete descriptions in the input schema, so the 100% schema coverage baseline of 3 applies. The description does not add additional meaning about workspaceRef or portfolioRef, but that is an accepted trade-off when the schema is already thorough.

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-resource combination: it re-runs current saved rules and counterparty defaults across eligible existing accounting transactions. This clearly separates it from siblings like preview_accounting_rules, edit_accounting_rules, list_accounting_rules, and delete_accounting_rule.

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 gives explicit on-the-job guidance: preview first and then track the returned requestId with get_request_status. It does not explicitly state when not to use it or name a fallback alternative, so it stops just short of the strongest 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?

Annotations already cover readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the bar for the description is lower. The phrase 'this queued action returns a requestId' adds genuinely useful async behavior beyond the annotations. However, it does not explain what 'post to the books' entails (e.g., ledger effects, authorization needs) or how the queued result is retrieved.

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 two tightly coupled clauses, no filler, and the core action is front-loaded. Every word earns its place, and the async-return detail is appended 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?

Given the absence of an output schema, stating that it returns a requestId is helpful, and the annotations cover the safety profile. However, the description lacks workflow context: how a transaction becomes 'proposed', how to poll the returned requestId (e.g., get_request_status), and how this tool differs from update_transaction or reprocess_transaction. This is a minimum-viable description with clear 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?

Schema description coverage is 100%, so the schema fully documents all three parameters. The description's reference to a 'proposed accounting transaction' loosely maps to transactionId but adds no new semantic detail about workspaceRef or portfolioRef beyond what the schema already states, so 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?

The description uses a specific verb-action ('Post'), a clear resource ('a proposed accounting transaction'), and an outcome ('to the books'), which fully clarifies what 'confirm' means. It also distinguishes the tool from preview-style siblings (e.g., preview_transaction_classification) and mutation siblings (e.g., update_transaction) by focusing on posting a queued proposal.

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 or when-not-to-use guidance is provided. With 50+ sibling tools, an agent cannot tell whether to call confirm_transaction versus reprocess_transaction, update_transaction, or preview_transaction_classification, and there is no mention of prerequisites such as a transaction needing to already be in a 'proposed' state.

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

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

Annotations already convey mutating, non-idempotent, open-world behavior, so the description's burden is lower. It adds useful context: Canada/US profiles require matching currency, entity type, and timezone, and omitting jurisdiction triggers generic accounting defaults. However, it does not disclose the success response shape or behavior on failed constraint validation, so transparency 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?

Three sentences front-load the purpose, then list constraints and scope. The advice to 'Search help for policy choices' is slightly vague but not redundant. The description is compact and every sentence earns its place, though it could be tightened.

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?

Covers creation scope, defaults, and jurisdiction-dependent constraints, and points to help for policy options. However, with no output schema, it omits what a successful call returns (e.g., a portfolio reference), and the open-world side effects are not elaborated. For an 11-parameter creation tool, this leaves meaningful 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?

Schema coverage is 91%, which sets a baseline of 3. The description adds cross-parameter meaning beyond the schema by stating that Canada/US profiles require consistent currency, entity type, and timezone, and that omitting jurisdiction selects generic defaults. This helps agents pick coherent parameter combinations, which is valuable.

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: creates an accounting portfolio in an existing workspace. Also draws a clear boundary by noting workspace creation remains in the Tokenbooks UI, distinguishing it from workspace-scoped tools. The action is unambiguous and easily separated from list/get sibling tools.

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?

Clarifies the valid scenario: use when a portfolio is needed inside an already-existing workspace, and explicitly excludes workspace creation as a UI task. It also describes behavior when jurisdiction is omitted, helping agents decide whether to supply jurisdiction-related parameters. No specific sibling tool is named, so it doesn't reach the explicit-alternative tier.

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

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

Annotations already include destructiveHint=true and readOnlyHint=false, so the description's explicit mention of 'destructive rule-removal path' reinforces this. The additional advice to 'preview its impact first' adds useful context beyond annotations, such as the suggestion to check consequences before executing.

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 action and target, and adds a cautionary note. It is concise without redundancies, though it could be even more compact.

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 that this is a destructive operation with no output schema and only three parameters, the description covers the action, target, and a cautionary note. However, it does not clarify the meaning of portfolioRef or workspaceRef, which might be critical for correct invocation. The complexity is low, but the lack of parameter semantics slightly reduces completeness.

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. It mentions ruleRef as the target but does not clarify the role of workspaceRef and portfolioRef beyond being required contexts. This is a gap, but with three parameters all having minLength constraints, the description at least identifies the main identifier.

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 verb 'Remove' and the resource 'saved accounting rule', and specifies the ruleRef identifier. It is distinguishable from siblings like 'edit_accounting_rules' and 'preview_accounting_rules', though it could be more explicit about being the opposite of the create/edit paths.

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 guidance on when to use this tool: when you want to remove a rule from active use. It also advises to preview the impact first when consequences are uncertain, which implies a cautionary note but does not name the preview tool explicitly. Slightly more could be said about 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?

Annotations already indicate readOnlyHint=false (mutation), destructiveHint=false (no deletion), and idempotentHint=false. The description adds value by clarifying that changes are not applied to existing transactions, which is a key behavioral trait. However, it doesn't elaborate on side effects (openWorldHint=true) or any other execution details, so it provides limited additional transparency beyond annotations.

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 efficiently conveys the main actions and scope. It front-loads the purpose and immediately clarifies exclusions, making it easy to scan without 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?

Given the complexity (4 operations, nested condition/action schemas, no output schema, no parameter descriptions), the description is grossly incomplete. It doesn't explain the operation parameter, how to structure rules, or what the response will be. The advisory to preview changes is helpful but insufficient for an agent to correctly construct a call without further documentation.

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 by explaining parameters. It fails to mention workspaceRef, portfolioRef, operation, ruleRef, conditions, action, or orderedRuleRefs. The operation enum values are critical but entirely undocumented in the description. This is a significant gap for a tool with 9 parameters and nested objects.

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 (create, update, enable/disable, reorder) and resource (saved accounting rules). It also distinguishes from siblings by explicitly noting what it does NOT do (delete rules, apply to existing transactions), which helps an agent differentiate it from delete_accounting_rule and apply_accounting_rules.

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 says when not to use this tool: 'without deleting rules or applying them to existing transactions,' which points to using delete_accounting_rule and apply_accounting_rules for those cases. It also advises to 'preview uncertain changes first,' suggesting a workflow step with preview_accounting_rules. This provides clear when and 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?

Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds no further behavioral context beyond the core search action, such as no-match behavior, pagination defaults, or what fields are 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?

A single sentence with no filler. The main action is front-loaded, and the usage context is appended efficiently without 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?

The description is nearly complete for a read-only lookup tool: it states the purpose, the usage context, and the schema documents all parameters. It does not describe the return shape or explicitly separate this tool from list_portfolios, but an agent has enough information to invoke it correctly.

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

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

Schema description coverage is 100%, so parameter semantics are already fully documented. The description only reinforces that query searches by name or slug, which does not add meaning 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 uses a specific verb and resource: 'Search portfolios by name or slug'. It also positions the tool as a prerequisite step for portfolio-scoped tools, which distinguishes it clearly from list_portfolios or get_portfolio.

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 explicitly tells the agent when to use the tool: 'before calling portfolio-scoped tools'. It does not name alternatives or exclusions, such as using list_portfolios for full enumeration, but the guidance is clear enough for correct selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds the sequencing context (call before workspace-scoped tools), but does not describe return shape, matching semantics, or pagination. This is mild added context rather than rich behavioral disclosure.

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: verb and resource first, usage context second. It wastes no words and does not repeat the title or 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, annotation-covered search tool, the description supplies the essential purpose and usage context. The only gap is that, with no output schema, it does not state what the returned matches look like; but the low complexity and clear intent make 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?

The sole parameter 'query' is already fully described in the schema as 'Workspace name or slug search query'. The description's 'by name or slug' restates rather than extends the schema. With 100% schema coverage, the description carries no additional parameter burden.

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

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

The description opens with a specific action ('Search') and a precise resource ('workspaces by name or slug'), then states its role: a pre-step before workspace-scoped tools. It clearly differentiates this tool from a broad list_workspaces enumeration by emphasizing targeted lookup.

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

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

'Before calling workspace-scoped tools' provides explicit timing and context for when to use this tool. It does not name list_workspaces as the alternative for listing all workspaces, so it stops short of a full when/when-not comparison.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false. The description adds valuable behavioral context by specifying exactly what gets destroyed and rebuilt, plus a clear danger warning. It does not contradict the annotations.

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

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

The description is two sentences with no filler. The warning is front-loaded, the action is stated directly, and the alternative is cleanly separated in the second sentence.

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?

Combined with the destructive annotation and fully described schema, the description gives an agent enough information to invoke the tool correctly and avoid misuse. It does not describe post-call results or verification, but that is a minor gap for a destructive resync tool with no output schema.

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

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

Schema description coverage is 100%, and the schema already documents all parameters, including the optional wallets behavior. The description does not add parameter-level detail, but it doesn't need to given the complete schema coverage, so the 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?

The description names a specific destructive operation ('delete and rebuild... from source data') and identifies the affected resources (wallet transaction, journal, and cost-basis history). It also explicitly distinguishes itself from incremental_sync, making sibling differentiation 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?

It explicitly states the only acceptable condition for use ('only after the user explicitly requests this destructive reset and accepts the consequences') and names the alternative for routine cases ('use incremental_sync for routine new activity'). This is strong when-to-use and when-not-to-use 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?

Annotations already indicate read-only, non-destructive behavior, so the bar is lower. The description adds useful behavioral context by naming the categories of values returned and advising use of exact values. It doesn't describe response format or edge cases, but for a zero-parameter lookup this is sufficient.

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 conveys purpose, scope, and usage guidance with no filler. Every clause 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 zero-parameter, non-destructive reference lookup, the description gives enough context to know when to use it and what it returns. It could mention output shape or possible empty/unavailable values, but this is a minor gap given the tool's simplicity.

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

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

There are no parameters, so the baseline is 4. The description fully covers the semantic space by listing what kind of values can be looked up, leaving no parameter ambiguity since none exist.

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 ('look up') with a clear resource ('valid accounting values') and concrete examples of what those values include. It is clear, though it does not explicitly distinguish itself from sibling lookup tools like get_filter_options.

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

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

The description provides clear usage context: call this before classifying or filtering and use the returned exact values instead of guessing. It does not mention alternative tools or exclusions, but the intended timing is 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?

The annotations already carry the safety profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value beyond those by clarifying scope (wallet holdings, not all ledger accounts) and naming the expected output fields: quantity, cost basis, market value, unrealized gain/loss, and portfolio totals.

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 carry all the essential information with no filler. The first sentence states the action and output contents, and the second narrows the scope and points to an alternative.

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, read-only query with three fully described parameters, the description covers both the included scope and the excluded accounting scope. It also enumerates the returned dimensions, which is especially valuable given that no output schema is provided.

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 each parameter already has practical semantics, e.g., 'exact name or slug' and 'asset symbol or canonical asset id'. The description confirms the asset is a cryptocurrency/token but does not need to add much beyond the schema, so the baseline score 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?

The description states a specific action: 'Summarize one cryptocurrency or token across every wallet' with a clear resource and result. It also draws a boundary against ledger/accounting reporting, helping the agent differentiate this from related sibling tools.

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

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

It clearly frames when the tool is appropriate for wallet-level holdings and gives an explicit exclusion for balance-sheet/accounting needs. It could be stronger by naming the exact sibling alternative, but the routing direction is still clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the behavioral context that this is a pre-query enumeration step ('before building a filtered query'), which is useful. However, it doesn't disclose pagination behavior, clamping of pageSize, or the fact that some filter providers require mode. With annotations covering safety, a 3 is appropriate.

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 core action ('List the available values') and gives concrete examples of filter types. It's efficient and readable. It could arguably be slightly more explicit about the mode requirement, but as a description it earns its place without bloat.

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 read-only enumeration tool with rich schema annotations and 78% parameter coverage, the description is mostly adequate. However, it doesn't mention that some filter providers (portfolio-transaction-addresses) require the mode parameter, nor does it clarify the relationship between filterName values and the oneOf schema variants. An agent might not know that mode is mandatory for address filters without opening the schema. The output schema is absent, so return-value expectations are also left unspecified.

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 78%, so the schema already documents most parameters well, including mode's from/to semantics, search's case-insensitive behavior, and selected's hydration purpose. The description adds the high-level context that filterName selects among accounts, wallets, assets, etc., but doesn't add meaning beyond what the schema's enum and per-parameter descriptions provide. Baseline 3 is correct.

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 resource ('available values for one portfolio filter'), and names example filter types (accounts, wallets, assets, transaction status, warnings). It clearly conveys that this is a read-only enumeration tool for filter options. It doesn't explicitly differentiate from sibling list tools like list_wallets or list_counterparties, but the 'before building a filtered query' context and the filterName parameter make the purpose distinct enough.

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 context ('before building a filtered query') and the schema's oneOf variants show which filterName values require mode. However, the description itself doesn't explicitly state when to use this tool versus alternatives like list_wallets or list_counterparties, nor does it mention that mode is required for address filters. The schema carries most of the usage guidance, but the description provides only implied 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?

Annotations already establish readOnly, idempotent, and non-destructive behavior, so the description doesn't need to restate safety. It adds a meaningful behavioral trait: it traces each line to cost-basis records and blockchain movements, clarifying the depth of data returned beyond a plain journal-entry fetch.

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 a front-loaded verb and no wasted words. The em-dashed parenthetical adds useful domain context, and every clause contributes to the object, scope, or output behavior.

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 read operation with full parameter coverage, the description plus schema is sufficient to invoke it correctly. It clearly states what will be returned—debit/credit lines and traced records—though it does not discuss pagination or the potential size of the traced result set.

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?

All three parameters have 100% schema description coverage, so the baseline is a 3. The description does not add parameter-level detail, but it doesn't need to because the schema already documents workspaceRef, portfolioRef, and journalEntryId clearly.

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

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

The description names a specific resource (a journal entry), a precise action (read), and a concrete scope (every debit/credit line plus traced cost-basis and blockchain records). It clearly distinguishes itself from sibling get_* tools in substance, 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?

There is no explicit statement about when to use this tool vs. alternatives like get_lot_ledger or get_accounting_reference. The wording implies it is for retrieving a full journal entry with its traced records, but it lacks direct when-to-use or when-not-to-use 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the pagination trait but provides no detail on default ordering, response shape, or other behavioral nuances, which is acceptable but not enriched beyond the annotations.

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 states the action, resource, scope, and filtering options with no wasted words. It is appropriately sized for a 13-parameter tool whose schema carries the detailed weight.

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 read-only listing tool, the description gives a clear high-level contract, and the schema fully documents all parameters and required references. It is slightly incomplete only because there is no output schema and the description does not hint at the returned row shape or default sort order.

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

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

Schema coverage is 100%, and every parameter has a detailed description, including the AIP-160 filter grammar, deprecated aliases, and cross-parameter requirements. The description's high-level summary of filter categories adds no meaning beyond the schema, so the baseline 3 applies.

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

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

The description names a specific resource ('cost-basis acquisition, disposal, transfer, and adjustment history') and an action ('Trace'), scoped across a portfolio with optional narrowing by asset, wallet, event kind, accounting transaction, or date. This clearly distinguishes it from sibling transaction and journal tools without needing to inspect the schema.

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

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

The description implies the tool is for retrieving lot-ledger history, but it never states when to prefer it over siblings like get_portfolio_transaction, list_portfolio_transactions, or get_asset_position, nor does it give exclusions. The optional filters give context, but routing decisions are left to inference.

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

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

The read-only, idempotent, and non-destructive traits are already provided by annotations, so the description's added value is the exact-match requirement and the legalEntityType-is-unset nuance. This is meaningful behavioral context beyond the structured annotations, with no contradiction.

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

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

The description is two sentences with no filler: the first states the operation and inputs, the second records a useful edge case. It is front-loaded and every sentence 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 read tool with two fully documented parameters, rich annotations, and an output schema, this description provides the necessary selection criteria (single portfolio, exact identifier, settings/accounting policy) and a valuable unset-value detail. Nothing needed 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 coverage is 100%, and both required parameters already carry 'exact name or slug' descriptions. The description mostly restates that matching mode and adds no new per-parameter constraints or formats, so the schema carries the semantic weight.

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

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

The description opens with a specific verb ('Read') and a clearly scoped resource ('one portfolio's settings and accounting policy'), then specifies the identifier type ('exact name or slug') and the included fields. This distinguishes it from list/balance/find siblings even without naming them, because it targets a single portfolio's administrative data.

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

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

It clearly communicates the tool is for reading one portfolio's settings when an exact name or slug is known, which implicitly separates it from list/find tools. However, it does not explicitly name alternatives or state when not to use it, such as when balances 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?

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. On top of that, the description adds meaningful behavioral detail by enumerating the return content (per-wallet match status, token count, last transaction time, overall match flag) and clarifying that the tool performs a comparison rather than a mutation. No contradiction with annotations; the added disclosure is genuinely informative.

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, dense sentence with no filler: the purpose clause is front-loaded and the return items trail in a compact list. Every phrase earns its place. It could be split for readability but is efficient and well-ordered as written.

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

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

With no output schema, the description correctly shoulders the duty of disclosing return values and does so (match status, token count, last transaction time, overall flag). For a simple two-parameter read-only lookup with strong annotations, nothing critical is missing. Minor gaps — the precise meaning of a 'match' failure or behavior when no snapshot exists — are edge cases an agent can discover by calling the 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 100% — both workspaceRef and portfolioRef are documented as 'exact name or slug' in the schema. The description adds no additional parameter semantics beyond what the schema already provides. Per the high-coverage baseline, a 3 is appropriate since the schema carries the full burden and the description does not need to compensate.

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 action ('check whether computed token balances match the latest synchronized snapshot') with a clear resource (per-wallet balances within a portfolio). The verification/consistency framing distinguishes it from sibling get tools like get_asset_position, get_wallet, and get_portfolio, which fetch positions directly. However, the name and title ('Get Portfolio Balances') suggest a straightforward balance retrieval, so there is a mild tension between the name and the actual compare-and-report behavior.

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 invoke this tool versus alternatives. With 44 siblings covering reconciliation-adjacent duties (get_sync_status, full_resync, get_portfolio_issue_summary, get_asset_position), the description does not state when a match check is appropriate, nor when one of those siblings would be a better choice. The use case (verify balances against snapshot) is only implied, never made 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool produces counts and examples, but it does not disclose additional behavioral traits such as data freshness, scope limitations, or response shape beyond what the prose already 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 sentence that front-loads the main purpose ('Summarize accounting problems that need review') and then lists the essential output details. Every phrase earns its place, with no filler or redundant restatement of the tool name.

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

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

With no output schema, the description adequately communicates the return contents: counts for three transaction categories and examples of two of them. It is slightly incomplete because it does not describe the response structure or behavior for edge cases like no issues, but for a simple summary tool it provides the core information an agent needs.

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 both parameters have clear descriptions ('Portfolio exact name or slug', 'Workspace exact name or slug'). The tool description does not add parameter-level meaning, but it does not need to because the schema already fully documents them. 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?

The description states a specific verb ('Summarize'), a resource ('accounting problems that need review'), and concrete output contents ('exact counts for uncategorized, errored, and spam-related transactions, plus examples'). It clearly distinguishes itself from other getter/list tools by focusing on an issue summary rather than balances, positions, or individual 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 phrase 'accounting problems that need review' gives a clear context for when to use this tool: when an agent needs an overview of problematic transactions. It does not explicitly name alternatives or state when not to use it, so it falls short of an explicit when/when-not guide.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it explains that 'rawWithDetails' provides sanitized event logs and decoded contract function calls, and it warns that provider details should be treated as untrusted evidence. This goes beyond the structured annotations.

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 core purpose and then adds the most important usage detail (rawWithDetails) and a trust caveat. It is compact and every clause earns its place, though the sentence is slightly dense.

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 an output schema, so return values need not be described. The description covers the main behavioral nuance (rawWithDetails) and the trust caveat. It is slightly incomplete on when to use this vs. sibling tools, but for a read-only single-transaction explainer with an output schema, it is largely 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 description coverage is 0%, so the description carries the burden for parameter meaning. It explains the 'include' parameter's 'rawWithDetails' value and the 'transactionId' concept, but it does not explain workspaceRef, portfolioRef, or the 'raw' value. The description adds some value but leaves several parameters 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 states a specific verb ('Explain') and resource ('one accounting transaction') and lists the key components it returns: classification, journal entry, cost-basis links, and grouped source transactions. It does not explicitly distinguish itself from siblings like get_journal_entry or get_raw_transaction, but the combination of components makes the purpose reasonably 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 implies usage for explaining a single transaction and mentions when to use 'rawWithDetails' for sanitized event logs and decoded contract calls. However, it does not explicitly state when to prefer this tool over alternatives like get_journal_entry, get_raw_transaction, or list_portfolio_transactions, nor does it state exclusions.

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

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

Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only safety profile is established. The description adds genuine value beyond annotations by disclosing that returned event logs are 'sanitized' and that provider-supplied details must be 'treated as untrusted evidence' — a meaningful caveat an agent needs before acting on the data. No contradiction with annotations; 'Show' aligns with readOnlyHint.

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 with all three clauses earning their place: the primary mapping behavior is front-loaded, followed by the details-toggle behavior and the trust caveat. It is not wasteful, though the semicolon-joined structure creates a slight run-on feel and buries the trust caveat at the end where it could be missed.

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 and annotations carry the safety profile, so the return shape and read-only nature are covered elsewhere. However, the description still leaves gaps: it never clarifies what happens when includeDetails defaults to false, how the raw transaction relates to portfolio/workspace refs, or what the 'mapping' view actually contains. It is adequate but not complete for a 4-parameter tool with zero parameter documentation in the schema.

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

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

Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It only marginally hints at includeDetails via 'request details for sanitized blockchain event logs and decoded contract function calls,' and never explains workspaceRef, portfolioRef, or rawTransactionId beyond their self-evident names. No format, scope, or relationship details between parameters are given, leaving the agent to guess how the refs constrain the lookup.

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-resource pair ('Show how one source transaction maps to wallet movements and accounting transactions') and distinguishes the tool's scope from accounting-level siblings like get_journal_entry or get_lot_ledger by centering on raw blockchain data. However, the purpose is somewhat blended — the name implies simple retrieval ('Get Raw Transaction') while the description leads with a lineage/mapping view and then pivots to detail requests, which slightly muddles what the primary deliverable is.

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 tool versus alternatives such as list_raw_transactions, get_portfolio_transaction, or get_journal_entry. No when-not-to-use conditions, prerequisites, or sibling comparisons are provided. The only implicit signal is the name plus the mapping language, which does not tell an agent which of the 46 sibling tools to prefer in a given situation.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the specific status set and report-scope constraint, but does not describe return details or error behavior; with annotations in place, this is acceptable but not exceptional.

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

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

A single sentence that front-loads the tool's purpose and statuses, then immediately routes to the right sibling. 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 read-only status-check tool, the description covers what it returns (statuses), where the requestId comes from, and how to route other background-job checks. It does not describe the exact response shape, but there is no output schema and the states are enumerated, making this adequate.

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 schema already documents every parameter. The description adds a useful hint that requestId comes from request_report_export, but it does not add meaning for the other parameters beyond what the schema 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 states a specific verb and resource: checking whether report generation is queued, running, failed, or completed. It also names the source of the requestId (request_report_export), which clearly distinguishes it from the sibling get_request_status.

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 explicitly says to use this tool for report-generation status checks and to use get_request_status for any other background job. This gives the agent a clear decision rule and names the alternative tool directly.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful scoping about which kinds of async work are supported, which goes slightly beyond the annotations, but it does not discuss response format, possible statuses, or other runtime behavior.

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 efficient sentence that front-loads the action and scope, then adds the key alternative. There is no redundant or filler 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 read-only status tool, the description plus the fully documented schema gives the agent what it needs to invoke correctly. It lacks an explicit description of the returned status payload, but the core use case and disambiguation from get_report_request_status are covered.

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 schema already explains requestId, workspaceRef, portfolioRef, and transactionId. The description adds no parameter-level meaning beyond mentioning requestId in the prose, so the baseline of 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?

The description names a specific verb and resource: checking the status of background wallet syncs, rule applications, or transaction changes via requestId. It also explicitly distinguishes itself from the sibling get_report_request_status, so an agent can tell them apart without inspecting schemas.

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

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

It clearly states when to use the tool (to check status via requestId) and provides an explicit alternative for report exports (get_report_request_status). This gives the agent direct routing guidance rather than leaving it to infer.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds that the tool surfaces the server endpoint and supported authentication methods—useful behavioral context beyond the annotations, with no contradiction.

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 resource, and the usage context with no 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?

For a no-parameter, read-only, idempotent server-info probe, the description fully covers what the tool returns (endpoint, auth methods) and when to call it. The rich annotations handle safety, and no output schema is needed given the simple informational return.

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 0 parameters, so the baseline is 4. No parameter explanation is needed or possible; the input schema is empty and schema description coverage is 100%.

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 ('Check') and resource ('MCP server endpoint and supported authentication methods'). Clearly distinguishes this from the many portfolio/wallet/accounting sibling tools by targeting server-level connection info.

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 explicit usage context: 'when configuring or debugging a connection.' It doesn't name alternatives or exclusions, but no sibling serves a comparable server-info purpose, so the when-to-use is clear enough to route an agent correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar for additional disclosure is lower. The description adds meaningful behavioral context by stating that current activity takes priority over the latest finished result, and that the response includes codes and messages guiding retry or credential reconnection.

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

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

The description is two sentences with no filler. The core purpose is front-loaded, and the behavioral nuance fits compactly in the second sentence. Every clause 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?

With a full output schema, complete parameter schema, and annotations covering safety, the description is largely sufficient. It would be slightly stronger if it named the sibling tools to avoid (e.g., full_resync) or the conditions under which a resync should be triggered, but the current text covers what the tool does and what the response conveys.

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%, with both parameters (workspaceRef and portfolioRef) clearly documented as exact names or slugs. The description adds no further parameter-level meaning, which is acceptable given the schema fully carries the burden.

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'), a specific resource ('sync health across every wallet in a portfolio'), and the scope of the operation. It is immediately distinguishable from sibling tools like full_resync or incremental_sync because it is strictly a read-only status check.

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 clear context for when this tool is appropriate: to inspect sync health across a portfolio's wallets. It does not explicitly name alternatives or state when not to use it, but the read-only framing and the mention of 'retry or reconnect credentials' imply it is the diagnostic step before acting.

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

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

Annotations already declare readOnly=true and idempotent=true, so the safety profile is covered. The description adds useful behavioral nuance beyond annotations: current activity takes priority over the latest finished result, safe codes indicate retry vs. reconnecting credentials, and EVM address normalization differs from other networks.

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 compact and front-loaded with the core purpose, followed by only high-value behavioral caveats and a direct parameter-passing instruction. Every sentence contributes useful information with 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 single-wallet read operation with a full output schema and read-only/idempotent annotations, the description covers purpose, key behavior, and address normalization. The main gap is the absence of tool-selection guidance relative to siblings, but that is already penalized under usage_guidelines.

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 schema already documents all four required parameters. The description adds a small amount of meaning by mapping chainId to 'blockchain network' and reiterating the walletAddress normalization, but it does not substantially enrich 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 uses a specific verb and resource: 'Check one wallet's identity and sync health.' It clearly distinguishes from siblings like list_wallets by scoping to a single wallet, and from get_sync_status by focusing on wallet identity and health rather than a global sync state.

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 use this tool versus alternatives such as list_wallets, get_sync_status, or full_resync. It does mention retrying or reconnecting credentials when interpreting results, but that is response interpretation, not tool-selection 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?

The description adds meaningful behavioral context beyond the annotations: it discloses the two-phase preview/post workflow, the requirement that the source file must remain unchanged for posting, and the need for a preview token and resolutions. Since annotations already signal mutability (readOnlyHint=false), the description's extra context about blocking issues and the token requirement is valuable.

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 dense sentence that front-loads the action and resource, then adds workflow conditions without extraneous detail. Every clause earns its place, making it both compact and 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?

Given the tool's complexity (dual preview/post modes, detailed resolutions schema, output schema present), the description provides the critical workflow glue: preview first, resolve issues, then post with the original file and token. Missing sibling comparisons and some parameter-level detail are the only notable gaps, but the schema and output schema carry much of the remaining context.

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 low at 29%, so the description must compensate, and it partially does by linking 'preview token' and 'resolutions' to the post flow and emphasizing the file must be complete and unchanged. However, the description does not explain individual parameters like portfolioRef, workspaceRef, previewToken, or resolutions semantics; it relies largely on the schema's oneOf structure.

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: 'Preview or post a complete CSV or CSV or XLSX file of balanced manual adjustment journals for one portfolio.' This precisely identifies the tool's function and differentiates it from siblings such as preview_accounting_rules or update_journal_entry_line by focusing on balanced manual adjustment journal imports.

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 explicit workflow guidance: 'Preview first; post only after reviewing every blocking issue, then resend the unchanged source with its preview token and any resolutions.' This clearly instructs the agent on sequencing and conditions for the post action, though it does not name alternative tools or when not to use this tool.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds that it preserves existing history (non-destructive) and that it returns a requestId for tracking, which goes beyond the annotations and clarifies the asynchronous nature.

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

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

A single sentence that efficiently packs purpose, usage, and follow-up action without filler. Every clause earns its place and the key information 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 tool with no output schema, the description sufficiently covers what the agent needs: when to use it, what it does, and how to track completion via requestId. It does not describe edge cases like empty results, but this is not critical for basic 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% – all parameters (wallets, portfolioRef, workspaceRef) have descriptive text. The description adds no additional semantic detail beyond the schema, so a baseline of 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?

The description states a specific verb ('Pull') and resource ('recent blockchain and wallet activity'), and explicitly contrasts with keeping all existing history, which differentiates it from full resync. This is clear and specific.

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?

Explicitly states when to use it ('routine refresh before reports or when new activity is missing') and provides a follow-up action (track requestId with get_request_status). It does not explicitly name alternatives like full_resync, but the context strongly implies the incremental vs. full distinction.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, so the safe, non-mutating behavior is known. The description adds the concrete use case of recovering ruleRef for downstream operations, which is useful context. It doesn't mention pagination or clamping behavior (though limit parameter has description), but given annotations cover the primary behavioral traits, this is acceptable.

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

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

A single sentence that is concise and information-dense. It front-loads the primary action (find) and then lists the key purposes (filter, recover ruleRef). No fluff 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?

Given the tool's complexity (13 parameters, 2 required), the description is sparse but not inadequate. It covers the main use case and output purpose (ruleRef). However, it doesn't explain requirement context (workspaceRef and portfolioRef are required but not mentioned), might benefit from indicating that this is the list counterpart to edit/delete. The presence of an output schema absent means the agent must infer return format, but the description's mention of ruleRef recovery partially addresses this.

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 only 15%, with only limit and pageToken having descriptions. The description itself does not explain any parameter semantics beyond the overall purpose. However, many parameters are self-explanatory (search, enabled, ruleRef, wallets, assetIds, actionTypes, etc.), and the description's mention of filtering covers the gist. It doesn't compensate for the lack of schema descriptions fully, but the parameter names are intuitive.

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 clear purpose: finding saved accounting rules, filtering them, and retrieving the ruleRef for subsequent operations. It distinguishes from siblings like apply_accounting_rules and preview_accounting_rules by mentioning the ruleRef recovery aspect, but it doesn't explicitly differentiate from similar list tools (e.g., list_ledger_accounts) beyond context.

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 searching and getting ruleRef, but it doesn't provide explicit when-to-use versus alternatives. It doesn't mention that this is the tool to use before edit/delete/preview, though the ruleRef mention hints at that. No exclusions or alternative tool names are given, but the context of 'saved accounting rules' clarifies scope.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful functional context beyond annotations: results are not just raw chains but EVM networks whose shared 0x address is usable with add_wallet, and queries can resolve by name, slug, or numeric network ID.

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 information-dense sentence with no repetition or filler. The lookup purpose is front-loaded and the add_wallet relationship finishes the thought; every clause 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 low-complexity lookup tool with full parameter documentation and strong annotations, the description is nearly complete. It does not spell out default behavior when query is omitted or the exact result fields, but these are minor and unlikely to block correct invocation.

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

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

Schema coverage for both parameters is 100%, so the description does not need to document them. It adds slight nuance ('Tokenbooks chain slug', 'numeric EVM network ID') and ties evmOnly to the add_wallet use case, but this is not a substantial enrichment over 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?

States a concrete lookup action ('Find which blockchains support wallet syncing') with three accepted query forms and identifies the relation to add_wallet. This clearly separates it from other list_* siblings focused on wallets, transactions, or workspaces.

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 tool is a companion/prerequisite to add_wallet, telling the agent that supported EVM networks share a 0x address that can be added. It does not explicitly list exclusions or alternative chain-lookup tools, but no competing 'list chains' sibling exists among the provided 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the context that it returns only the counterparty name and references the address book, which provides some extra value but not substantial behavioral detail. Given the annotation coverage, a 3 is appropriate.

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, information-dense sentence with zero waste. The core action and resource are front-loaded, and the purpose is stated immediately. No redundant 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 list/find tool with 100% schema coverage and comprehensive annotations, the description is sufficient. It explains the tool's purpose and what it returns, and the schema covers pagination and filtering details. The only minor gap is not stating that no search returns all counterparties, but that is implied. No critical information 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 100%, meaning every parameter is already documented. The description mentions 'counterparty name' and 'address book' but does not add syntax or format details beyond what the schema provides (e.g., 'search' already filters by name). The baseline of 3 applies since the schema does the heavy lifting.

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 verb 'Find', the resource 'saved vendor, person, or organization in the address book', and the specific purpose 'get the counterparty name needed to assign it to an accounting entry line'. This distinguishes it from siblings like list_portfolios and list_ledger_accounts, leaving no ambiguity about what the tool does.

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 a concrete usage scenario ('needed to assign it to an accounting entry line'), which implies when to use it. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to select it over other listing 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?

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds that results are limited to 'active' accounts, which is a meaningful filtering behavior not present in the annotations.

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 sentence that front-loads the verb and resource and states the purpose without filler. Every clause 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 read-only lookup with two required reference parameters and one optional search, the description plus schema is sufficient to invoke correctly. It names the key output (accountNumber) even though there is no output schema. Minor gaps like result count or pagination are non-essential for such a basic list 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 covers 100% of parameters with descriptions, so the description need only add marginal value. It does restate that search filters by name or number, matching the schema, but adds no new parameter-level semantics. 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 ('Find') and resource ('active ledger accounts'), and explains the operational outcome: retrieving the accountNumber needed for assignment to an accounting entry line. This clearly separates it from sibling tools like list_accounting_rules, which concern rules rather than 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 the tool should be used when preparing to assign a ledger account to an accounting entry line, since it returns the accountNumber required for that task. It does not name alternative tools or explicit exclusions, but the context is 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context, such as pagination behavior, ordering, or what happens when no portfolios exist. With annotations present, the description could have added value by mentioning these, but it does not.

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 no wasted words. It delivers the core purpose immediately and is appropriately sized for a simple listing 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?

The tool is simple, with full schema coverage and safety annotations, so the description does not need to repeat those. However, it lacks any mention of return format or pagination nuance (though pagination is implied by the schema), and it does not clarify how this differs from find_portfolios. For a straightforward list tool, this is marginally adequate but not 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 100%, so the baseline is 3. The description adds no extra meaning to parameters; it relies entirely on the schema's rich per-field descriptions. Since the schema fully documents page, limit, pageSize, and workspaceRef, this meets the baseline without exceeding 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 clear verb ('list') and resource ('portfolios') with an explicit scope ('in a workspace'). It is not a tautology and is understandable, but it does not differentiate from related tools such as find_portfolios or get_portfolio, which is a slight gap.

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 no guidance on when to choose this tool over alternatives like find_portfolios (which likely supports filtering) or get_portfolio (for a single item). There is no mention of exclusions or preferred scenarios, leaving the agent to infer usage from the name alone.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds a non-obvious behavioral fact beyond those annotations: including source transactions limits each page to 10 records. This is exactly the kind of contextual disclosure that helps an agent anticipate response 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?

Three sentences with no filler: purpose, filter categories, and the page-limit caveat are front-loaded and each sentence earns its place. The structure makes the key behavioral exception immediately visible.

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 30 parameters, a rich output schema, and annotations that clearly mark the operation as read-only/idempotent, the description is sufficiently complete for correct tool selection and basic invocation. It could explicitly mention pagination or pageToken, but those are already documented in the schema, so nothing critical 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 high at 93%, so the schema carries most parameter meaning. The description still adds value by grouping filters conceptually (status, type, errors, spam, wallet, asset) and by clarifying that 'include source transactions' yields compact raw source data and imposes the 10-record page cap. This is meaningful enrichment over 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 names a specific verb and resource ('Find accounting transactions') and clarifies the domain term 'Portfolio Transactions in Tokenbooks,' which distinguishes it from raw-transaction listing siblings. It also signals the detailed-evidence sibling by saying 'then open one for detailed evidence,' so an agent can disambiguate without opening schemas.

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 states the intended use cases ('for review or reconciliation') and gives conditional guidance ('include compact source transactions when needed'). It does not explicitly name alternatives or exclusions, but the review/reconciliation framing and 'open one' instruction provide clear context for when this tool is 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?

Annotations already communicate read-only, idempotent, non-destructive behavior. The description adds useful context by mentioning that results are 'compact source transactions' and include unprocessed or partially linked activity. It does not disclose behavior such as pagination defaults, result ordering, or filtering restrictions, but it does add meaningful scope beyond the annotations.

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 dense sentence with no fluffable padding, and the core purpose is front-loaded. The phrase 'called Raw Transactions in Tokenbooks' is slightly redundant with the title, but it helps establish domain terminology, so the sentence 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?

Given the tool's complexity (13 parameters, required workspaceRef and portfolioRef, multiple filter options), the description alone is not enough to guide correct invocation. The output schema and annotations help, but the low schema description coverage and absence of parameter guidance leave significant gaps for an agent trying to construct a correct call.

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

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

The input schema has 13 parameters with only about 15% described in the schema, and the description provides no guidance for workspaceRef, portfolioRef, date filters, chain filters, or processingState. The only parameter-related signal is the pointer to get_raw_transaction, which does not explain how to use any of this tool's parameters.

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

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

The description names a specific verb and resource ('Find compact source transactions') and clarifies what qualifies as raw transactions ('unprocessed or partially linked activity'). It also points to get_raw_transaction for detail inspection, which helps differentiate the list tool from the detail tool, though it does not explicitly distinguish it from other list tools like list_portfolio_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 phrase 'Find compact source transactions first' suggests this is the entry point for raw transaction exploration, and the explicit pointer to get_raw_transaction gives a follow-up workflow. However, there is no explicit guidance on when to use this tool instead of list_portfolio_transactions or other list alternatives, and no exclusions are stated.

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

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

Annotations already cover readOnly=true, idempotent=true, and destructive=false, so the description's burden is lower. It adds useful domain context by defining 'responsibility centers' and identifying the expected output fields, but it does not describe list-shaped behavior or optional search filtering beyond the schema. No contradiction with the annotations.

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 defines the domain term, identifies the resource, specifies the output fields, and states the downstream purpose. It does not restate annotations or schema details, so every component 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 filtered-list tool with no output schema, this is complete: the agent learns what a responsibility center is, what values are produced, and why they matter. Required parameters and optional search semantics are covered by the schema, and the read-only/idempotent safety profile is covered by annotations.

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 parameters are already well documented in the input schema. The description adds context around 'center name' but no syntax or format details beyond the schema. 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?

The description states a clear verb ('Find...') and resource ('departments, projects, or other reporting groups—called responsibility centers in Tokenbooks', and names the concrete output fields ('type key and center name') needed for the downstream task. This distinguishes it from generic list_* siblings by connecting the tool to assigning a responsibility center to an accounting entry line.

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 explicitly states the intended use case: retrieving the values 'needed to assign one to an accounting entry line.' It does not name alternatives or exclusions, so it lacks the 'when-not-to-use guidance' required for a 5. The when-to-use context is clear enough for an agent to select this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that the tool returns sync status and transaction counts, which is useful behavioral context beyond annotations. However, it doesn't disclose pagination behavior or other operational details, which is acceptable given the strong annotation coverage.

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 that front-loads the core action and scope, then adds the two key return details. There is no wasted words or unnecessary information, making it highly efficient for an agent to parse.

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 strong annotations and full schema coverage, the description is adequately complete. It specifies the scope (in a portfolio) and the content of the response (sync status, transaction counts). It doesn't mention pagination, but that's documented in the schema parameters. The description is sufficient for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so all six parameters (workspaceRef, portfolioRef, page, limit, chainId, pageSize) are well-documented in the schema itself. The description adds no additional parameter-specific meaning, so it doesn't go beyond what the schema provides. 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?

The description states a specific verb (List) with a clear resource (wallets) and scope (in a portfolio). It also adds detail about what's included (sync status and transaction counts), which distinguishes it from get_wallet (single wallet) and add_wallet (creation). This is a precise and unambiguous 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?

The description gives a clear context of use: listing wallets within a portfolio. It doesn't explicitly mention alternatives or exclusions, but the context is distinct enough from sibling tools like get_wallet or add_wallet. An agent can infer when to use this tool, though explicit guidance would strengthen 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the authentication scoping detail but does not disclose return shape, pagination, or ordering. This is adequate given the annotations, but adds only minimal behavioral context.

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 that front-loads the action and resource with no 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?

For a simple one-optional-parameter listing tool with safety annotations, the description is sufficient for an agent to invoke it correctly. It could mention what the response contains since there is no output schema, but the tool's simplicity keeps this from being a material 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?

The input schema already describes the single optional 'query' parameter at 100% coverage. The description adds no additional meaning about how the query filters or matches, so it stays at the baseline for schema-covered parameters.

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

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

The description states a specific verb ('List') and resource ('workspaces') and clarifies scope as those available to the authenticated Tokenbooks user. It is clear but does not differentiate from the sibling tool find_workspaces, 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?

The description gives no indication of when to use this tool versus find_workspaces or other list_* siblings. The phrase 'available to the authenticated user' implies a general listing use case, but there are no explicit exclusions or alternative routing.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false), the description adds materially useful behavior: the operation is queued, it returns a requestId, it defaults to marking spam, and it updates existing records. This helps an agent understand asynchrony and outcome without contradicting the annotations.

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, then states the purpose, and finishes with the queued/requestId behavior. Every clause earns its place, and it is easy to scan.

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 action, purpose, mutation effect, default flag behavior, queued execution, and the requestId return. With a fully described schema and no output schema, the main missing elements are minor (e.g., how to poll the request status), so it is sufficiently complete for an agent 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 description coverage is 100%, so the parameter descriptions already document all six fields. The description only adds the default behavior for isSpam (defaults to marking spam) and otherwise does not need to repeat parameter semantics, matching the baseline for fully covered schemas.

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 a specific verb phrase, 'Mark or unmark a token as spam', and states the exact resource (a token) and the intended effect (excluding unwanted dust or airdrops from accounting and updating records). This clearly identifies the tool's function and distinguishes it from the unrelated sibling tools.

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 a clear use context: marking unwanted dust or airdrops as spam so they are excluded from accounting, or unmarking a token. It does not name alternative tools or explicit when-not conditions, but no sibling appears to offer the same function, so clear contextual guidance is sufficient.

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

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

Annotations already declare destructiveHint=true, and the description reinforces this with 'destructively' while adding valuable behavioral details: the operation is queued and returns a requestId to track, and a preview should be run first. This goes beyond the structured annotations by explaining the async, destructive workflow.

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 dense sentence conveys the core action, the destructive nature, the required preview step, and the async tracking behavior. There is no filler or redundancy; every phrase 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 destructive, async, multi-parameter tool with no output schema, the description covers the essential operational context: what is merged, the need for preview, and the queued requestId to follow. It could be more complete by naming the exact status-tracking tool or by listing when not to use it, but the essentials for correct invocation are 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 100%, so all parameters are already documented. The description adds some semantic framing by linking 'wallet movements' to the operations array, 'target transaction' to transactionId, and 'reclassify' to operationType, but it does not add material detail 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 names a specific action ('combine' and 'reclassify') with a precise resource scope: wallet movements from several accounting transactions into one target transaction. It clearly distinguishes this from sibling tools like split_transactions and update_transaction, so an agent can tell this tool apart without opening the schema.

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

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

The description implies the intended workflow: preview the grouping first, then track the queued requestId, which gives meaningful guidance. However, it does not state when to prefer this over alternatives or name excluded cases, leaving some selection inference to the agent.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds value beyond the annotations by noting that results are compact and that the scan truncation is reported, which is useful behavioral context for an agent.

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 single-sentence description is compact and front-loaded: it names the verb, the resource, the safety guarantee, and a key output trait. Every clause earns its place, and no fluff is present.

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 the large multi-variant input schema and the lack of output schema, the description is too thin to fully orient an agent. It conveys the preview intent but does not explain the operation variants, parameter roles, or the nature of the returned 'compact' report.

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 has 0% description coverage and 10 parameters, but the description adds no meaning for any parameter beyond a general hint about saved rules versus an unsaved change. The agent is left without any prose guidance for operation, conditions, action, ruleRef, maxAffected, or orderedRuleRefs, which is a severe gap for such a complex 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 states a specific verb (preview), resource (accounting rules), and side-effect boundary (without saving or applying). This clearly differentiates it from apply_accounting_rules and edit_accounting_rules, though it does not name them 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?

The phrase 'without saving or applying anything' gives clear context about when to use this tool versus mutation tools. However, it does not explicitly name alternatives or state when not to use the tool, so guidance is clear but not fully 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description's 'without changing data' matches those annotations and adds a small behavioral note about grouping movements into one accounting transaction, but it does not disclose anything substantially new.

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

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

A single sentence that front-loads the core behavior, immediately establishes the non-destructive guarantee, and names the relevant sibling tools. There is no filler or redundant restatement.

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 three fully documented required parameters, a simple input shape, and strong safety annotations, the agent has enough to invoke the tool correctly. The only minor gap is the lack of an output-shape description, but the phrase 'see how... would be classified' gives adequate functional context for a read-only preview.

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 exact-name/slug semantics of workspaceRef and portfolioRef and the structure of operations are already documented. The description only vaguely echoes 'chosen wallet movements' and adds no meaning beyond the schema, so the baseline 3 applies.

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

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

The description names a specific verb ('See how'), a specific resource ('chosen wallet movements'), and the outcome ('classified if grouped into one accounting transaction'). It also distinguishes itself from merge_transactions and split_transactions by explicitly labeling itself as the preview step.

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

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

It explicitly tells the agent when to use the tool: 'use this preview before merge_transactions or split_transactions.' This gives clear context and names the relevant siblings, though it does not spell out when not to use it beyond those cases.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds context about the content ('full instructions and accounting guidance') but does not disclose additional behavioral details beyond annotations, so a 3 is appropriate.

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 waste. It states the action, the resource, and the prerequisite in a compact form. Excellent structure.

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 read tool with one parameter and safety annotations, the description is nearly complete. It lacks explicit return-value details, but given no output schema and the tool's straightforward nature, it provides sufficient context for correct invocation. A 4 is warranted.

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% for the single slug parameter, but the description adds meaningful context by specifying the slug must come from search_help_articles. This goes beyond the schema's simple 'Help article slug' description, enhancing the parameter's semantic meaning.

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 verb 'Open' and the resource 'full instructions and accounting guidance in one help article', and distinguishes it from search_help_articles by specifying it uses the slug returned by that search. It is specific and unambiguous, separating it from sibling tools.

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 instructs to use the slug returned by search_help_articles, establishing a clear prerequisite and workflow. It tells the agent when to use this tool (after obtaining a slug) and implies not to call it without one, effectively differentiating from the search tool.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds useful context beyond that: 'queued job' indicates asynchronous behavior, 'may regroup only its assigned wallet movements' specifies a scope limitation, and 'waitForCompletion can return the final state' explains a return behavior option. No contradiction with annotations.

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, well-structured sentence that front-loads the primary purpose ('Recalculate one accounting transaction') before adding key behavioral notes (destructive, queued, regrouping, waitForCompletion). There is zero fluff and every clause 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?

With no output schema, the description should clarify return behavior. It mentions 'waitForCompletion can return the final state', but does not describe the response when waitForCompletion is false or the overall job result format. For a complex destructive async operation, a bit more about expected return or failure modes would improve completeness.

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

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

Schema description coverage is 100%, so all seven parameters are well-documented in the input schema. The description does not add any parameter-specific meaning beyond what's in the schema (e.g., it mentions waitForCompletion but the schema already describes it). Thus 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?

The description clearly states the action ('Recalculate') and the resource ('one accounting transaction'), plus the context ('after correcting its inputs'). This distinguishes it from siblings like update_transaction (which directly edits) or confirm_transaction (which confirms), making the purpose unambiguous.

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 a clear usage context: the tool is for recalculation after inputs have been corrected. It does not explicitly name alternatives or exclusions, but the condition 'after correcting its inputs' sufficiently guides when to use it. It also warns about the destructive and queued nature, which is relevant usage information.

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

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

Annotations already indicate non-read, non-destructive, non-idempotent behavior. The description adds valuable context by revealing that the tool queues work rather than returning the report immediately, and that the agent must poll a status endpoint via the requestId. It does not mention potential costs or rate limits, but the core async behavior is 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 description is a single, well-structured sentence that front-loads the operation and resource, then appends the follow-up status tool. The report examples are slightly redundant with the schema enums but still aid natural-language understanding without significant bloat.

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 an asynchronous export tool with no output schema, the description covers what is queued, that a requestId is returned, and how to track it. Required parameters are fully documented in the schema, and the missing details such as error handling or cancellation are not essential for invoking the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters and their enums. The description names formats and report types, but these duplicate the schema enums without adding new semantic detail, 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 names a specific verb ('Queue generation') and a concrete resource: accounting reports in spreadsheet, PDF, or JSON formats for a reporting period. The report type examples align with the schema enums, and the mention of requestId tracking clearly separates it from sibling status and list tools.

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 explicitly tells the agent to track the returned requestId via get_report_request_status, giving a clear follow-up path for an asynchronous operation. It does not state when not to use it versus other report/list tools, but the async-queue framing makes the intended context 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: it mentions the topical scope and that the result should be opened with read_help_article, which guides the agent's next step. No contradiction with annotations.

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, well-structured sentence that front-loads the core purpose, includes concrete topic examples, and ends with the follow-up action. Zero wasted words and all information is relevant.

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 search tool with full schema coverage and safety annotations, the description covers everything an agent needs: what to search for, what topics are relevant, and what to do with results. No output schema exists, so return format is not required. The description is complete for its complexity level.

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%, with clear descriptions for both parameters ('Search query' and 'Maximum number of results'). The tool description does not add additional semantics beyond the schema, which is acceptable given the schema's completeness. 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?

The description clearly states the tool's function: 'Find practical Tokenbooks instructions or accounting guidance by topic', with specific examples like MCP workflow, cost basis, fair market value, gas fees, and stablecoins. It also names the follow-up tool (read_help_article), distinguishing it from siblings that focus on other operations.

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 context: use this to search for help content, and explicitly directs the agent to use read_help_article to open a result. However, it does not explicitly state when not to use this tool (e.g., if you already know the article ID), but the intended use case is well implied.

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

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

Annotations already indicate a mutating, non-idempotent operation, but the description adds valuable context: the action is queued, returns a requestId, and recomputes dependent cost-basis records. It does not fully explain terminal-state semantics or status polling, but the main behavioral traits are disclosed beyond what annotations provide.

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 focused sentence that front-loads the action and resource, then states the queued request behavior. Every clause earns its place, and there is no repetition, filler, 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?

For an 11-parameter mutation tool with no output schema, the description provides the essential queued-action and requestId context, and the schema covers the parameters. The main missing piece is explicit guidance on how to consume the requestId, though the waitForCompletion parameter and sibling get_request_status tool partially cover that workflow.

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 schema documents each parameter clearly, including the precise meaning of newValueQuote as an exact per-unit decimal string. The description mainly reinforces 'per unit' without adding new parameter-level semantics, so the baseline score of 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?

The description states a specific verb and resource: set a corrected fair market value per unit for one asset on an accounting transaction, then recompute dependent cost-basis records. This clearly differentiates it from generic transaction update tools and other siblings, while the queued-action note adds a distinct operational trait.

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 or when-not-to-use guidance, and no alternative tool is mentioned. The phrase 'corrected fair market value' implies the tool is for fixing an erroneous FMV, but an agent is left to infer that rather than being told how this differs from related transaction operations.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no new behavioral details beyond the estimation function, which aligns with these hints. It does not disclose anything about rate limits, authentication, or response structure, but this is acceptable given the annotation coverage.

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 that front-loads the primary purpose and lists the key cost components without filler. It communicates the tool's value in one breath, making it easy for an agent to parse quickly.

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 the comprehensive schema (all 8 parameters documented) and annotations covering safety, the description adequately conveys what the tool does and what it returns (estimates of rates, fees, amount, and limits). The absence of an output schema is mitigated by the description's enumeration of the output contents. It could be more explicit about the exact response structure, but nothing critical 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 100% with detailed descriptions for every parameter, so the schema carries the semantic weight. The description adds minor value by giving examples of the network enum (ACH, SEPA, EFT) and tying them to the concept of 'rails', but this is redundant with the schema's 'Fiat payout rail / bank method' 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?

The description states a clear, specific purpose: 'Estimate exchange rates, processing fees, amount received, and corridor limits for a bank payout before sending money.' It names the resource (bank payout quote) and distinguishes it from sibling tools that handle portfolios, transactions, or sync, making its role unambiguous.

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 explicitly advises using the tool 'before sending money' and recommends it for comparing rails like ACH, SEPA, EFT, etc. There are no exclusion criteria or mention of alternative tools, but since no sibling tool provides quote functionality, the guidance is sufficient. A missing 'when not to use' clause prevents 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?

Annotations already state destructiveHint=true and idempotentHint=false, so the description credibly restates destructiveness, but the description adds the queued-request workflow and the 'preview first' safety guardrail, which are not present in annotations. It also conveys asynchronous queued behavior via requestId tracking.

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

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

A single sentence that front-loads the destructive nature, the primary behavior, and the required workflow. Every clause adds information without padding.

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 the destructive annotation and lack of an output schema, the description covers the key operational context: split operation, preview requirement, and asynchronous requestId tracking. It could name the exact status endpoint, but the core workflow is complete enough for a competent 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?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal extra semantic value by connecting 'selected wallet movements' to the operations array and 'new classified transaction' to operationType, but does not need to repeat parameter details.

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 and resource combination: 'move selected wallet movements out of one accounting transaction into a new classified transaction.' It clearly identifies the split action and distinguishes it from siblings like merge_transactions and update_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 instruction to 'preview the grouping first' gives explicit sequencing and suggests using preview_transaction_classification before invoking this tool. The 'then track the queued requestId' also conveys the expected follow-up workflow, though alternative tools are not named explicitly.

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

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

Annotations already declare readOnly=false, openWorld=true, and idempotent=false. The description adds meaningful behavior beyond those annotations: the operation returns requestIds to track, the line number must be read first, and selectable values must come from list tools. It does not cover reversibility or side effects, but the annotations lower the burden and the added context is valuable.

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 actionable instructions and no filler. It is efficient, though it packs three workflow instructions into one long semicolon chain, which slightly reduces scannability.

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 mutating, request-oriented tool with 7 parameters and no output schema, the description covers the key workflow: prerequisites (read the line number first), value sourcing (use matching list tools), and post-call behavior (track requestIds). It leaves permissions and exact return details unstated, but the schema and annotations carry much of that responsibility.

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. The description maps the operation to ledger account, counterparty, and reporting-group fields, but it does not materially add beyond the schema, which already documents each parameter and even explains special values like null to unset and [] to clear.

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 ('Change') and names the exact resource and fields: the ledger account, counterparty, or reporting-group assignments on one accounting transaction's debit or credit line. It clearly narrows scope to a single line, but it does not explicitly differentiate itself from sibling tools such as update_transaction or reprocess_transaction, so it just misses full sibling distinction.

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 an explicit call sequence: read the line number first, look up selectable values with the matching list tools, and track returned requestIds. This is useful context for correct invocation, but it does not state when not to use this tool or when an alternative such as update_transaction would be preferable.

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

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

Annotations already convey mutation (readOnlyHint=false), non-idempotency, and non-destructiveness, so the description's 'Change' adds limited new behavioral signal. It does add useful scope context by saying what it does not affect, but it does not disclose asynchronous behavior, side effects, or consequences beyond the annotation data.

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, zero filler. The primary action is front-loaded, and the second sentence efficiently provides the exclusion and alternative routing. Every clause 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 10-parameter mutation tool, the description gives a clear core purpose and boundaries, while the schema's detailed descriptions cover throttling, polling, and completion behavior. It omits mention of subType and asynchronous completion semantics, but those are adequately handled in the structured schema, so the overall context is strong.

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. The description summarizes memo, tags, and operationType, which helps frame the main editable parameters, but it largely restates information already present in the schema and does not add deep meaning for subType, polling, or timeout parameters.

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

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

The description names a specific verb and resource ('Change one accounting transaction's memo, full tag set, or operation type') and clearly distinguishes the tool from the closest sibling by stating what it does NOT change. An agent can confidently identify this as the tool for editing transaction-level fields without confusing it with update_journal_entry_line.

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 states the exclusions ('does not change ledger accounts, counterparties, or reporting-group assignments') and directly names the alternative tool to use for those cases ('use update_journal_entry_line for those'). This is an explicit when-not/alternative pairing, leaving little ambiguity.

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