Lovie Company Formation

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds minimal behavioral context ('single by ID') beyond what annotations provide. It does not describe error cases, authorization needs, or other edge behaviors, but for a simple read operation 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?

The description is a single sentence of 11 words, fully front-loaded with the essential action and scope. No unnecessary words or repetition. It is appropriately concise.

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 (one parameter, output schema present, annotations cover safety). The description effectively complements the schema and output schema, making the tool's purpose and usage clear. Slight lack of explicit sibling differentiation prevents a 5.

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 100% description coverage for the 'id' parameter ('UUID value wrapper'). The description only restates that the tool uses an ID, adding no new semantic detail. Baseline of 3 applies given the schema fully documents the parameter.

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

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

The description clearly states the tool's function: 'retrieves a single account by ID with its details.' The verb 'retrieves' specifies the action, 'account' is the resource, and 'single by ID' distinguishes it from listing tools like account_get_list_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 usage context ('by ID') but does not explicitly state when to prefer this over sibling tools like account_get_list_accounts. No exclusions or alternatives are mentioned; guidance is implied rather than explicit.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, establishing safety. The description adds the batch behavior and efficiency rationale (eliminates N+1 calls), which is useful context beyond the annotations. 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 a single, front-loaded sentence that captures the core purpose and value proposition. No fluff, 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?

Given the tool has an output schema and simple read semantics, the description is adequately complete for selection and invocation. It covers the batch nature and distinguishes from single-get, though it could slightly improve by referencing pagination or filter usage.

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

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

Schema description coverage is 0% and the description provides no parameter-level guidance. The filter, pageSize, and pageToken semantics are only inferable from the raw schema structure (e.g., maxItems, min/max). The description does not compensate for the low detailed coverage.

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

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

The description clearly states the tool retrieves account details in batch, with the specific benefit of eliminating N+1 GetAccount calls. This distinguishes it from the sibling tool account_get_account and emphasizes its batch capability.

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 frames this as a batch alternative to GetAccount, implying it should be used when fetching multiple account details to avoid N+1 problems. It does not explicitly mention exclusions or compare directly with account_get_list_accounts, but the usage 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 and destructiveHint=false, so the safe-read nature is fully covered. The description adds that the list supports filtering and pagination, which is useful operational context but not extensive. 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?

A single sentence that front-loads the core action and avoids redundant wording. It is concise and to the point, though it sacrifices detail for brevity.

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 complex filter schema and pagination parameters, the description is thin but the schema provides the parameter structure and enums. It lacks guidance on pagination behavior and relationship to sibling tools, but annotations and output schema cover safety and return fields. Adequate but minimal for full comprehension.

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

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

The description mentions filtering and pagination at a high level but does not explain the filter object structure, pageSize, or pageToken. The schema has no top-level descriptions, so the description carries much of the burden for parameter semantics and only partially fulfills 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 clearly states the tool retrieves a list of accounts and highlights filtering and pagination, making the core purpose evident. However, it does not distinguish this from sibling account_get_list_account_details, which likely also lists account information, so explicit differentiation is missing.

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

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

No guidance is provided on when to use this tool versus account_get_account or account_get_list_account_details. The phrase 'list of accounts' implies a listing use case, but there are no explicit alternatives, exclusions, or conditions for use.

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 destructiveHint=true, but the description adds valuable behavioral details: 'Entries already posted for elapsed periods are kept' and 'Audit-logged.' These go beyond the annotation by clarifying what is not destroyed and that the action is recorded. This is consistent with the destructive hint.

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

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

The description is two concise sentences. The first sentence states the primary action and consequence, and the second adds important side effects. Every word earns its place, and the structure is front-loaded with the core purpose.

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 two parameters and an output schema, the description covers the essential behavior and side effects, including what is retained and audit logging. It does not mention prerequisites or reversibility, but the presence of an output schema reduces the need to explain return values. Overall, it is sufficient for a cancellation operation.

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 describes both parameters only as 'UUID value wrapper,' which is minimal but still provides 100% coverage. The description does not elaborate on the parameters, but with full schema coverage, the baseline of 3 applies. No additional semantic value is added by the 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 clearly states 'Cancel an accrual schedule so no further periodic entries are generated.' This specifies the action (cancel), the resource (accrual schedule), and the primary effect (ceasing generation of periodic entries), distinguishing it from sibling tools like accounting_create_schedule and accounting_get_schedule.

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 when an accrual schedule should stop producing future entries, and it provides clear context without explicitly naming alternatives or exclusions. It does not mention when not to use it, such as for deleting already-posted entries, but the purpose is self-evident.

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 discloses extensive behavioral traits beyond the annotations: the window locking, balanced closing entry, equity rollover logic (current-year earnings vs. retained earnings), overlap restriction, rejection of writes, no-op re-closing, multi-currency handling, and audit logging. This adds significant context beyond the idempotentHint and destructiveHint 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 paragraph that front-loads the purpose and then enumerates essential behaviors. Every sentence adds value—covering prerequisites, effects, idempotency, multi-currency nuance, and audit logging—without redundant fluff.

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, idempotent mutation with an output schema, the description covers all key aspects: what the operation does, constraints, side effects, edge cases, and audit behavior. The presence of sibling tools like accounting_reopen_period and accounting_preview_close further contextualizes the tool's role in the lifecycle.

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 (20%), so the description must compensate. It explains the startDate/endDate window and indirectly explains granularity by noting different closing entry behavior for month/quarter vs. fiscal-year closes. However, it does not clarify the basis parameter (accrual/cash) or the companyId wrapper, leaving gaps that the schema alone does not fill.

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

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

The description clearly states the tool's purpose with a specific verb ('Close') and resource ('accounting period'), and elaborates on the exact behavior: locking the date window and posting a closing entry. It naturally distinguishes from siblings like accounting_reopen_period and accounting_preview_close by detailing the closing semantics.

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 to use the tool: periods must not overlap existing closed periods, and after closing, writes are rejected until reopened. However, it does not explicitly mention alternatives (e.g., preview_close for dry-run) or state when not to use this tool, so it stops short of a 5.

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

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

The description goes well beyond the minimal annotations (openWorldHint=false, destructiveHint=false). It discloses exactly how entries are posted (Dr/Cr per period), the straight-line allocation with rounding remainder on the final period, and the impact on cash-basis reports. This is rich behavioral context that materially assists the agent in understanding side effects.

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

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

The description is three sentences, tightly packed with relevant information. It is front-loaded with the core purpose, followed by detailed mechanics and a practical note about cash-basis. Every sentence earns its place; no wasted words.

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

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

