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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds the max 500 limit and the requirement that each item needs an id plus fields to change, but it does not disclose whether updates are atomic, how partial failures are handled, what the response looks like, or any permission requirements. This is a gap for a mutation 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 concise and front-loaded: the first sentence states the core purpose, the second gives common uses, and the third lists fields. There is no fluff, and every sentence serves a clear 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?

The description covers usage context and constraints (max 500, id required) but omits what the tool returns on success or failure, which is important given there is no output schema. It also lacks guidance on partial failure behavior. However, the input schema is thorough, and the common uses provide enough context for basic invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description primarily reiterates field names already defined in the schema, adding little semantic value beyond clarifying that each item needs an id plus fields to change, which the schema already implies via the required id property.

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 updates multiple transactions at once with a max of 500, which is a specific verb, resource, and scope. It also lists common uses (batch-categorize, bulk mark reviewed, assign tags), distinguishing it from sibling tools like manage_transaction that likely handle single updates.

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 common use cases (batch-categorize, bulk mark reviewed, assign tags) implying when to use this tool. However, it does not explicitly mention when not to use it or name alternatives like manage_transaction for single updates, so it lacks explicit 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?

With no annotations, the description carries the burden of behavioral disclosure. It adds context about the account types (manual vs. synced) and the data shown (balances, types, status), but does not disclose potential behaviors like whether hidden/archived accounts are included, pagination, or authentication 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 concise, two sentences, front-loaded with the core action ('Get all Lunch Money accounts'). Every word adds value, with no filler or repetition.

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

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

Given the simplicity (0 params, no output schema, no annotations), the description is largely complete. It states what the tool returns and distinguishes account types. It could be slightly more explicit about response contents (e.g., includes account names/IDs), but it covers the essential use case adequately.

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

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

The tool has zero parameters, so the schema is fully covered (vacuously). The baseline for 0 params is 4, and the description adds no parameter-specific semantics needed. It instead provides useful return-value context, which is appropriate given no output 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 retrieves all Lunch Money accounts, explicitly distinguishing between manual and synced (Plaid) accounts. It also mentions what the response shows (balances, types, status), making the purpose unambiguous and distinct from siblings like manage_account.

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

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

The description implies when to use the tool: whenever all accounts are needed, with no filtering or modification. It clearly differentiates from management tools by focusing on retrieval only, though it does not explicitly name alternatives or 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?

With no annotations provided, the description carries the full burden. It discloses the output nature (expected amounts, frequency, match status) and the default period behavior when dates are omitted. It does not describe security implications or response format, but for a read-only retrieval tool, these disclosures are meaningful and exceed the minimum.

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 short sentences, each adding necessary information: what it does, what it shows, and the default behavior. It is front-loaded with the core action and contains no redundant phrases or filler.

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

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

Given only two optional date parameters and no output schema, the description covers the essential functionality well: what resource is retrieved, what information is returned, and the default period. It leaves some ambiguity around terms like 'match status' and does not detail response structure, but overall is sufficient 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 provides descriptions for start_date and end_date, so baseline is 3. The description adds valuable context by explaining that omitting dates defaults to the current month, which is not in the schema. This clarifies the behavior and relationships between 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 clearly states it retrieves recurring items (subscriptions, bills, income) and specifies what it shows (expected amounts, frequency, match status). This is a specific verb+resource that distinguishes it from sibling tools like list_transactions or get_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 when to use the tool by mentioning recurring items and the period, but it does not explicitly state alternative tools to use instead, nor does it provide exclusions. It does give a practical usage note about defaulting to the current month without dates, but lacks broader guidance on choosing between this and related tools.

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

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

With no annotations, the description carries the burden of revealing behavior. It discloses what the summary includes and the conditional inclusion of budget amounts when date ranges align with budget periods. However, it does not mention permissions, rate limits, or potential errors, which is a moderate gap for a read-only 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 concise and front-loaded: the first sentence states the core purpose, the second expands on output, and the tip adds practical guidance. Every sentence 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 simple read-only summary tool with no output schema, the description covers the return contents, the conditional budget behavior, and offers a practical usage tip. It is complete enough for an agent to understand what will be returned, though it could be explicit about the read-only nature.

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

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