Given the tool's complexity and the presence of an output schema, the description is complete. It covers behavior, parameter sourcing, allocation logic, and report impact. It does not need to describe return values since an output schema exists, and it references the appropriate sibling tool for account lookup.

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 44%, so the description needed to compensate. It does well for key parameters: debit/credit account IDs are explained, 'total amount across N monthly periods' clarifies totalAmount and periodCount, and the examples map to the kind enum. However, currencyCode and sourceTransactionId are not mentioned at all, and startDate is only implied by 'monthly periods.'

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 and resource: 'Create an accrual schedule that spreads a total amount across N monthly periods as accrual-only adjusting entries.' It gives concrete examples (amortize prepaid, defer revenue, depreciate asset) and distinguishes itself from sibling tools like accounting_cancel_schedule and accounting_preview_schedule.

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: it explains when this tool is appropriate (accrual-based adjustments) and even directs the agent to pick account IDs from accounting_get_chart_of_accounts. It mentions that cash-basis reports are unaffected, which is a useful exclusion. However, it does not explicitly state to use accounting_preview_schedule for previewing or accounting_cancel_schedule for cancellation.

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 goes far beyond the destructiveHint annotation by detailing exact behaviors: derived entries are recreated on next sync, manual overrides revert to automatic, standalone entries are voided (kept for audit, excluded from reports), and all outcomes are audit-logged. This rich behavioral context is not present in the annotations and adds significant value.

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 concise yet comprehensive, with each sentence adding necessary detail. It is front-loaded with the core action, then breaks down outcomes in a structured, logical order, avoiding redundancy and fluff.

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 destructive nature and multiple behavioral branches, the description covers all essential context: when to use alternatives, what happens for each entry type, and audit implications. With an output schema present and rich annotations, the description is fully complete for an agent to understand the tool's effects.

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

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

The input schema covers 100% of parameters with descriptions, but those descriptions are generic ('UUID value wrapper') and add little semantic value. The tool description does not elaborate on the parameters beyond their names, so it does not improve on schema coverage. Baseline 3 applies due to high schema coverage.

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

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

The description opens with 'Delete or void a journal entry', using a specific verb and resource that clearly distinguishes it from sibling tools like accounting_upsert_journal_entry or accounting_get_journal_entry_by_transaction. It also explains the different deletion semantics (derived vs manual override vs standalone), further clarifying the tool's unique 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 explicitly states 'For entries tied to a transaction prefer re-categorizing the transaction (the entry re-derives)', providing a clear alternative and when to use it instead. It also outlines the consequences for each entry type, giving the agent situational guidance on when deletion 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 declare readOnlyHint=true and destructiveHint=false. The description adds useful context beyond annotations: equity includes net income to date and the sheet always balances, which sets expectations about data behavior. It does not mention currency or basis handling, but annotations reduce the burden.

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, no redundant fluff. Front-loads the core function and includes a key behavioral nuance. Very efficient and well-structured.

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 read-only tool, output schema present, and annotations, the description covers the essential purpose and a key data quirk. It doesn't need to explain return structure. Minor gaps in parameter detail and alternative usage pull it below 5.

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 25% (companyId's wrapper). The description does not explain basis, currencyCode, or asOfDate semantics. It loosely references 'as of a date' but doesn't specify formats, defaults, or how basis affects the report. Since coverage is low, the description fails 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 clearly states the tool returns assets, liabilities, and equity balances as of a date, with the specific note that equity includes net income to date. This distinguishes it from siblings like profit_and_loss or trial_balance by explicitly defining the balance sheet structure.

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 explicit when-to-use or alternative guidance. It implies use for point-in-time balance sheet queries but does not contrast with period-based reports like P&L or trial balance. Clear context but no exclusions or named alternatives.

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 the description reinforces 'Read-only.' It adds valuable behavioral context by revealing the flat list structure with parent links and that tree construction is the client's responsibility. This goes beyond the annotations by disclosing data shape and processing expectations, though it does not mention pagination or default filtering 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 a single, focused sentence that front-loads the core purpose and includes a critical implementation detail. Every word earns its place, with no redundancy or fluff, making it optimally concise.

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 tool with an output schema, the description is mostly sufficient. It conveys the essential output shape (flat list with parent links) and the client-side tree construction need. However, it omits any mention of the includeInactive parameter's behavior, which feels like a minor gap given the tool's simplicity and the presence of an 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 only 50% (companyId has a wrapper description, includeInactive has none), and the tool description does not explain either parameter. The boolean 'includeInactive' is particularly left ambiguous; the description offers no insight into its default or effect. The description adds no value beyond the schema for parameter understanding.

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: 'returns the company's chart of accounts.' It also specifies the output format ('flat list with parent links') and instructs the caller to 'build the tree client-side,' distinguishing it from related tools like balance sheet or general ledger. The verb 'returns' and specific resource make 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 does not provide explicit guidance on when to use this tool versus alternatives. While it implies usage for retrieving a chart of accounts, it does not differentiate from sibling tools like account_get_list_accounts or accounting_get_general_ledger, nor does it state any exclusions or preferred scenarios. There is no 'use X instead' 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=true and destructiveHint=false, so the description's 'Read-only.' is redundant. However, it adds valuable behavioral context beyond annotations: pagination ('pages through'), the restriction to 'posted lines' (excluding unposted entries), and the balance structure (opening, running, closing). This enriches the agent's understanding of what happens when invoking the tool.

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

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

The description is a single, front-loaded sentence with an em-dash clarification, plus a redundant but short 'Read-only.' note. Every word earns its place; it is concise and well-structured.

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 output schema exists and annotations cover the safety profile, the description provides sufficient core context: pagination, single-account scope, posted lines, and balance types. It does not elaborate on parameter usage, but the required parameters are obvious from the schema and the description's focus on 'one account'. This is slightly above 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 only 25% (just 'UUID value wrapper' for companyId and glAccountId), and the description does not compensate. It mentions 'one account' which hints at glAccountId and 'pages through' which relates to pagination parameters, but it does not explain optional parameters like basis, startDate, endDate, or currencyCode. The description adds minimal meaning beyond the schema param names.

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

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

The description uses a specific verb 'pages through' and clearly identifies the resource: one account's posted lines with opening, running, and closing balances. It distinguishes from siblings by emphasizing 'one account' and 'account register', which differentiates it from broader financial reports like balance sheet or trial balance.

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

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

The phrase 'one account's posted lines' gives clear context that this tool is for single-account detail, implying it is not for multi-account or financial statement views. However, it does not explicitly name alternatives or exclusions, so it stops short of a full 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the useful behavioral detail that the result is empty when no journal entry exists yet, which goes beyond the annotations and helps the agent interpret the response.

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 concise sentences with no filler. The first sentence states the purpose and behavior, and the second reinforces read-only nature. Every word earns its place, and it is front-loaded with the key information.

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

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

The tool is simple, has an output schema, full parameter descriptions, and strong annotations. The description covers the key edge case (empty result) and does not need to explain return format due to output schema. It is complete for the tool's complexity.

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

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

Schema description coverage is 100%, with both parameters having descriptions ('UUID value wrapper'). The description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline score of 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 clearly states it returns the journal entry derived for one transaction, using the specific verb 'returns' and resource 'journal entry'. It distinguishes itself from siblings by specifying 'by transaction' and 'for one transaction', which differentiates it from list-oriented journal entry 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 provides clear context that this tool is scoped to a single transaction, implying it is for fetching a single derived journal entry rather than listing multiple. It does not explicitly name alternatives or exclusions, but the 'for one transaction' phrasing gives sufficient guidance for when 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 declare readOnlyHint=true and destructiveHint=false. The description adds that it 'pages through' (pagination) and that the review queue filter is `needs_review: true`, which is useful behavioral context. However, it does not disclose return format, rate limits, or other behavioral traits, and 'Read-only' merely repeats the annotation.

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 very brief and front-loaded with the main action. It wastes little space, though it redundantly starts with the function name 'GetListJournalEntries' and ends with 'Read-only' which duplicates the annotation. Still, it is efficient and readable.

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 output schema exists, return values need not be described. The description covers the core purpose, pagination, and a key filter scenario. It lacks details about other filters and required parameters, but the schema provides that structure. It is adequate for a listing tool with 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 low (25%) with only companyId described. The description does not explain pageSize, pageToken, or most filter fields. It gives one example related to the filter object (`needs_review: true`), but the key name differs from the schema's `needsReview`, adding confusion. Overall, parameter semantics are minimally compensated by the 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 clearly states a specific action: 'pages through the journal register' with filters, identifying the resource (journal entries) and operation (listing/paginating). It distinguishes from siblings like accounting_get_journal_entry_by_transaction and accounting_upsert_journal_entry by focusing on the list/register aspect.

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 guidance on when to use this tool vs alternatives. It does not mention any siblings or exclusions. The only hint is the review queue filter example, which is a use case, but not a comparative guideline.

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 destructiveHint=false, and the description adds 'pages through' (pagination behavior) and 'newest first' (ordering), which are useful behavioral traits not present in the schema. 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, front-loaded sentence that immediately states the action and resource. It is concise with zero filler, earning full marks for 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?

With 4 parameters including nested filter and pagination, plus an output schema, the description is minimal. It fails to address filter semantics, pagination mechanics, or how to use pageToken/pageSize, leaving significant gaps despite the 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 only 25% (only companyId has a description). The description adds minimal context for companyId ('a company's periods') but does not explain the filter, pageSize, or pageToken parameters. Low coverage requires the description to compensate, which it does not.

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 it pages through a company's periods, which is a specific verb+resource, and includes ordering ('newest first') and safety ('Read-only'). This distinguishes it from single-resource tools like accounting_get_period and aligns with its listing 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 implies use when listing periods, but does not explicitly state when to use it over alternatives like accounting_get_period or other list tools. No exclusions or alternative guidance are provided beyond the name and basic phrasing.

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 destructiveHint=false, so the 'Read-only' phrase is redundant. However, 'pages through' reveals pagination behavior and 'a company's schedules' scopes the operation to a single company, adding context beyond annotations. No contradictions.

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 brief and front-loaded with the primary action. The second sentence 'Read-only' is redundant with the annotation, but the overall size is appropriate. It loses one point for unnecessary 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?

Despite having an output schema, the description omits important operational details: the filter parameter is not mentioned, pagination semantics are only implied, and status values are undocumented. Given the low schema coverage, this description is insufficient for an agent to correctly leverage the tool's full capabilities.

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 25% (only companyId has a description). The description doesn't explain filter, pageSize, or pageToken. 'Pages through' hints at pagination but provides no details about parameter usage or filtering by statuses. The description fails to compensate for the low schema coverage.

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

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

The description clearly states the action ('pages through') and the resource ('a company's schedules'), making it obvious this is a paginated listing operation. It distinguishes itself from sibling tools like accounting_get_schedule (singular), accounting_create_schedule, and accounting_cancel_schedule.

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 fetching multiple schedules in a paginated fashion but does not explicitly state when to prefer it over alternatives, nor does it provide exclusions or mention the filter capability. The read-only context is clear from the annotation, but no explicit guidance on when to use this tool vs. others is given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds the 'closed period' and 'by id' behavior, but does not disclose error handling, auth requirements, or the meaning of 'closed.' With strong annotation coverage, this is adequate but not rich.

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

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

The description is two short sentences containing only essential information: the operation and its read-only nature. There is no filler or redundancy, and it is front-loaded.

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

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

For a simple get-by-id tool with an output schema and comprehensive annotations, the description is mostly complete. It identifies the resource, the closed state, and safety. Minor gap: it doesn't clarify that periodId must belong to companyId, but this is not critical for a well-named 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 coverage is 100% since both parameters have descriptions, though those descriptions are only 'UUID value wrapper' and not truly meaningful. The tool description does not elaborate on the parameters. Per the baseline rule for high schema coverage, a 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 ('returns') with a clear resource ('one closed period by id'), and the qualifier 'closed' distinguishes it from the list-periods sibling. This is a precise, non-tautological 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 implies usage for fetching a single closed period when its ID is known, and 'Read-only' gives a safe context. However, it does not explicitly compare against accounting_get_list_periods or mention when not to use this tool, so usage guidance is only 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 declare readOnlyHint=true and destructiveHint=false, and the description's 'Read-only' simply repeats this. No additional behavioral context is provided—such as what happens with invalid date ranges, whether basis affects results, or any authentication/rate-limit considerations. The description adds no new behavioral disclosure 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 two concise sentences, with the key content in the first. The second sentence 'Read-only' adds no value beyond the annotations, slightly reducing efficiency, but the overall structure is tight and 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 five parameters including basis (accrual/cash) and date boundaries, the description is too thin. It doesn't clarify which parameters are needed for a meaningful report, how basis changes the output, or what the date range defaults to. An output schema exists, but parameter semantics still require explanation.

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 20% (only companyId has a wrapper description). The description does not explain the meaning of basis, date range, currencyCode, or how they shape the report. 'For a period' is too vague to compensate for the low schema coverage, so the agent must guess at parameter semantics.

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 returns an income statement for a period, listing revenue and expense accounts with activity, totals, and net income. This specific verb+resource makes it easy to distinguish from sibling tools like balance sheet or trial balance.

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 when to use the tool (for income statement/reporting) but does not explicitly contrast it with alternatives such as accounting_get_balance_sheet or accounting_get_trial_balance. There is no clear 'when not to use' guidance, so usage is inferred rather than 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?

The readOnlyHint annotation already establishes this is a safe read operation, and the description's 'Read-only' is redundant. The description does add the useful detail that the response includes postings, which goes beyond the annotation, but it does not disclose error behavior or other operational nuances.

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 exactly two short sentences, front-loaded with the primary action and outcome. Every word is purposeful, and the 'Read-only' clarification is acceptable given the annotation, though slightly redundant.

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

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

Given the tool's simplicity, the presence of an output schema, and annotations declaring it a read-only operation, the description covers the essential behavior. It lacks explicit usage guidance or alternative mentions, but these are not critical for a get-by-ID tool where parameters and return structure are already defined.

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 parameters have 'UUID value wrapper' descriptions), so the baseline is 3. The tool description does not provide any additional meaning beyond the schema; it does not clarify how to obtain or format the IDs, leaving the agent to rely on 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 the specific verb 'returns' and names the resource 'one schedule with its postings,' making the purpose clear. It also distinguishes from sibling tools like accounting_get_list_schedules by explicitly noting it returns a single schedule, not a list.

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

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

The description implies usage for retrieving one specific schedule but does not explicitly state when to choose this tool over alternatives like accounting_get_list_schedules. There is no mention of required identifiers, although they are in the schema, and no 'use this when...' 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=true and destructiveHint=false, so the read-only nature is covered. The description adds context beyond annotations by explaining the output semantics: per-account debit/credit totals and the balancing property. This is useful behavioral context about the report's 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?

The description is concise and front-loaded, with two sentences covering the core function and a read-only note. However, the 'Read-only.' statement is redundant with the annotation, slightly reducing efficiency, but it doesn't detract significantly.

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

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

With an output schema present, return values are likely covered. The description adequately covers the main purpose but omits parameter semantics and edge cases (e.g., what happens if dates are omitted, default basis). It's adequate for a report tool but has 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 only 20%, with only companyId having a minimal description. The description text does not explain parameters like basis, startDate, endDate, or currencyCode, nor does it clarify that 'period' relates to the date parameters. It fails to compensate for the low schema coverage.

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

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

The description clearly states the tool returns every account's debit and credit totals for a period, which is a specific verb+resource. The balancing condition ('total debits equal total credits') adds distinctive semantic detail that differentiates it from sibling reports like general ledger or balance sheet.

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 by describing the trial balance report, but it doesn't explicitly state when to use this tool versus alternatives such as accounting_get_general_ledger or accounting_get_balance_sheet. There are no exclusions or alternative scenarios mentioned.

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

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

Annotations already declare read-only and non-destructive. The description adds valuable context by noting the log is 'append-only' and 'newest first', which explains the immutable, ordered nature beyond what annotations provide. 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?

Two sentences deliver purpose, scope, ordering, filtering, and read-only status with zero filler. The description is front-loaded with the core verb and resource.

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

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

For a read-only, paginated list tool with an output schema and annotations, the description covers the essential behavior: purpose, scope, ordering, and filter. It does not explain companyId semantics or pagination token details, but these are partially inferable from the schema and required 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?

The description explains entityId as a filter for one record's history and implies pageSize/pageToken via 'pages through'. However, companyId, a required parameter, is only described as a 'UUID value wrapper' in the schema, with no additional meaning in the description. Coverage is 50%, so partial compensation.

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 identifies the tool as paginating through the append-only accounting audit log, specifying the exact scope (journal entries and chart of accounts) and ordering (newest first). It distinguishes from siblings like cap_table_list_cap_table_audit_events by explicitly stating 'accounting audit log'.

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

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

The description gives clear usage context: use when you need to see who changed what and when in accounting, and use entity_id for a single record's history. It lacks explicit exclusions or alternative tool references, but the context is unambiguous.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the behavioral detail that it computes per-currency totals and net income, but does not disclose prerequisites, rate limits, or other side effects. This modest addition beyond annotations warrants a 3.

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 brief and front-loaded, stating the core computation first. However, 'without writing anything' and 'Read-only' are redundant, making the second sentence slightly repetitive. It is still efficient and well-structured.

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?

While the output schema exists, the tool description leaves parameter semantics unexplained, particularly startDate, endDate, and basis, which are essential for correct invocation. The high-level overview does not compensate for the low schema coverage, making the tool contextually incomplete.

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 25%, with companyId receiving a minimal 'UUID value wrapper' description and basis, startDate, endDate lacking any descriptions. The tool description does not explain the meaning of the date range or basis enum, leaving the agent without enough information to populate these parameters correctly. It fails to compensate for the sparse schema.

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

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

The description clearly states the tool computes per-currency revenue/expense totals and net income a close would roll, using a specific verb and resource scope. It explicitly distinguishes itself from sibling tools like accounting_close_period by stating 'without writing anything' and 'Read-only', clarifying this is a non-mutating preview.

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 clearly implies the use case: previewing the financial impact of a close before executing it. While it does not explicitly name alternatives, 'without writing anything' contrasts with actual close tools, providing clear context. No explicit when-not-to-use scenarios are given, but the intent is apparent.

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 destructiveHint=false, so the description's 'without persisting anything' and 'Read-only' largely duplicate that safety profile. It adds the straight-line calculation method but does not disclose additional behavioral traits such as failure modes, auth requirements, or precisely how startDate affects the result.

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. However, it redundantly states 'without persisting anything' and 'Read-only,' which are essentially the same point, slightly undermining efficiency.

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 3-parameter read-only tool with an output schema, the description covers the basic purpose and safety profile. But it lacks explicit usage guidance and fails to explain startDate, making it only minimally complete for selecting and 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?

With 0% schema description coverage, the description must compensate for parameter meaning. It mentions 'amount and period count' but omits startDate entirely, leaving its role in the calculation unclear. It also does not clarify formats beyond the schema patterns or whether all parameters are required despite schema stating none are required.

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 computes a straight-line per-period split for a given amount and period count, which is a specific verb and resource. It also explicitly notes that nothing is persisted, distinguishing it from schedule creation and retrieval tools like accounting_create_schedule and accounting_get_schedule.

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

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

The description implies a preview use case by stating 'without persisting anything,' which contrasts with creation tools. However, it does not explicitly name alternatives or state when to use this tool versus others. The guidance is implied rather than explicit.

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

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

Annotations already mark it read-only and non-destructive. The description reinforces this by stating 'Returns proposals only — nothing is created.' It also adds context about the input source (recent posted transactions) and the contents of each proposal, exceeding what annotations alone 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?

Three focused sentences. The first sentence states the core action, the second clarifies the workflow and non-mutating nature, and the third lists proposal contents. No redundant wording or repetition of schema details.

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 output schema exists (so return values are structured separately), the description fully covers purpose, workflow, and relationship to sibling tools. It tells the agent exactly what to do with the result, making invocation and follow-up clear.

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

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

The schema has only companyId with a minimal 'UUID value wrapper' description. The tool description implies companyId selects the company whose transactions are scanned, adding partial meaning beyond the schema. Since schema coverage is 100% but thin, this is a baseline 3 with some added context from the 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 clearly states it scans recent posted transactions and suggests accrual schedules. It distinguishes itself from accounting_create_schedule by explicitly noting that nothing is created until confirmed, so the agent knows this is a proposal-generation tool, not a mutation.

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 guidance: use this to get proposals, then call accounting_create_schedule to confirm. The example (amortize a prepaid) clarifies typical use. This directly tells the agent when to use this tool versus the create 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?

The description adds meaningful detail beyond the destructiveHint annotation: it voids closing entries, lifts the write lock, allows editing, permits re-closing, and is audit-logged. This explains the consequences of the destructive action, increasing transparency. 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 ('Reopen a closed accounting period') and then provides essential details. Every word earns its place, with no fluff 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 destructive mutation with two parameters and an output schema, the description provides sufficient context: the scope, the side effects (voiding entries, lifting lock), and the audit trail. It does not mention prerequisites like period must be closed, but that is implied. Overall, it is fairly complete for the tool's complexity.

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

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

The input schema already documents both parameters (companyId and periodId) with full coverage, so the baseline is 3. The description does not add any additional semantics beyond what the schema provides, so it stays at baseline.

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 purpose: to reopen a closed accounting period by voiding its closing entries and lifting the write lock. This specific verb-resource combination distinguishes it from siblings like accounting_close_period (the inverse operation) and read-only period queries.

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 to use the tool: when a closed accounting period needs to be reopened so entries inside its date window can be edited. It implies the alternative of leaving the period closed and contrasts with close_period, though it does not explicitly mention when NOT to use it or list alternative tool names.

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 annotations (idempotentHint, destructiveHint), the description discloses critical behavior: lines must balance, source is forced to user and status to POSTED, every save is audit-logged, and entries with transaction_id replace derived entries and survive re-enrichment. These are valuable contextual details not present in annotations or schema.

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

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

Three dense sentences, front-loaded with purpose, then constraints, then behavioral traits. Every sentence provides necessary information with zero filler.

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

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

For a complex nested-parameter tool, the description covers the key aspects: balance rules, line limits, amount formatting, account selection, transaction override semantics, and forced fields. An output schema is present, so return values need no explanation. The description is sufficiently complete for an agent to use the tool correctly.

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

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

Schema description coverage is 0%, so the description carries a heavy burden. It adds significant meaning to the 'entry' object: constraints on lines (2-64, debits == credits), amount format (positive decimal with side carrying sign), glAccountId selection from chart of accounts, and transactionId behavior. Some fields like entryDate, memo, currencyCode are not elaborated, but the most critical semantics are covered.

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

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

The description specifies a clear verb and resource: 'Create or replace a double-entry journal entry', with explicit scope ('manual adjustment or per-transaction override'). It distinguishes this tool from siblings like accounting_delete_journal_entry and accounting_get_journal_entry_by_transaction.

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

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

The description gives clear usage context by stating when to use the tool (manual adjustment or per-transaction override) and even points to accounting_get_chart_of_accounts for selecting gl_account_id. However, it does not explicitly mention when not to use it or name alternative tools for similar operations, just missing that explicit exclusion.

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

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

With annotations limited to openWorldHint=false and destructiveHint=false, the description adds value by disclosing caching behavior ('Results are cached per company + account + window + charge, so repeated panel opens do not re-run the agent'). However, it does not explicitly state whether the operation is read-only or what side effects, if any, exist beyond caching.

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 and reasonably concise. The first sentence conveys the core action, and the second adds useful caching context without excessive verbosity. Minor awkward phrasing in 'summarises one charge against the campaigns in its billing window' prevents a 5.

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 6 optional parameters, an output schema, and limited annotations, the description only explains the primary purpose and caching. Lacking usage context, parameter details, and distinct behavior against siblings, it is not complete enough for an agent to confidently invoke the tool without external knowledge.

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

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

Schema description coverage is 0%, and the description does not explain any parameter semantics. It indirectly references 'company + account + window + charge' which maps to companyId, accountId, periodStart/periodEnd, and chargeAmount, but does not detail formats or relationships. Given 6 parameters, the description must compensate more.

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 'summarises one charge against the campaigns in its billing window', which is a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like provider-specific campaign window getters, so it falls 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 guidance on when to use this tool versus alternatives. It mentions 'panel opens' but does not explain conditions for invocation or exclusions, leaving the agent without direction on 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=true and destructiveHint=false, so the agent knows it is a safe read operation. The description adds 'lightweight' and 'status only' which reinforce the non-mutating, poll-like behavior, but it does not disclose any additional behavioral details such as rate limits, authentication requirements, or what happens when the action cannot proceed. Still, given the annotation coverage, the description adds some value beyond the structured 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?

The description is a single, well-structured sentence that front-loads the tool's name (GetApprovalSessionStatus) and clearly communicates its purpose in a compact form. Every word adds value: 'lightweight,' 'poll,' 'status only,' and 'gated action' all contribute to understanding the tool's function without wasted prose.

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 low complexity (one simple parameter), the presence of a read-only annotation, and an output schema (as indicated by hasOutputSchema=true), the description sufficiently covers the essential context. It tells the agent exactly what the tool checks and its lightweight nature, leaving no critical gaps for basic usage. The output schema presumably details the return values, so the description does not need to explain them.

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 one parameter, sessionId, with a description ('UUID value wrapper') that fully covers its meaning (100% schema description coverage). The tool description does not mention the parameter, so it adds no additional semantic value beyond the schema. This aligns with the baseline score of 3 when schema coverage is high.

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 with a specific verb ('poll') and resource ('approval session status'), and defines its scope as a lightweight, status-only check for whether a gated action can proceed. It effectively distinguishes itself by focusing on the approval session domain and its polling nature, 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 implies when to use the tool: when you need to poll the status of a gated action to see if it can proceed. It provides clear context by labeling it a 'lightweight poll,' but it does not explicitly mention alternatives or when not to use it, though no direct sibling tool exists for approval sessions, making this less critical.

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 clearly states the operation is destructive ('deletes every stakeholder'), but the annotations declare destructiveHint false. This is a direct contradiction, making the behavioral transparency misleading. The description adds the important detail of 'single DB-level operation' but the annotation conflict overrides that.

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

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

Two sentences, each adding value: the first defines the exact action and scope, the second explains its intended usage. No filler or redundant 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?

The description covers the essential aspects: what it does, scope, and use case. It does not explain irreversibility, permissions, or downstream effects, but given the simple single-parameter signature and presence of an output schema, this is mostly adequate. The annotation contradiction reduces trust but not completeness per se.

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 companyId documented as 'UUID value wrapper.' The description adds no additional parameter semantics beyond what the schema provides. Baseline of 3 is appropriate because the schema fully covers the single parameter.

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

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

The description uses a specific verb 'deletes' and clearly identifies the resource 'every stakeholder of a company'. It distinguishes itself from sibling tools like cap_table_delete_cap_table_stakeholder by emphasizing the bulk, all-stakeholders scope and single DB-level operation.

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 a clear use case: 'Used by the "replace cap table" import flow.' This gives context for when to invoke this tool versus the singular delete alternative. However, it does not explicitly list exclusions or alternative tools for partial deletes, but the context 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, but the description adds extensive context: it 'CANNOT be undone', 'writes the cap-table of record', 'persists the SAFE conversions + ownership snapshots', and advises to 'confirm with the user first'. This goes well beyond the annotation, disclosing the irreversible and consequential nature of the operation.

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

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

The description is three sentences long, front-loaded with the tool's core action, and every sentence adds essential information: what it does, how to interpret user intent, and the warning about irreversibility. No redundant wording.

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, irreversible mutation tool, the description gives sufficient context: the exact workflow, the permanent impact, the user-confirmation requirement, and the alternative preview option. Since an output schema exists, return values don't need elaboration. This is complete for the tool's complexity.

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

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

Schema description coverage is only 33% (just 'UUID value wrapper' for companyId and roundId). The description does not explain any parameter meanings, such as newMoneyRaise, preMoneyValuation, carryForwardUnwired, or targetOptionPoolPct. While the parameter names are somewhat self-explanatory, the description fails to compensate for the low schema coverage.

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

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

The description clearly states the tool's function with a specific verb and resource: 'CloseCapTableRound PERMANENTLY closes the round' and outlines the exact actions (runs the calc engine, persists SAFE conversions + ownership snapshots, flips the round to CLOSED). It distinguishes itself from the sibling PreviewCloseCapTableRound by explicitly noting the difference between closing and estimating.

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 defines when to use this tool: 'This is the action for "close the round", "make it permanent", or "finalize the round"'. It also provides a clear exclusion and alternative: 'To only estimate the outcome without closing, use PreviewCloseCapTableRound'. This is strong 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?

The annotations do not include a readOnlyHint, so the description must clarify it is a mutation; it does by saying 'creates.' However, it only adds 'draft' as a behavioral trait and does not disclose permissions, side effects, or what happens after creation. This sparse disclosure falls short for a create operation.

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 conveys the core action and a key qualifier without any waste. It is appropriately concise for a simple purpose, though it lacks depth.

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?

Despite having an output schema and some annotations, the description is insufficient for a tool with 8 parameters, including nested objects. It does not explain required fields, the meaning of 'draft,' or why the type enum includes SAFE if the tool is non-SAFE. The agent would need external knowledge 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 only 38%, with most parameters lacking descriptions. The tool description mentions no parameters or how they relate to the non-SAFE scope, so it does not compensate for the schema gaps. For instance, the type enum includes SAFE despite the description saying non-SAFE, but no parameter guidance is given.

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 creates a draft cap table agreement and specifies 'non-SAFE,' which distinguishes it from SAFE-related tools. Although the name already indicates the resource, the description adds the scope qualifier and draft status, 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 implies use when creating a non-SAFE agreement but provides no explicit guidance on alternatives or when not to use. It does not mention that SAFE agreements should be handled by other tools or any prerequisites, so usage context is only 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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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

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

Tool has no description.

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 (openWorldHint=false, destructiveHint=false) are present, but the description adds meaningful behavioral context: it clarifies that only identity is created, no holdings/securities are created, and the stakeholder will not appear in the investor pipeline. This goes beyond what the annotations convey and helps the agent predict side effects.

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

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

The description is two sentences, front-loaded with the key distinction ('IDENTITY ONLY'), and every sentence earns its place. It is concise, clear, and well-structured.

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 (a single object parameter with many nested fields), the description adequately explains the tool's scope and pitfalls, and an output schema exists to cover return values. It could mention required fields or enum constraints, but those are visible in the input schema, so the description is sufficiently complete for an agent to select and 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?

The schema already documents the nested fields with descriptions (e.g., name, type, email), so the description need not repeat them. However, the description mentions a subset of fields ('name, type, email, metadata') without elaborating on the full object structure, and schema coverage is listed as 0% for the top-level parameter, so it adds only modest semantic value 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 ('Adds') and explicitly scopes the resource as 'stakeholder IDENTITY ONLY', which clearly distinguishes it from related tools by stating it does NOT create any holding/security or appear in the investor pipeline. This directly addresses sibling differentiation (e.g., RecordCapTableInvestment).

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

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

The description explicitly tells when to use this tool versus the alternative: 'For an investor contributing capital via SAFE or priced shares, use RecordCapTableInvestment instead'. It also states what this tool will not do, giving clear exclusion criteria.

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 flag destructiveHint=true, and the description simply says 'removes', adding no new behavioral context. It does not disclose permanence, cascading effects, or any special permissions, which are valuable for a destructive operation.

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 extremely short (six words), which is concise, but the content is largely a restatement of the tool name and adds little informational value. It is not 'appropriately sized' because it under-specifies the operation.

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 delete operation, the description is severely lacking in contextual detail. It does not explain what 'removing an agreement' entails (e.g., irreversibility, associated records, permission requirements), and the available annotations do not compensate for this gap.

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

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

Schema description coverage is 100% (though the 'UUID value wrapper' descriptions are minimal), so baseline is 3. The tool description adds no parameter meaning beyond what the schema provides, but the parameter names and types are fairly self-explanatory given the tool name.

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 'DeleteCapTableAgreement removes an agreement' is essentially a tautology of the tool name and title. It states the action verb 'removes' and resource 'agreement' but adds no specificity or differentiation from sibling tools like deleting a round or stakeholder.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, side effects, or contrast with related cap_table operations, leaving the agent without decision support.

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 goes beyond the destructiveHint annotation by specifying the cascading effect ('plus its round-scoped securities/agreements/snapshots') and the rejection condition with error type ('FailedPrecondition'). This discloses important behavioral traits that annotations alone do not 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 two concise sentences that front-load the action and scope, with no wasted words. It efficiently covers purpose, applicability, and limitations.

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 deletion tool with an output schema and two simple parameters, the description covers the essential context: what is deleted, what is rejected, and the permanent nature. It does not need to explain return values because the output schema exists, and the annotations cover safety.

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 both parameters as 'UUID value wrapper' with 100% coverage, so the description adds minimal parameter-specific meaning. It implicitly connects roundId to the SAFE round but does not elaborate beyond the schema.

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

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

The description clearly states the tool's function: 'permanently removes an unpriced SAFE round (open or light-closed) plus its round-scoped securities/agreements/snapshots.' This specifies the exact resource and action, and distinguishes it from sibling tools like close_cap_table_round or delete_cap_table_agreement.

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

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

The description provides explicit conditions: it is for unpriced SAFE rounds in open or light-closed states, and 'Priced / engine-closed rounds are rejected (FailedPrecondition).' This clearly tells the agent when to use the tool and when not, though it does not explicitly compare with alternatives.

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, so the destructive nature is known. The description adds minor value by specifying it removes 'one holding', implying a single entity deletion, but it does not disclose irreversibility, side effects on related data, or permission requirements.

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 concise sentence, immediately front-loaded with the action ('removes'). It wastes no words and is easy 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?

Despite having an output schema and annotations, the description is very minimal for a destructive operation. It lacks contextual information such as what happens to associated holdings, whether deletion is permanent, or any preconditions. The complexity is low, but the absence of behavioral context makes it incomplete 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?

Schema description coverage is 100% (both parameters have descriptions like 'UUID value wrapper'), so the schema carries the parameter meaning. The description adds no additional semantics beyond what the schema provides, keeping the baseline score at 3.

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 ('removes') and the specific resource ('one holding'), which is more precise than the title. It distinguishes this from sibling delete tools (e.g., delete_cap_table_agreement, delete_cap_table_round) by focusing on the security/holding entity.

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

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

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. Unlike examples like 'use search_calls_extensive instead', there is no mention of alternative tools or specific conditions for deletion.

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

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

Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds only the direct action ('removes one stakeholder') without further context such as irreversibility, cascading effects on associated records, or permission requirements. Given the annotation coverage, a score of 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 concise sentence that directly states the purpose without unnecessary elaboration. Every word contributes to clarity, and the format is easily scannable.

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 delete tool with one fully documented parameter, an output schema, and destructive annotations, the description is sufficiently complete. It covers the core action, while annotations convey the destructive nature. A minor gap is the lack of explicit mention of permanence or side effects, but these are implied by the annotations and simple scope.

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 the sole parameter stakeholderId documented as 'UUID value wrapper'. The description adds no additional meaning to the parameter, so the baseline of 3 applies. The nested object structure is already explained in the schema.

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

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

The description clearly states it removes one stakeholder from a cap table, using the specific verb 'removes' and identifying the exact resource. This distinguishes it from sibling tools like cap_table_clear_cap_table_stakeholders (which removes all) and delete operations for other entities (agreements, rounds, securities).

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 explicit guidance on when to use this tool versus alternatives, such as cap_table_clear_cap_table_stakeholders for bulk removal or update for modifying instead of deleting. No context is given about prerequisites or situations where 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?

The description clarifies that 'download' actually means 'presigns', which is an important behavioral nuance beyond annotations. Annotations already mark it as read-only and non-destructive, and the description adds the batch-presigning behavior without contradicting them.

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 is front-loaded with the key action and resource. No wasted words or redundant details.

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, and an output schema exists, so return values are documented. However, the description does not clarify behavior when agreementIds is omitted, error scenarios, or whether it presigns all SAFEs by default. This leaves minor gaps in 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 descriptions are minimal ('UUID value wrapper') with only 50% coverage. The description does not explain companyId or the optionality of agreementIds; it only implies agreementIds maps to the multiple PDFs. This provides incomplete parameter 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 uses a specific verb 'presigns' and resource 'multiple SAFE agreement PDFs', clearly distinguishing this batch tool from singular alternatives like cap_table_get_cap_table_agreement_pdf_url. It precisely conveys the tool's function.

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 'in one call' implies a batching use case, but the description does not explicitly state when to use this tool over alternatives or when not to use it. There are no exclusions or alternative tool references, leaving the context only 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?

Adds important behavioral details beyond annotations: nothing is persisted, requires prior upload, verdict values, and constraint for RecordCapTableWire. Annotations are minimal, so description carries the burden well and does not contradict them.

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 concise sentences: purpose, flow, constraint. Every sentence adds value with zero filler.

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

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

Covers return verdict, flow, persistence, and constraint. Output schema fills in field details. Missing explanation of optional agentCode, but overall complete for a complex 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 coverage is 50%; description explains sourceS3Uri origin and securityId context via 'for a security', but agentCode remains unexplained. Adds some meaning beyond schema but not full compensation for all 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 (runs vision OCR) and resource (wire payment proof), and explicitly differentiates from invoices and ties to RecordCapTableWire. It clearly distinguishes from other cap_table 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?

Provides explicit flow (GetOcrUploadURL → PUT → call with source_s3_uri) and context (only 'verified' can back a wire). Does not name alternative tools but gives clear when-to-use and exclusion (NOT an invoice).

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?

Since annotations lack a readOnlyHint, the description appropriately discloses the side effect of storing the PDF. It also communicates the return value (S3 key) and the follow-up URL retrieval step, adding behavioral context beyond the sparse 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. It front-loads the primary action and then provides essential follow-up information about the S3 key and URL retrieval, making every sentence valuable.

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 simplicity (2 required params), the presence of an output schema, and the clear coverage of purpose, side effect, and workflow, the description is largely complete. It doesn't discuss edge cases or prerequisites, but for this tool it provides sufficient 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?

The schema documentation covers 100% of the parameters with 'UUID value wrapper' descriptions, so the baseline is 3. The description adds no additional parameter-specific meaning; it only implies agreementId through 'one employee equity-grant agreement', but this is already evident.

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

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

The description uses a specific verb ('renders') and resource ('PDF for one employee equity-grant agreement'), lists the grant types (option/rsu/rsa/fast), and distinguishes itself by returning the S3 key. This makes it clearly distinct from sibling tools like cap_table_generate_cap_table_summary_pdf.

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 on when to use the tool: to generate and store an agreement PDF, then fetch the presigned URL via GetCapTableAgreementPdfUrl. However, it does not explicitly state exclusions or alternative tools for other PDF types, so it stops short of full 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?

The description reveals the async nature of the operation ('async generation pipeline'), which is a behavioral trait not captured in the annotations (openWorldHint=false, destructiveHint=false). However, it does not disclose other important behaviors such as required permissions, whether existing documents are replaced, or how results are delivered. With minimal annotations, the description only partially fulfills the transparency burden.

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 short and front-loaded, but the sentence includes the redundant term 'GenerateCapTableDocs' which repeats the tool name. While concise, it sacrifices substance for brevity, resulting in a marginally acceptable one-liner.

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?

Despite having an output schema, the description is incomplete for a tool with two parameters, async behavior, and multiple sibling tools. It does not explain what 'cap table docs' are, what triggers the pipeline, or how the output is returned. The description leaves too much ambiguity for the agent to confidently invoke and interpret the result.

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

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

The input schema descriptions ('UUID value wrapper') are unhelpful and schema coverage is at 50%. The tool description does not explain the meaning or purpose of companyId or stakeholderIds, nor does it describe how they affect the generation. This leaves the agent with no semantic understanding of the 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 the action ('kicks off the async generation pipeline') and the resource ('Cap Table Docs') but is vague about what specific documents are generated or how this differs from sibling tools like cap_table_generate_cap_table_agreement_pdf or cap_table_generate_cap_table_summary_pdf. It is more than a pure tautology but lacks clear differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, expected use cases, or exclusions. The presence of many similar generate/download tools in the sibling list makes this lack of guidance particularly problematic.

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 (destructiveHint=false, openWorldHint=false), the description adds key behavioral details: it renders on a backend document engine (Gotenberg), returns bytes, and explicitly states 'Read-only'. This provides useful context about safety and execution environment, though it does not discuss error behavior or prerequisites.

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, front-loads the core action, and includes only essential details (backend engine, return type, read-only, ticket reference). Every part earns its place with no 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 single-parameter tool with an output schema and annotations, the description covers the action, execution location, output type, and safety profile. It is complete for an agent to select and invoke the tool correctly, without needing to explain return structure since the output schema exists.

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 covers 100% of the parameter with a description ('UUID value wrapper'), so the description does not need to add parameter detail. It adds no further semantics, which is acceptable given the high schema coverage, but does not go beyond the baseline.

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 ('renders') and identifies the exact resource ('cap-table summary to a branded PDF'), while also noting the backend engine (Gotenberg) and return type (bytes). This clearly distinguishes it from siblings like cap_table_generate_cap_table_agreement_pdf and cap_table_get_cap_table_summary.

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 generating a PDF of the cap-table summary and mentions moving PDF generation out of the browser, but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. No alternative tools are named as contrasts.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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

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

Tool has no description.

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 the important behavioral detail that the URL is 'short-lived' and 'signed', which goes beyond the readOnlyHint and destructiveHint annotations. It also indicates the URL points to an S3 object. However, it does not mention failure modes (e.g., if the PDF has not been rendered) or the exact lifetime, but annotations already cover the safety profile.

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 immediately states the action and the result. It is front-loaded with 'GetCapTableAgreementPdfUrl' and contains no redundant words or filler, making it highly concise and well-structured.

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 a read-only getter with an output schema, so the description covers the core return value. However, it lacks guidance on the prerequisite that the PDF must already be rendered, and it fails to explain the purpose of the 'attachment' parameter. These gaps make it incomplete for a tool with two parameters and a non-trivial 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?

The description does not elaborate on the parameters. Schema coverage is only 50% (agreementId has a description, attachment does not), and the description adds nothing about what 'attachment' means or how parameters should be used. The agent would need to infer from the schema alone, which is insufficient for the optional attachment parameter.

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

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

The description uses the specific verb 'returns' and clearly names the resource as 'a short-lived signed S3 URL for the rendered SAFE agreement PDF'. This makes the tool's purpose unambiguous and distinguishes it from sibling tools like cap_table_generate_cap_table_agreement_pdf (which generates the PDF) and cap_table_get_cap_table_agreement (which likely retrieves the agreement metadata).

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 'rendered SAFE agreement PDF' implies the PDF must already exist, but the description does not explicitly say when to use this tool versus alternatives (e.g., generate_pdf or download_safes). There are no explicit exclusions or conditions, leaving usage to be inferred from the tool name and 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 declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: vesting progress is 'resolved as of now,' and it specifies the exact data carried for founder/advisor/employee vs. investor entries. This gives the agent a precise expectation of the resolved output without contradicting 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 three sentences, front-loaded with the main purpose, then details and a use-case example. Every sentence adds value with no filler or repetition of annotations. It is information-dense and perfectly sized.

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 rich output schema and strong annotations, the description covers all essential context: what data is returned, how it is grouped, the temporal resolution of vesting, and typical use cases. No critical gaps remain for an agent to use this tool correctly.

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

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

The input schema has 100% description coverage for the single parameter companyId ('UUID value wrapper'), so the schema fully documents it. The description does not mention parameters, but since the schema is exhaustive and the parameter is straightforward, 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 clearly states the tool 'returns a company's equity holdings grouped the way a founder thinks about them: founders, advisors, employees (option grants), and investors.' This is a specific verb and resource, and it distinguishes the tool from sibling tools like cap_table_get_cap_table_overview or cap_table_get_list_cap_table_securities by the conceptual grouping and the included fields.

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 says to 'Use this to answer "who holds what" or "how much of X's grant has vested" without adding up securities by hand,' providing clear use cases. It implies this is the go-to for aggregated equity views, but it does not explicitly name alternative tools or state when NOT to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds useful context: 'read directly from the stakeholder row' indicates no derived computation, and 'a new investor defaults to NONE' discloses default visibility behavior. This goes beyond the annotation safety profile.

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 concise, with two sentences that each add value: the first states the core purpose and the second provides behavior context (direct read, default NONE). No unnecessary repetition beyond the redundant 'Read-only' (already in annotations), which is minimal and not harmful.

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 list tool with one parameter, good annotations, and an output schema, the description is largely complete. It explains the scope (every investor), the data source (stakeholder row), and the default visibility (NONE). It could mention the possible visibility levels, but these are likely in the output schema, so the lack is acceptable.

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% since the only parameter companyId has a description ('UUID value wrapper'), so the baseline is 3. The description does not add further param-specific semantics, but the parameter is straightforward and the tool name implies the company context.

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

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

The description clearly states the tool 'lists every investor stakeholder with its current cap-table visibility level', specifying the verb (lists), resource (investor stakeholders), and the key attribute (visibility level). This distinguishes it from sibling tools like cap_table_get_cap_table_stakeholder (single stakeholder) and cap_table_get_list_cap_table_stakeholders (generic list).

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 you need investor access levels for all investors, but it does not explicitly state when to use it versus alternatives or provide exclusions. There is no mention of alternative tools for filtered or individual stakeholder access, so the guidance is only 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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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

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

Tool has no description.

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 readOnlyHint annotation, the description discloses important semantics: the stage buckets are exclusive, raised is the sum of the buckets, and it clarifies the meanings of committed/signed/wired. This is valuable behavioral insight not available from annotations alone.

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 well-structured, with the first sentence stating what is returned and the second providing usage guidance and key semantic clarifications. Every sentence adds value with no fluff.

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 simplicity (one parameter) and the presence of an output schema, the description fully covers the return value semantics, usage context, and important caveats about how the round stages are aggregated. It is 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?

The schema already covers the single companyId parameter with a description ('UUID value wrapper') at 100% coverage. The tool description adds no additional parameter-specific meaning, 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 ('Returns') and explicitly names the resource (funding round summaries) and the exact fields returned (capital per pipeline stage, total raised, investor count). It clearly distinguishes itself from sibling tools like get_cap_table_round by scoping to all rounds with investors attached.

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 use cases: answering 'how is the round going' or 'how much have we actually collected' without manual summation. This gives good context, but it does not explicitly mention alternatives or when not to use the tool, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'Read-only' is redundant. It adds no unique behavioral details such as error handling, permissions, or rate limits. It does not contradict annotations, but with annotations present, a 3 is appropriate because the description adds minimal value beyond them.

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 short sentences, front-loaded with the core action, and contains no filler or redundant information. It earns its place efficiently.

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 one parameter, an output schema, and annotations covering read-only behavior. The description covers its main purpose and scope. It does not explain error conditions, but that is not required given the output schema and simple get-by-id design. It is complete enough for this simple tool.

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

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

The schema already documents securityId as a UUID value wrapper with 100% coverage. The description's 'by id' clarifies that this parameter is the identifier used to look up the holding, providing marginal semantic value beyond the schema by explaining the parameter's role in the operation.

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 operation: 'returns one holding by id,' specifying a single resource and lookup method. This distinguishes it from sibling list endpoints like cap_table_get_list_cap_table_securities. The title aligns with the tool name and adds specificity.

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

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

The phrase 'by id' implies this is for retrieving a single security when the ID is known, providing clear context for when to use the tool. It does not explicitly name alternatives like the list tool, but the context signals sibling list endpoints, so it gives clear context without 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 declare readOnlyHint=true and destructiveHint=false, and the description's 'Read-only' merely repeats this. 'By id' restates the schema parameter without adding new behavioral traits such as not-found handling, permissions, or error conditions. The description adds minimal value 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 two short sentences with no redundant words. It efficiently communicates the purpose and read-only nature of the tool.

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

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

For a simple read-only getter with one parameter and an output schema, the description is nearly complete. The purpose and safety are stated, and the schema covers input. A brief mention of list alternatives would improve completeness, but the current description suffices for a low-complexity 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% (the stakeholderId parameter has a 'UUID value wrapper' description), so baseline is 3. The description clarifies that the ID is used to select the stakeholder, adding slight context, but it does not provide additional format or usage details beyond the schema.

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

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

The description clearly states that the tool returns one stakeholder by id, using a specific verb and resource. This distinguishes it from sibling tools like cap_table_get_list_cap_table_stakeholders, cap_table_create_cap_table_stakeholder, etc.

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

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

The phrase 'one stakeholder by id' implies the tool is for fetching a single stakeholder when the ID is known, but it does not explicitly state when to use this versus the list endpoint or other alternatives. No exclusions or alternative recommendations are provided.

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?

While readOnlyHint is already true, the description adds useful behavioral context by stating 'Keeps the ownership math server-side' and 'fully-diluted source roster.' This clarifies that calculations are authoritative and server-computed, going beyond the annotation alone.

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

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

The description is three sentences, front-loaded with the core purpose and details, followed by a short note on computation location and read-only status. Every sentence adds value and there is no filler.

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

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

The description adequately covers the return content and adds the server-side computation context, and an output schema exists to detail return fields. However, it omits the effect of the optional 'asOf' parameter and gives no guidance on how this tool relates to similar siblings like overview or round summaries, leaving some contextual 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?

The description does not explain the 'asOf' parameter or its effect on the aggregation. The schema provides only a weak description for companyId ('UUID value wrapper') and no description for asOf. With 50% schema coverage, the description needed to compensate but did not, leaving parameter meanings partially ambiguous.

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 returns a dashboard aggregate with specific metrics (totals, stakeholder count, founders %, per-type ownership segments) on the fully-diluted source roster. This is a specific verb+resource and delineates its function from other cap-table tools like overview or round summaries.

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 mentions 'Keeps the ownership math server-side,' implying the tool should be used when you need pre-computed ownership calculations rather than doing the math yourself. However, it does not explicitly state when to use this tool versus alternatives like cap_table_get_cap_table_overview, nor does it provide 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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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

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

Tool has no description.

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