Schema coverage is 100%, so the schema already describes each parameter. The description adds a helpful date-range example in the tip, but it does not provide additional semantic meaning beyond what the schema offers, making baseline 3 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 gets a budget summary for a date range and specifies the contents: income, spending, per-category breakdown with budget vs actual. This is a specific verb+resource action that distinguishes it from sibling tools like list_transactions or get_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 through the date-range parameter and provides a tip for monthly overviews, but it does not explicitly state when to use this tool versus alternatives, nor does it exclude cases where another tool would be more appropriate.

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

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

No annotations are provided, so the description carries the full burden. The verb 'Get' clearly signals a read-only operation, and it specifies the data returned. It does not discuss authentication or side effects, but for a simple getter this is sufficient and not misleading.

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

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

The description is a single, front-loaded sentence with no filler. Every word adds value, listing exactly what will be returned.

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?

No output schema exists, so the description compensates by listing the returned fields (name, email, budget name, primary currency). For a simple user info tool with no parameters and a clear read-only operation, this is complete.

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

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

There are zero parameters, so schema coverage is trivially 100%. The description adds no parameter details, but none are needed; the baseline for 0 params is 4.

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

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

The description uses a specific verb ('Get') and resource ('current Lunch Money user's account info'), and lists the specific fields returned, clearly distinguishing it from sibling tools like get_accounts or get_summary. This is unambiguous and specific.

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

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

The description implies when to use the tool (when needing the current user's account info), but it does not explicitly state alternatives or exclusions. Since it's a simple retrieval, the intended usage is clear but not formally differentiated from siblings.

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

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

With no annotations, the description carries the behavioral disclosure burden. It states that the grouped transaction amount equals the sum of the original amounts and that ungroup restores original transactions. This goes beyond the schema by revealing underlying behavior, though side effects on original transactions are not fully described.

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 well-structured with separate sections for group and ungroup actions. Each sentence serves a purpose, and the most important information is front-loaded. There is no filler or repetition of schema content.

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

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

For a tool with two actions and 8 parameters, the description covers the essential context: required vs optional parameters and the amount summation behavior. It does not mention return values or error conditions, but given the complexity and lack of output schema, it is reasonably complete. A perfect score would require more details on side 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value by mapping parameters to actions: ids/date/payee are required for group, id is required for ungroup. It also clarifies that category_id, notes, and tag_ids are optional for grouping. This extra context justifies a 4.

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 'Group or ungroup Lunch Money transactions', which clearly states the verb and resource. It further differentiates the two modes (group and ungroup) with specific instructions, distinguishing it from sibling tools like split_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 provides explicit context for when to use each action: grouping requires ids, date, and payee; ungrouping requires the parent id. It does not explicitly mention alternatives or when not to use the tool, but the action-specific guidance is clear enough.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explains the nested vs. flat behavior and the default, which is useful. However, it does not mention return structure, error cases, or authentication requirements, leaving room for more transparency.

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 19 words, front-loaded with the main purpose and immediately providing actionable format guidance. No unnecessary information.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description is sufficiently complete. It covers the core functionality and the only parameter option, making it easy 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 describes the 'format' parameter thoroughly (nested = grouped hierarchy, flat = list, default flat). The description adds little beyond the schema, essentially restating the options with slightly different wording. Given 100% schema coverage, 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 action ('List') and the resource ('all Lunch Money categories'). It also specifies two output formats, making the purpose immediately clear and distinct from sibling tools like manage_category, which handles modifications.

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 context on when to use the tool (for listing categories) and explains the format options. However, it does not explicitly exclude mutation scenarios or mention alternatives like manage_category for changes, so it lacks the 'when-not-to-use' guidance that would earn 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?

With no annotations, the description carries the full transparency burden. It indicates a read-only 'list' operation with no side effects, but provides no further detail on pagination, ordering, or response behavior. For a simple list tool this is acceptable 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?

Two concise sentences with the key information front-loaded. Every word adds value, explaining both the action and the purpose of tags.

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 (0 params, no output schema), the description is complete enough. It explains what the tool does and why tags matter, but could be slightly more explicit about the absence of filters or sorting options.

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

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

The tool has zero parameters, so the schema fully covers semantics. The baseline is 4, and the description adds no parameter-specific detail, which is appropriate given there are none.

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 all Lunch Money tags with a specific verb and resource. It distinguishes itself from sibling tools like list_categories by contrasting tags with categories.

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 context for when to use this tool, noting that tags are for additional organization beyond categories. This implicitly guides the user to choose this over list_categories when tag-level organization is needed, though it does not explicitly name 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?

It discloses the default 30-day range when no dates are provided and notes that output is hydrated (names instead of IDs). This is useful beyond the schema. Since there are no annotations, the description carries the burden; however, it does not explicitly mention that the operation is read-only or address error handling, leaving some transparency gaps.

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

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

The description is compact: three sentences covering purpose, filters, and output. It is front-loaded with the primary action and includes no fluff or redundant 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?

Given the 10 parameters and no output schema, the description covers the main behaviors (modes, defaults, filters, pagination, output). However, the account_id inaccuracy and lack of explanation about how the two account filters relate make it incomplete. It also does not clarify behavior when an id is used with filters.

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 aggregates filters and adds the default-date context, but it mentions 'account_id' which does not exist in the schema; the schema has separate plaid_account_id and manual_account_id. This is misleading and could cause incorrect invocation. Although the schema has thorough descriptions, this inaccuracy reduces the value added.

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 'List or look up Lunch Money transactions' with explicit modes (with/without id). This distinguishes it from sibling tools like manage_transaction or bulk_update_transactions, which imply write operations. The resource is specific and the verb is clear.

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

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

It provides clear context for when to use the tool: without an id for filtered lists, with an id for a single lookup. It also explains default date behavior and pagination. However, it doesn't explicitly state alternatives or when-not-to-use cases, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently warns that delete permanently deletes the account and that transactions are 'NOT deleted by default,' and it notes that synced accounts are read-only. These are important behavioral traits beyond what the schema conveys. It does not mention permissions, rate limits, or response formats, but the destructive warning and read-only constraint add significant transparency.

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 and efficient. It opens with a one-sentence summary, then provides a clear action-by-action breakdown in distinct lines. Every sentence adds value: the warning about delete is critical, and the optional parameters are listed without unnecessary elaboration. No filler or redundancy.

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

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

For a tool with 10 parameters and 3 actions, the description covers the essential context: what each action does, required vs. optional fields, and a critical warning for delete. It does not describe return values, but with no output schema that is not a major gap. It could mention the response format or potential errors, but the description is sufficiently complete for an agent to safely select and invoke the tool.

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

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

The schema already has 100% coverage, but the description adds action-specific semantics: it explains which parameters are required for create (name, type, balance) and which are optional, and clarifies that update accepts 'any fields to change' while delete only needs id. This goes beyond the schema's per-field descriptions by grouping parameters by action, making the tool easier to invoke correctly.

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: 'Create, update, or delete a manual Lunch Money account.' This specifies the verb (create/update/delete), resource (manual accounts), and scope (Lunch Money), and distinguishes it from siblings like get_accounts (which reads accounts). The additional note about synced (Plaid) accounts being read-only further clarifies the boundary.

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

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

The description provides clear context for when to use the tool: it is for manual accounts, and synced (Plaid) accounts are read-only, which serves as an explicit exclusion. The per-action breakdown (create/update/delete) with required parameters gives practical usage guidance. However, it does not explicitly name alternatives (e.g., get_accounts for viewing), though this is implied by the sibling 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?

With no annotations provided, the description carries the full burden. It discloses that force=true is needed to delete with dependencies, and that update supports partial field changes. It does not mention irreversible effects or permissions, but the core behavioral traits are covered.

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 action-labeled bullets, no redundancy, and every sentence provides actionable information. It is appropriately sized for the tool's complexity.

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?

All input parameters are covered across actions, but the description omits return value details (e.g., what the response contains after create/update/delete). Since there is no output schema, this is a notable gap, though not critical for invoking the tool correctly.

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

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

The description adds significant meaning beyond the schema by mapping each parameter to specific actions—e.g., name required for create, id for update/delete, force for delete. This clarifies conditional requirements the schema alone does not convey.

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 'Create, update, or delete a Lunch Money category' with specific action labels, making the tool's purpose unambiguous. It distinguishes from sibling tools like list_categories (read-only) by emphasizing CRUD operations.

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

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

It provides clear context per action (create/update/delete) with required fields and options. However, it does not explicitly contrast with sibling tools like manage_tag or list_categories, so the when-not-to-use guidance is implicit 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?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals important behavior: delete without force may fail if the tag is in use, and update allows changing name, description, or archived status. It also clarifies that name is required for create and id for update/delete. Missing details like permission requirements or error handling keep it from a 5.

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

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

The description is compact and front-loaded with the core purpose. Each line serves a distinct role: the first states the purpose, then each action is described with its required parameters and optional specifics. No redundancy or filler; it reads as a precise usage manual.

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 6-parameter mutation tool with no output schema, the description covers all necessary operational aspects: all three actions, required vs optional fields, and the special force behavior. It lacks only trivial details like return format, which are not essential for invoking the tool correctly. The coverage is fully sufficient.

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

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

The schema already describes all 6 parameters with 100% coverage, so the baseline is 3. The description adds value by mapping parameters to specific action contexts (e.g., 'name required for create', 'id required for update/delete', 'force=true only relevant to delete'), which is not fully evident from the schema alone. This elevates the score above 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 opens with 'Create, update, or delete a Lunch Money tag' – a specific verb and resource that clearly states the tool's purpose. It distinguishes from sibling tools like list_tags by focusing on mutations (create/update/delete) and enumerates the three actions explicitly.

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

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

The description provides action-specific guidance (e.g., 'Provide name (required) for create', 'Provide id for update/delete', 'Use force=true to delete even if used on transactions'), making it clear when to use each mode. However, it does not explicitly mention alternatives or when not to use the tool, such as pointing to list_tags for read-only needs, so it misses the top tier.

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

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

With no annotations provided, the description must carry the full behavioral disclosure burden. It does disclose action-specific requirements and the meaning of amount sign (positive=debit, negative=credit), which is useful. However, it does not explain update semantics (e.g., whether omitted fields are unchanged or cleared), delete irreversibility, or expected return values, leaving meaningful gaps given the lack of 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 highly concise and well-structured. It front-loads the primary purpose in a single sentence, then uses bullet-style action-specific lines to convey the required parameters without redundant commentary. Every sentence contributes directly to operational guidance.

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 moderate complexity (11 parameters, three distinct actions) and no output schema or annotations, so the description must carry significant weight. It covers the main actions well but fails to mention the 'manual_account_id' parameter entirely and incorrectly names it 'account_id' in the create instructions. This omission and mismatch leave the description incomplete for a full parameter set.

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

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

The schema already provides 100% description coverage for all 11 parameters, so the baseline is 3. The description adds value by grouping parameters by action and clarifying the amount sign, but it also introduces a mismatch: it references 'account_id' in the create action, while the schema defines 'manual_account_id'. This error undermines the added semantics, leaving the score at the baseline rather than above.

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 'Create, update, or delete a single Lunch Money transaction,' which uses a specific verb (create/update/delete) and a clear resource (Lunch Money transaction). The qualifier 'single' distinguishes this from sibling tools like bulk_update_transactions, split_transaction, and group_transactions, so the purpose is 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 provides explicit instructions for each action, listing required and optional parameters per operation. This gives clear context for when to use each mode. However, it does not explicitly mention alternatives like bulk_update_transactions for batch operations, nor does it state when not to use this tool, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses a critical constraint ('split amounts MUST add up to the parent transaction amount') and that unsplit 'restores it to normal', which gives some insight. But it omits details such as what happens to existing split data upon unsplit, potential errors (e.g., when amounts don't sum), or permissions needed, leaving significant behavioral gaps for a mutation 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 concise and well-structured, with a front-loaded sentence defining the verb and resource, followed by action-specific instructions. Every sentence earns its place, and it avoids unnecessary fluff. The two-paragraph structure makes it easy to scan for the relevant action.

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 moderate complexity (3 parameters with a nested split object) and detailed schema, the description covers the main usage comprehensively: both actions, required fields, and the sum constraint. However, since there is no output schema, the description could have explained what the tool returns or how errors surface, which is a gap. Still, it is fairly complete for a specialized mutation 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%, so the baseline is 3. The description reiterates parameter meanings but adds minimal new information beyond the schema, such as structuring usage by action. The sum constraint is already in the schema's split item description, so the description does not significantly enhance understanding of parameters beyond what the schema already provides.

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

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

The description clearly states 'Split or unsplit a Lunch Money transaction' with specific verbs and resource, immediately identifying the tool's core function. It distinguishes itself from sibling tools by focusing exclusively on split/unsplit operations, unlike manage_transaction or group_transactions which handle general edits or grouping.

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 context for when to use each action: action='split' requires id and splits array, action='unsplit' only requires the parent id. It clearly explains the required input structure for both modes, making the usage context unambiguous. However, it does not mention alternatives or explicitly state when not to use this tool, so it stops short of a perfect score.

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