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

The annotations already communicate that this is not read-only and is not idempotent, and the description's 'Add' only restates that mutation is involved. It does not disclose additional behavioral traits such as whether entries are appended, whether existing notes are modified, any permission requirements, or whether this action can be reversed.

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

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

The description is a single, front-loaded sentence with no wasted words. It states the core action and target resource immediately and remains appropriately sized for a simple 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 mutation tool with fully documented parameters, the description is minimally adequate: it names the action and resource, and the schema covers parameter meaning. However, it omits broader context such as output behavior, common use cases, or any relationship to sibling tools, and with no output schema the agent is left without information about what the call returns.

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 input schema fully documents all three parameters. The description adds little semantic value beyond indicating that the tool handles notes or activity logs, which is already reflected in the schema's type field.

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 ('Add') and the resource ('a note or activity log to a pipeline opportunity'), making the tool's function immediately understandable. It is distinguishable from siblings like create_opportunity or update_opportunity_stage, though it does not explicitly name any alternative.

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

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

The description implies the tool is used for adding notes or activity entries to an opportunity, but it gives no explicit when-to-use guidance and does not mention alternatives such as create_task or updating the opportunity. An agent would have to infer appropriate usage from the parameter schema and sibling 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it does not lock the period, it computes results from transactions, and it explicitly states 'does not change anything'. This goes beyond the annotations 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?

Three tightly written sentences: hook/purpose first, factual context second, usage triggers third. No filler or repetition of schema fields. Every sentence earns its place.

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

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

For a simple read-only tool with one well-documented parameter and strong annotations, the description provides sufficient context: what it computes, why it exists, and when to use it. It does not detail the output structure, but the '9-box' phrasing already conveys the result shape, and there is no output schema requiring alignment.

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

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

Schema description coverage is 100% and the single parameter period_id is already well documented, including a cross-reference to get_vat_periods. The description does not add additional parameter-specific meaning, so the baseline 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 states a specific verb 'Preview' and resource '9-box VAT breakdown' and immediately distinguishes the tool from lock_vat_period by clarifying it does NOT lock the period. It also explains the computation source ('period's transactions', 'same logic as the VAT page'), making the tool's role unambiguous.

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

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

Provides explicit trigger examples ('what's my VAT for this quarter', 'show me the 9 boxes') and an explicit pre-workflow ('before lock_vat_period so they can check first'). This clearly tells an agent when to invoke this tool instead of others like get_vat_summary or lock_vat_period.

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 says 'suggest,' which implies an analysis-only behavior, yet annotations declare readOnlyHint=false, so the side-effect profile is not reflected in the text. It does not disclose whether the suggestion is returned only or written back to the transaction, or what happens if the transaction is already categorized. Annotations cover idempotency and non-destructiveness but leave this mutation ambiguity unresolved.

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

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

A single front-loaded sentence conveys the operation with no filler or redundant restating of the tool name. It is concise without sacrificing clarity.

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

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

With no output schema, the description should explain what kind of suggestion is returned (category label, ID, confidence, reason) and whether the tool persists anything. It provides neither, and the readOnlyHint=false annotation makes the need for such context more pressing.

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 transaction_id is already documented and the description adds no additional meaning beyond confirming the target is a transaction. No enum, nested, or optional parameters need further explanation, so the baseline 3 is appropriate.

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

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

The description uses a specific verb ('suggest') with a specific resource ('category') and target ('transaction'), making the tool's job unmistakable. It is clearly distinct from siblings like create_transaction or update_transaction, which modify transaction records.

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 list_categories, create_transaction, or update_transaction. The phrase 'for a transaction' implies the trigger, but the description does not say whether this is a preliminary read-only suggestion or an actual categorization step, nor does it state prerequisites.

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, openWorldHint, idempotentHint, and destructiveHint false. The description adds crucial behavioral context: it queries a live external register (consistent with openWorldHint), explains that a 'not registered' result is a real answer not an error, and instructs the agent to report the registered name and highlight mismatches with the contact's name. This goes beyond annotations and is essential for correct usage.

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, front-loading the core purpose before diving into usage and behavioral nuances. Every sentence adds meaningful information: purpose, geographic scope, usage triggers, result interpretation, and reporting guidance. No wasted words; it is concise yet comprehensive.

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 only two parameters, no output schema, and annotations covering safety, the description fully covers what an agent needs: the exact function, the meaning of edge-case results, and how to handle the response (report name, flag mismatches). There is no missing critical information for correct invocation and use.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that vat_number can include or omit the GB prefix, and that contact_id is optional and used for reporting results against the contact. These details help the agent understand the intended usage beyond the raw 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 checks a UK VAT registration number against HMRC's live register and returns the registered trader name and address. It specifies 'GB only' and the exact use cases, effectively distinguishing it from sibling tools like get_vat_summary by focusing on validation against the live register.

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 when-to-use conditions: when the user asks about validity, when adding/editing suppliers/customers with VAT numbers, or when confirming a VAT number on a document. It also clarifies that 'not registered' is a legitimate answer. It does not explicitly mention alternative tools, but the 'GB only' constraint and the specific use cases make usage 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?

Annotations are all neutral (readOnlyHint=false, destructiveHint=false, etc.), so the description carries the full burden of disclosing side effects. It only says 'Record' without revealing what happens after creation: whether journal entries are created, whether balances are updated, whether the bill is reversible, or whether any authorization is required. This is a significant 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 a single 11-word sentence with no filler, and the key action and object are front-loaded. It is efficient and easy to parse. However, it does not provide any structured elaboration on context or behavior, so it earns a 4 rather than 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?

This is a mutation tool with no output schema and neutral annotations, so the description must provide sufficient operational context. It does not explain what the tool returns, what prerequisites exist (e.g., contact must already exist, dates must be valid), or downstream accounting effects (e.g., balance sheet impact). An agent cannot fully anticipate the consequences of invoking 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 coverage is 100%: every parameter (contact_id, bill_date, due_date, items, notes, bill_number) has a description in the schema. The tool description adds only the semantic context that the bill is a supplier liability, which is not parameter-specific. At high schema coverage, the baseline of 3 is appropriate; the description does not add further value.

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

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

The description states a specific action ('Record') and resource ('supplier bill/invoice'), and clarifies that it represents an accounts-payable obligation ('that the company owes'). This distinguishes it from siblings like get_bills (reading bills) and pay_bill (settling bills), and from generic create_transaction.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or exclusions (e.g., 'use for supplier bills only, not customer invoices'). The intended usage must be inferred from the tool name and schema, with no explicit routing among siblings like create_transaction or create_estimate.

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

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

Annotations already declare readOnlyHint=false (a write operation), idempotentHint=false (each call creates a new record), and destructiveHint=false (not destructive). The description merely confirms 'create', adding no extra behavioral context such as uniqueness constraints, required permissions, or response format. With annotations present, this is adequate but not enhanced.

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, front-loaded with the core action and resource, and includes a useful parenthetical list of allowed types. There is zero fluff; every word adds value. This is a model of conciseness for a simple 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 create-contact tool with 6 fully documented parameters and no output schema, the description is largely sufficient. It could be slightly more complete by noting the 'other' type (present in the schema but omitted from the description) or stating that a new record is created each call, but these are minor gaps. The annotations and schema cover the rest.

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

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

Schema description coverage is 100%, so every parameter (name, type, email, notes, phone, company_name) is already documented. The description adds no parameter-specific meaning beyond the schema, which sets the baseline at 3. It does not clarify optionality or valid values beyond what the schema states.

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

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

The description clearly states the verb 'create' and the resource 'contact', and specifies the accepted types (client, supplier, lead). This distinguishes it from other create tools like create_opportunity and create_transaction. 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 gives no explicit when-to-use guidance or exclusions. However, the purpose is self-evident from the name and description, so an agent can infer it is for creating a contact. It does not mention alternatives or scenarios where it should not be used, leaving the agent to rely on the resource type.

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

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

Annotations already declare readOnlyHint=false, so the agent knows this is a write operation. The description adds no further behavioral context (e.g., idempotency, side effects, response behavior), providing no value beyond the structured 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?

A single sentence with no filler words. The description is appropriately minimal and front-loaded, containing only the essential 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?

For a simple create operation with full schema coverage and annotations, the description is minimally adequate. However, it does not mention what the tool returns after creation or any constraints (e.g., uniqueness), but given the low complexity this is a minor 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%, so the schema documents all parameters. The description adds no additional meaning to the parameters, staying at the baseline for fully covered schemas.

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

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

The description states a clear verb ('Create') and resource ('tax or filing deadline'), which is specific enough. It distinguishes the action from listing deadlines (get_deadlines) but doesn't explicitly name the alternative or scope the deadline types beyond 'tax or filing'.

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

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

No guidance on when to use this tool versus other deadline-related tools like get_deadlines. It does not mention any prerequisites, alternatives, or exclusion scenarios, leaving the agent to infer 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 are all false, so they only signal that this is not read-only, not idempotent, and not destructive-but-declared. The description adds only the trivial fact that it creates a new record; it does not disclose side effects (e.g., whether the estimate is sent to the client, assigned a status, or becomes immediately visible), auth requirements, or post-creation behavior. With weak annotations, the description carries a burden it does not meet.

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

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

A single sentence with no filler, front-loaded with the verb and resource. Every word earns its place; 'new' reinforces the non-idempotent nature and 'for a client' clarifies the contact relationship.

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 mutation tool with 5 parameters and no output schema, the description does not explain what the tool returns (e.g., an estimate ID or generated document), nor the estimate lifecycle (draft vs. sent, whether it requires further approval). The schema covers inputs well, but the missing return-value and workflow context leaves an agent guessing about correct invocation.

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

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

Schema description coverage is 100%, so each parameter is already documented with names and formats such as 'Expiry date (YYYY-MM-DD)' and the items array structure. The description adds no parameter-level meaning beyond what the schema provides, so the baseline 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 uses a specific verb ('create') with a clear resource ('estimate/quote') and recipient ('for a client'). It distinguishes cleanly from sibling create tools like create_opportunity, create_contact, create_bill, and create_task, since the resource noun is unique and 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?

No guidance is given on when to use this tool versus alternatives, such as when to prefer create_estimate over create_opportunity or create_transaction, or how it relates to the read-side get_estimates. There are no usage conditions, prerequisites, or exclusions stated.

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

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

Annotations already indicate readOnlyHint=false and idempotentHint=false, so the agent knows this is a non-idempotent write operation. The description aligns by saying 'Create a new...' but adds no extra behavioral context such as whether an existing record is modified, what the default pipeline stage is, or that re-invocation creates duplicates. Some credit is given because the main behavior is transparent; however, no value beyond the annotations is provided.

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 names the action and resource with zero filler. It is appropriately sized for a tool whose schema carries the detailed parameter 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 straightforward create tool, the description is minimally viable but leaves gaps. It does not mention the return value (no output schema exists), what happens if optional fields like stage_id are omitted, or whether the created opportunity is immediately available via list_opportunities. Given the 8-parameter schema, a little more context would improve completeness, but the schema does cover the parameter list.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters and their semantics. The tool description adds no parameter-specific detail, such as rules for combining fields or defaults. Baseline of 3 is appropriate since the description does not need to compensate for schema gaps.

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 ('Create') and a clearly defined resource ('a new sales pipeline opportunity/deal'). It distinguishes this tool from other create_* tools by naming the business object, and even adds a synonym ('deal') to disambiguate. This is more informative than the title alone.

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 tool is for creating opportunities, but it gives no explicit guidance about when to use this instead of alternatives such as add_opportunity_note or update_opportunity_stage. The context is implied by the tool name and resource type, but no when-not-to-use or alternative-routing information is 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?

Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false. The description adds no behavioral context beyond 'create'—it doesn't mention whether creation is idempotent, what happens on duplicate titles, or any side effects. However, since annotations cover the basic safety profile, a 3 is appropriate; the description doesn't contradict 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, efficient sentence with no waste. It's front-loaded with the verb and resource. However, it's slightly under-specified for a tool with five parameters, but conciseness itself is good.

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 creation tool with full schema coverage and no output schema, the description is adequate but not rich. It doesn't mention return values, required fields beyond title, or any post-creation behavior. Given the tool's simplicity, this is a minimum viable description, but it could add context about what 'task' means in this system.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds no extra meaning beyond the schema—it doesn't explain relationships between parameters (e.g., type enum values) or provide examples. Baseline 3 is correct when schema does the heavy lifting.

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

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

The description states a clear verb and resource: 'Create a new task or to-do item.' This distinguishes it from read-only task tools like get_tasks, though it doesn't explicitly differentiate from create_deadline or create_transaction. The title and description align well.

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

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

No guidance on when to use this tool versus alternatives like create_deadline or create_transaction. The description implies general task creation but doesn't specify context, exclusions, or relationships to sibling tools. An agent would have to infer usage from the schema.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, but the description adds little beyond the word 'manually.' It does not disclose side effects like auto-categorization, VAT implications, or journal entry creation. The schema mentions auto-categorization, but that is structured data, not behavioral transparency in the description.

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

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

The description is a single concise sentence with no filler. It is well-structured and easy to parse, though it could convey a bit more detail without losing conciseness.

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 8 parameters, no output schema, and a large sibling list including update_transaction, categorize_transaction, create_bill, and create_estimate, the description is far too thin. It does not mention what the tool returns, typical usage scenarios, or how it relates to other transaction-related tools, leaving the agent to guess.

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 input schema thoroughly documents all 8 parameters. The description adds no extra meaning to any parameter; it simply restates the action. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly states the action ('Create') and the resource ('transaction'), and 'manually' hints at manual entry vs automated processes. It does not explicitly name siblings like update_transaction or create_bill, but the verb and resource are specific enough that an agent can infer the primary purpose.

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

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

There is no guidance on when to use this tool vs alternatives. No mention of when manual creation is appropriate, when to use create_bill or create_estimate instead, or any exclusions. The 'manually' hint is implicit but not actionable for tool 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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety and side-effect profile. The description adds context that this is an EOR-specific cost calculation, but does not disclose additional behavioral details such as what cost components are included or whether currency conversion applies. With strong annotation coverage, a 3 is appropriate.

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

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

Two sentences carry everything needed: the action and resource in the first sentence, and explicit usage triggers in the second. There is no fluff, redundancy, or irrelevant detail.

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

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

For a simple, read-only calculation tool with rich annotations and 100% parameter coverage, the description is largely complete. It identifies the intended use case and required inputs. It does not describe the return format or cost breakdown, but with no output schema and an obvious monetary result, this is a minor gap rather than a significant one.

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 all three parameters clearly documented: country full name, annual gross salary, and currency code. The description adds no additional parameter semantics beyond the schema, so the baseline 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 uses a specific verb and resource: 'Calculate the total cost of hiring someone in a specific country through Deel EOR.' It clearly identifies the tool's domain and naturally differentiates it from sibling deel_calculate_take_home_pay, since employer cost and employee take-home pay are opposite concepts.

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

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

The description gives explicit trigger phrasing: 'Use when the user asks "how much would it cost to hire in [country]?" or about employment costs abroad.' This is clear context, though it does not explicitly mention when not to use it (e.g., take-home pay questions), so it stops short of a full when-not/alternative statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety context is covered. The description adds minimal behavioral context by framing the operation as a calculation that accounts for deductions, but it does not disclose return format, supported countries, or calculation assumptions.

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

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

Two short sentences that each earn their place: the first states the core operation-galculation of take-home pay; the second gives direct usage guidance. No filler or repetition.

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

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

For a simple read-only calculator with fully documented parameters and annotations covering safety, the description is nearly complete. It omits specific return details diagnostic of the take-home amount, but that is largely inferable from the tool name and purpose.

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

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

Schema description coverage is 100%, so the schema fully documents salary, country, and currency. The description adds no additional parameter-level meaning beyond what the schema already provides, 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 clearly states the verb and resource: calculate take-home pay for a salary in a country, and reinforces it with the 'net pay, take-home salary, or deductions' trigger phrases. It is sufficiently distinct from siblings like deel_calculate_employment_cost, though it does not explicitly contrast itself against that sibling.

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

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

The description explicitly says when to use the tool: 'Use when the user asks about net pay, take-home salary, or deductions in a country.' This is clear contextual guidance, but it does not mention when not to use it or name alternative tools for related calculations.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the description's safety burden is small. It adds the detail that invoices are contractor payment invoices, but offers no additional behavior (e.g., default limit, pagination, or source specifics) beyond vocabulary already in the schema.

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

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

Two informative sentences plus a use-case sentence with no filler. It front-loads the core purpose, and each sentence earns its place, though the second sentence is slightly redundant with the first.

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, idempotent tool with optional parameters and no output schema, the description covers what it does and when to use it; the schema covers parameter details and annotations cover side effects. The only minor gap is not describing the response shape or clarifying how it differs from the non-Deel get_invoices sibling.

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

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

Both limit and statuses are fully described in the schema with default and filter values, so schema coverage is 100%. The description only hints at the 'payment history' use case and adds no new semantic information 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?

States a specific action ('Get') on a well-scoped resource ('invoices from the user's Deel account') and clarifies that these are contractor payment invoices. It distinguishes itself from the generic get_invoices sibling via the 'Deel' qualifier, though it does not explicitly name or contrast that alternative.

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

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

Explicitly provides use context: 'Use when the user asks about Deel payments, contractor invoices, or payment history.' This gives clear triggering conditions but does not state exclusions or alternative tools, 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful context that results show payments to contractors and that the tool serves as payment proof, but it does not mention pagination, ordering, or what the response contains beyond 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 short sentences, front-loaded with the core function and followed by a direct use-case pointer. There is no filler, repetition, or unnecessary commentary.

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

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

For a one-parameter read-only list operation with complete schema coverage, the description is nearly sufficient. The only minor gap is that it mentions 'specific Deel payments' while the schema offers no filter or payment ID parameter, which could slightly overstate precision.

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?

Because schema description coverage is 100% for the single optional limit parameter, the schema already carries the semantic weight. The description does not need to add parameter detail, so a baseline score of 3 is appropriate.

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

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

The description names a clear verb and resource: 'Get payment receipts from Deel showing payments made to contractors.' It also adds a targeted use case, but it does not explicitly distinguish this from sibling tools like deel_get_invoices or get_payroll_summary, so the differentiation is incomplete.

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

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

It gives explicit guidance: 'Use when the user asks about specific Deel payments or needs payment proof.' This is a clear trigger condition, though it does not state when not to use the tool or name an alternative for invoice-related requests.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds little beyond the purpose—it does not disclose pagination behavior, result shape, or any side effects. No contradiction exists, so a 3 is appropriate.

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

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

Two sentences with no wasted words. The core action 'List people...' is front-loaded, followed immediately by the usage trigger. Every part earns its place.

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

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

For a simple read-only list operation with one optional parameter, the purpose, when-to-use guidance, annotations, and schema are sufficient. Minor gaps remain, such as not describing the result format or whether the list is paginated, but these are not critical for invoking correctly.

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

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

Schema description coverage is 100% for the single optional 'limit' parameter, including its default of 20. The description adds no extra parameter details, but the schema already carries the burden, so the baseline 3 applies.

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

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

The description states a specific verb and resource: list people (contractors and employees) in the user's Deel organization. It is clear and distinct in scope, but it does not explicitly name or differentiate any sibling alternatives, so it falls just short of a 5.

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

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

It gives an explicit trigger: 'Use when the user asks about their Deel team, workforce, or contractor list.' This provides clear context for when to call the tool, though it does not state when not to use it or mention 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds scope ('from the user's Deel account') but doesn't disclose additional behaviors like pagination limits or response format. Since annotations cover the core traits, a 3 is appropriate – it adds some context but not rich behavioral detail.

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: the first is the core action, the second gives usage context. It is front-loaded with the primary purpose, has zero wasted words, and is appropriately sized for a simple list tool.

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

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

The tool has no output schema, so the description should hint at the return format, but it doesn't mention what the response contains (e.g., fields, pagination). While it's a read-only list, an agent might need to know whether it returns full contract details or just summaries. For a simple list tool, this is a moderate gap; the description could be more complete by noting the response structure.

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%: both 'limit' and 'statuses' have descriptions in the input schema. The tool description does not add any extra meaning about parameters, so it relies on the schema. Baseline 3 is correct as the description adds no additional 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 clearly states the tool's function: 'List contracts from the user's Deel account.' This is a specific verb (List) + resource (contracts) that immediately distinguishes it from sibling tools like deel_get_invoices or deel_get_people. The added context about contractors and team members reinforces its purpose without ambiguity.

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 provides when to use: 'Use when the user asks about their Deel contracts, contractors, or team members managed through Deel.' This gives clear context and scenario. However, it doesn't explicitly contrast with alternatives (e.g., 'For individual people use deel_get_people'), but the naming and description make the differentiation obvious 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?

Annotations already indicate destructive and non-read-only behavior. The description adds the specific refusal condition (refuses if transactions, invoices, bills, or other records are linked), which is valuable behavioral context beyond the annotations. No contradiction detected.

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

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

Two sentences with zero fluff. The action and the critical constraint are front-loaded, and the refusal condition is stated concisely. Every word earns its place.

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

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

For a destructive operation with two optional parameters and no output schema, the description covers the key behavioral requirements: deletion only for empty projects and refusal when linked records exist. It doesn't detail return values or idempotency, but annotations cover idempotency and the destructive nature is implied. This is sufficiently complete for an agent to call it correctly.

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

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

Schema description coverage is 100%, with both parameters (project_id and project_name) already well-documented. The description does not add additional meaning or clarification about which parameter to prefer, so it does not exceed the schema 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 action (Delete) and the resource (project/deal), and adds a critical scoping condition ('empty project/deal'). This distinguishes it from sibling tools like update_project and get_projects without needing to open schemas.

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

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

The description explicitly states the precondition (empty project/deal) and the refusal behavior when linked records exist. This guides when to use the tool, though it does not name alternative tools for non-empty projects. The condition is clear enough for an agent to decide correctly.

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

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

Annotations already cover read-only, idempotent, and non-destructive hints. The description adds genuine behavioral context beyond those: it returns candidate pairs, matched/unmatched transaction counts, date ranges, sample matched pairs, and an AI same-account verdict. It clearly states the tool does not mutate anything. Minor gap: no mention of possible latency or AI-based computation time, but this is not critical.

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 long but every sentence earns its place: it explains the duplicate-account scenario, the underlying user situation, what the tool returns, when to use it, and which sibling tool to use instead. Information is front-loaded with the core purpose first, and the read-only note is placed near the end without burying critical facts.

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

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

For a zero-parameter, read-only detection tool with no output schema, the description fully fills the gaps. It explains the return payload, the triggering user phrases, the domain problem (double-counted cash/P&L), and the read-only nature with a pointer to the merge sibling. Nothing an agent needs to invoke and interpret the result is missing.

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

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

The input schema has zero parameters and 100% coverage, so there is nothing to document. Baseline for zero parameters is 4, and the description compensates by explaining what the tool analyzes and what it returns, making the lack of parameters feel intentional rather than an omission.

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

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

The description states a specific verb and resource: 'Find manual bank accounts that look like the same real-world account as a live bank feed...' This clearly distinguishes the tool from siblings like get_bank_accounts or get_reconciliation_status by naming the duplicate-account detection scenario rather than a generic listing 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?

Explicit usage triggers are given: when a user reports wrong cash/balance after linking a bank, mentions a duplicate account, or asks about an inflated P&L. It also explicitly contrasts with the sibling alternative merge_bank_accounts, stating this tool is read-only and that merging is done separately.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations by revealing that the tool performs two types of matching (already-linked and AI-suggested) and on which fields. No contradiction with annotations exists.

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

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

The description is two sentences with no filler. The first sentence front-loads the core function and matching logic; the second adds output composition and concrete usage examples. Every sentence earns its place.

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

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

For a read-only tool with only two well-documented parameters and no output schema, the description is complete: it states what the tool does, how it matches, what it returns, and when to use it. No critical calling information is missing.

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

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

Schema description coverage is 100%, with both entity_type and entity_id already documented. The description adds general context about how entity matching works (amount, vendor, date, reference) but does not add parameter-specific detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states a specific verb ('Find') and resource ('documents related to an entity'), and adds matching criteria (amount, vendor, date, reference) and output types (already-linked and AI-suggested). It does not explicitly differentiate from sibling tools like search_documents or get_document_links, 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 explicit use cases with natural-language examples: 'are there any receipts for this transaction?' and 'find documents related to this invoice'. It provides clear context for when to invoke the tool, though it does not state when not to use it or name alternative tools, so it misses the 'explicit when/when-not/alternatives' threshold.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds value by specifying exactly what data is returned (accounting period, preparation status, next steps), which is context beyond the annotations. It doesn't mention rate limits or auth, but for a read-only status getter 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?

Two sentences with no filler. The core purpose and return value are front-loaded, and the usage guidance is concise. Every word contributes to clarity.

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 parameterless, read-only status tool, the description fully covers what it does, what it returns, and when to use it. No output schema exists, but the description enumerates the key result fields. Nothing essential is missing for an agent 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?

The tool has zero parameters and the schema has no properties, so there is nothing to document. Per guidelines, baseline is 4 for 0-param tools, and the description appropriately focuses on behavior rather than 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 the tool retrieves annual accounts preparation status for the current company, mentioning specific data points (accounting period, preparation status, next steps). It distinguishes from siblings like get_filed_accounts_history and get_deadlines by focusing on the preparation workflow rather than filed history or deadlines.

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

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

Explicitly lists example user intents that should trigger this tool ('annual accounts, Companies House filing, year-end accounts, or corporation tax deadline'), giving clear guidance on when to use it. No alternative tools are named, but the scope is well-defined and distinct from similar financial reporting tools.

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

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

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description's 'Read-only' restates that. It adds modest context by disclosing the report's grouping and bucketing behavior, but does not cover edge behavior such as whether only unpaid bills appear or how the as_of_date shifts buckets. 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 with no wasted words: definition front-loaded, then usage triggers, then safety caveat. The example phrasings earn their place as direct agent-routing signals. Slightly long, but every clause contributes.

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 report tool with 2 optional params, no output schema, and full schema coverage, the description is nearly complete: it implies the return shape via buckets, gives clear invocation triggers, and is consistent with annotations. Minor gaps are currency/format details and alternative routing (e.g., get_aged_debtors), which are non-critical for an agent deciding whether to call.

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

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

Schema description coverage is 100% — both as_of_date and contact_id are already fully documented in the schema. The description adds no parameter-level detail beyond that, so the baseline 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?

States a specific resource (aged creditors report), its structure (grouped by supplier), and precise ageing buckets (current/not-yet-due, 1-30, 31-60, 61-90, 90+). The 'creditors' framing clearly distinguishes it from the sibling get_aged_debtors, and the supplier-payment focus separates it from generic get_bills.

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 when-to-use guidance with concrete user phrasings ('who do I owe', 'what bills are due', 'show aged payables', planning supplier payments). However, it does not name alternatives or give when-not-to-use exclusions, so it stops short of the 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 read-only, idempotent, non-destructive, so safety is covered. The description adds useful behavioral detail about the report's output structure (grouping by contact, bucketing by days past due), which goes beyond the schema. 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?

Three sentences, front-loaded with the core definition, then usage triggers, and a final read-only note. No filler, every sentence earns its place.

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

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

For a simple read-only report with zero required parameters and no output schema, the description covers purpose, usage, and output shape. It doesn't mention pagination or result format, but these are less critical given the low 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 coverage is 100%, with clear descriptions for as_of_date and contact_id. The description does not add parameter-specific meaning beyond saying the report can be scoped, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the resource ('aged debtors report') and what it does: lists outstanding invoices grouped by contact with ageing buckets. The buckets are enumerated, and the 'debtors' wording differentiates it from the sibling get_aged_creditors.

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 explicit trigger queries ('who owes me money', 'what's in our debtors book', etc.) and a use case (picking clients to chase). It does not explicitly contrast with get_aged_creditors or state when not to use it, but the examples make the intended scenario clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: it returns a ranked list, each item includes a plain-English reason and where to fix it, and it advises proactively offering help. This goes beyond the annotations and clarifies the tool's output style and suggested follow-up action.

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, but the first is a long enumerative sentence listing many categories. While every sentence earns its place and the main action is front-loaded ('Return the proactive, ranked list...'), the list of examples could be slightly condensed without losing meaning. It is still well-structured and informative.

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

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

Given the tool has no parameters and no output schema, the description provides sufficient context: it describes what the list contains, the use cases, and the format of each item (reason and where to fix it). It does not mention pagination or limits, but for a 0-param tool this is not a significant gap. It is complete enough 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 tool has zero parameters, and the input schema is an empty object with 100% schema description coverage. Per the rubric, a baseline of 4 is appropriate when there are no parameters. The description does not need to explain parameter semantics, and it correctly focuses on the tool's behavior and output.

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 proactive, ranked list of everything needing the user's attention across the account, with specific examples (missing bank statements, unreconciled transactions, deadlines, etc.). This distinguishes it from sibling tools like get_deadlines or get_tasks, which focus on narrower domains. The verb 'Return' and the resource 'ranked list of attention items' are specific and 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 explicitly enumerates trigger phrases: 'Use whenever the user asks what they need to do, what's outstanding, what's missing, whether anything needs them, for a status check or 'what should I focus on'.' This provides clear usage context. It does not explicitly mention when NOT to use it or point to alternatives, but the trigger list is comprehensive enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The word 'current' adds a real-time semantics claim that is not in the annotations, which is a modest but genuine addition. No behavioral traits are contradicted.

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

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

The description is a single efficient sentence with no wasted words, and the key intent is front-loaded. It is terse but not padded; the main weakness is under-specification rather than verbosity, which is a conciseness strength.

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, safe read operation with one fully documented optional parameter, the description is minimally adequate. However, it does not clarify whether 'account' refers to a bank account, ledger account, or DLA account, and without an output schema the agent gets no hint of the return shape. Given the large sibling set, a bit more disambiguating context would be warranted.

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

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

Schema description coverage is 100%, so the single optional parameter (account_id) is fully documented in the schema itself. The description adds no further meaning about what account_id means, what the default behavior is, or how to select an account, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Get') with a clear resource ('current account balance'), so an agent knows the basic operation. However, it does nothing to differentiate from siblings like get_dla_balance, get_bank_accounts, or get_financial_snapshot, which all plausibly return balance-like data.

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

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

No guidance is given on when to use this tool versus alternatives such as get_dla_balance or get_bank_accounts, nor when the optional account_id should be supplied. The agent must infer the appropriate context entirely from the schema and sibling 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the point-in-time snapshot context ('as at a given date'), but does not disclose other behaviors such as report content, currency, or any limitations.

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 contributes to identifying the operation and its key parameter.

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 report with one optional parameter and full schema annotation, the description is largely sufficient to invoke the tool. However, it does not provide any information about the returned report's structure, which is minor given the tool's straightforward nature and the absence 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?

The input schema fully documents 'as_at' with format (YYYY-MM-DD) and default (today), giving 100% coverage. The description's phrase 'as at a given date' simply restates this parameter's purpose without adding extra meaning.

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

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

The description clearly identifies the action ('Get') and resource ('Balance Sheet report'), and adds the key temporal modifier 'as at a given date.' It doesn't explicitly name sibling alternatives like get_profit_and_loss or get_trial_balance, but the tool name itself is unambiguous among the report siblings.

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 given on when to use this tool versus alternatives. The description only restates the function; it doesn't mention appropriate contexts, exclusions, or relationships to sibling report tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description's 'List' phrasing is consistent with these hints but adds no additional behavioral context such as pagination, ordering, or what 'connected to the company' excludes.

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

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

A single short sentence with zero filler. The action, resource, and scope are all front-loaded with no wasted words.

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

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

For a zero-parameter, read-only list tool with annotations covering the safety profile, the description is nearly complete. The only gap is that the return shape is undocumented and there is no output schema, but this is minor for a simple list 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 tool has zero parameters and schema description coverage is 100% (empty schema), so there are no parameters for the description to clarify. Per baseline for 0-parameter tools, this dimension defaults to 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 states a specific verb ('List') and resource ('bank accounts') with a scope qualifier ('connected to the company'). It is clear and distinct from siblings like find_duplicate_bank_accounts, though it does not explicitly name any sibling to differentiate itself.

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 given on when to use this tool versus alternatives such as find_duplicate_bank_accounts, get_transactions, or get_balance. There is no indication of what problem this tool solves that siblings do not, so an agent must infer the usage 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 readOnly, idempotent, and non-destructive behavior, so the safety profile is covered by structured data. The description adds that results represent supplier liabilities, but it doesn't disclose default scope such as whether paid bills are included or how the set is ordered. With annotations present 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 short sentences that are easy to scan and front-load the core purpose. There is slight redundancy between 'owed by the company' and 'what you owe to suppliers', but no wasted clauses.

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 fully documented optional parameters and a safe annotation profile, the description is largely complete. The only noticeable gap is that it doesn't state the default status scope when no filter is applied, but the schema's status options and limit default mitigate this.

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

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

Schema description coverage is 100%: limit, status, and contact_id each have descriptions. The tool description adds no extra parameter-level guidance, which is fine under the baseline since the schema carries the full semantic load.

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?

Description names a specific verb and resource: get supplier bills/invoices owed by the company. It adds the semantic nuance 'shows what you owe to suppliers', which distinguishes this payable-focused tool from sibling get_invoices (likely customer invoices). No ambiguity about what the tool retrieves.

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 'owed by the company' gives enough context to know this is for supplier payables. However, it does not explicitly tell the agent when to choose this over get_invoices, get_aged_creditors, or other invoice tools, nor does it state exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context by explaining the jurisdiction-dependent behavior (GB vs other countries) and the nature of the output (a hint, not a computation). This goes beyond the annotations and helps set expectations.

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. It front-loads the core purpose, then provides jurisdiction-specific detail, and ends with explicit usage guidance. Every sentence adds value, and there is no redundancy or filler.

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

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

For a single-parameter, read-only tool with a clear purpose and usage guidance, the description is complete. It explains what the tool does, when to use it, and what kind of output to expect (a hint, not a computation). The lack of an output schema is acceptable because the description sets expectations for the nature of 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?

Schema description coverage is 100%, so the schema already documents the single parameter (asset_id) and its source (from get_fixed_assets). The description adds context by explaining that the asset is a fixed asset and that the hint is specific to that asset, which reinforces the parameter's meaning without needing to repeat schema details.

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

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

The description clearly states the tool's purpose: it provides a tax capital allowance hint for a fixed asset, distinguishing between GB companies (AIA/WDA guidance) and other countries (jurisdiction note). It also explicitly differentiates from a filing computation, which helps an agent understand the tool's scope.

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 when to use the tool: 'Use when the user asks about capital allowances, AIA, or tax relief on a specific asset — not a filing computation.' This provides clear usage guidance and excludes a common alternative use case, making it easy for an agent to decide when to invoke 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds substantial behavioral detail by enumerating exactly what data is returned (e.g., projected low point, recurring patterns, tax deadlines). It does not disclose potential limitations like data freshness or assumptions, but it goes well beyond the annotations.

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

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

The description is a single long sentence that packs a lot of useful information without redundancy. It front-loads the main purpose ('13-week cash-flow forecast') and then lists specific outputs and usage triggers. It could be split into two sentences for readability, but it is not overly verbose.

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

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

With no output schema, the description must convey what the tool returns, and it does so comprehensively by listing the key outputs. It also gives usage context. Minor omissions like historical data coverage or accuracy caveats are not critical for a read-only forecasting tool, so it is largely complete.

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

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

The tool has zero parameters, so the schema is fully covered. The baseline for no parameters is 4, and there is nothing to add in the description about parameters. The description focuses on outputs instead, which is appropriate.

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

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

The description clearly states the tool's purpose: it returns a 13-week cash-flow forecast with specific components (current balance, weekly inflows/outflows, running balance, projected low point, recurring patterns, outstanding invoices, tax deadlines). The verb 'get' and resource 'cash flow forecast' are explicit, and the detailed output list distinguishes it from siblings like get_balance or get_transactions.

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

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

The description explicitly specifies when to use the tool: when the user asks about cashflow, runway, 'can I afford X', 'when will I run out', or wants to plan ahead. This is clear guidance, though it does not mention alternatives or situations where it should not be used, so it falls short of a perfect 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context beyond the schema and annotations, such as response shape, ordering, or any side effects. It does not contradict the annotations.

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

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

The description is just two sentences and wastes no words. The first sentence states the core operation, and the second gives concrete user-intent triggers. It is properly front-loaded and easy to scan.

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

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

For a simple read-only list tool with full schema coverage and clear safety annotations, the description is nearly complete. The only gap is that it does not describe the return format, but the absence of an output schema and the low complexity make this a minor omission.

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

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

The schema has 100% coverage for the single optional 'type' parameter, including its possible values. The description does not add any meaning beyond what the schema already provides, which aligns with the baseline of 3 for high schema coverage.

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

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

The description states a clear action and resource: 'List account categories (chart of accounts).' It also expands on the meaning via 'account codes' and 'available categories for categorizing transactions.' However, it does not explicitly distinguish itself from the sibling tool 'list_categories', so it misses the top score for sibling differentiation.

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

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

The description gives explicit trigger conditions: 'Use when the user asks about their chart of accounts, account codes, or available categories for categorizing transactions.' This is practical and direct, but it does not mention when not to use it or point to an alternative 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds no extra behavioral details beyond the listing intent, such as response format or filtering behavior, but it does not contradict annotations. With strong annotation coverage, this matches the baseline.

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 core action is front-loaded, and the usage hint is placed second. Every word earns its place.

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

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

For a simple read-only list tool with 100% parameter schema coverage and rich annotations, this description is complete. The optional parameters are self-explanatory, and no output schema is required for such a straightforward retrieval 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?

Schema description coverage is 100%, so the schema already fully documents all three parameters including their meaning and defaults. The description's mention of 'clients, suppliers, leads' loosely mirrors the type parameter but does not add new semantic value beyond the schema. Baseline 3 is appropriate.

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

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

The description names a specific verb and resource: 'List contacts', and clarifies the scope with examples (clients, suppliers, leads). This clearly distinguishes the read operation from sibling write tools like create_contact. The tool's function is immediately understandable.

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

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

The description explicitly says 'Use when user asks about customers, suppliers, or contacts,' providing a clear trigger condition. It does not explicitly name alternatives or exclusions, but for a simple list tool the primary usage context is well covered.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds the 'upcoming' scope, useful behavioral context, but it does not disclose output fields, date-range behavior, or formatting. 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 sentence with no filler. It front-loads the action and resource, and every word earns its place. It is appropriately sized for a simple read-only 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?

Given the low complexity and helpful annotations, this is minimally sufficient, but it lacks an output schema or any description of what the returned deadlines look like. It also does not connect to create_deadline or other related tools, 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 schema already provides 100% coverage for the single parameter include_completed. The description adds only the 'upcoming' context, which hints at default exclusion of completed deadlines, but contributes no additional parameter semantics beyond the schema.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource as 'upcoming tax and filing deadlines'. It is clear and unambiguous, but it does not explicitly distinguish itself from siblings like create_deadline or get_tax_facts, 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?

No usage guidance is provided. The description does not say when to prefer this over related deadline or tax tools, nor does it identify alternatives or exclusions. An agent must infer when and how 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds domain context (dividend records, shareholder payments) but no additional behavioral details such as pagination, filtering behavior beyond the schema, or return format. This is acceptable given the annotations.

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

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

The description is two sentences with no fluff. The core action and resource are front-loaded, and the usage guidance directly follows. Every sentence earns its place.

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

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

For a simple read-only list tool with fully documented parameters and safety annotations, the description is complete. It clearly states what the tool returns conceptually and when to invoke it; no output schema is needed for this level of simplicity.

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

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

Schema description coverage is 100%, so both parameters (limit and tax_year) are already documented in the input schema. The description adds no parameter-level meaning, which warrants the baseline score of 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 uses a specific verb and resource ('List dividend records') and gives concrete user intents ('dividends paid', 'dividend history', 'shareholder payments'). This is unambiguous and clearly distinguishes the tool from the many sibling tools.

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

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

The description explicitly states when to use the tool: 'Use when user asks about dividends paid, dividend history, or shareholder payments.' It provides clear context but does not mention exclusions or alternatives, 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context by noting the tool shows balance, transactions, and section 455 tax warnings, which is beyond the annotations. It does not introduce any contradictions and provides useful behavioral specifics.

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 main action and resource, then adds the key output details. Every word earns its place, and it is appropriately short for a simple read-only 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?

Given there is no output schema, the description provides essential output context: balance, transactions, and tax warnings. It also implies the return of a list of transactions via the 'limit' parameter. While it does not detail exact fields or pagination, the description is adequate for a tool with a single optional parameter and read-only 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?

The schema description covers the single 'limit' parameter fully with 'Max number of transactions to return (default 10)'. The tool description does not add any additional meaning for this parameter, so it meets the baseline of 3 given 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 states a specific verb and resource: 'Get the Director's Loan Account (DLA) balance and recent transactions.' It also explains the output's significance (whether director owes company or vice versa) and mentions a key detail (section 455 tax warnings). This clearly distinguishes it from other balance tools like get_balance or get_trial_balance, which target different 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 through its name and purpose (DLA queries) but does not explicitly state when to use this tool over alternatives, nor does it list any exclusions or alternative tools. An agent can infer usage, but the guidance is not explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which fully covers the safety profile. The description adds no additional behavioral details (e.g., pagination, limits, or error behavior), but it also does not contradict annotations. Since the description adds little beyond the annotations, a 3 is appropriate.

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

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

Two sentences with zero redundancy. The first sentence states the function and scope, the second provides usage examples. Information is front-loaded and every word earns its place.

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

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

For a simple read tool with no output schema and all parameters optional, the description does not explain the implicit requirement that at least one of entity_id or document_id must be provided, nor does it describe the return format. While the core purpose is clear, this omission could lead to incorrect calls.

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

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

Schema description coverage is 100%, so all three parameters are already documented with descriptions. The description does not add meaning beyond the schema—it does not clarify that entity_id and document_id are likely mutually exclusive, or that entity_type is required when entity_id is used. Baseline 3 applies because the schema carries the semantic load.

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

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

States a specific verb (get) and resource (documents linked to an entity or entities linked to a document), with a concrete list of entity types. Clearly distinguishes its bidirectional nature from siblings like search_documents and find_related_documents, even without naming them.

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

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

Provides two explicit user-phrase examples ('what documents are attached to this invoice?' / 'show me what's linked to that receipt') that indicate when to use the tool. Does not mention alternatives or when not to use it, but the context is clear enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a scoping detail ('sent to clients') but does not explain behaviors like pagination, default limits, or the inclusion of draft estimates. This is acceptable given the strong annotations, but the description adds limited behavioral context 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 a single front-loaded sentence with no filler or redundancy. It efficiently states the verb, resource, and scope qualifier, earning its place despite the slight ambiguity in 'sent to clients'.

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 tool with three optional, fully documented parameters and no output schema, the description is minimally sufficient. It omits what the returned estimates look like and does not reconcile 'sent to clients' with the draft/all status values, but the annotations and schema carry most of the load.

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 100% description coverage for all three parameters (limit, status, contact_id), so the baseline is 3. The tool description does not add any parameter-level meaning 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 states a clear verb ('Get') and resource ('estimates/quotes'), which distinguishes it from create_estimate and other non-estimate tools. However, the phrase 'sent to clients' is slightly ambiguous because the status filter includes 'draft' and 'all', so the exact scope is not fully pinned down.

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 given about when to choose get_estimates over alternatives like create_estimate, get_invoices, or other list/get tools. The description implies a read operation but provides no exclusions or selection 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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds no behavioral traits beyond that—it does not mention that it returns a list, supports filtering via status, or any pagination details. It merely restates the tool's purpose without additional behavioral context.

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

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

The description is a single, efficient sentence: 'Get expense claims and reimbursement requests.' It front-loads the action and resource, with zero unnecessary words. 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?

For a simple tool with two optional parameters and annotations covering safety, the description is minimally sufficient. However, it does not differentiate from the sibling 'get_expenses', which is a similar tool, nor does it mention any response format or limitations. Given the potential confusion with a sibling, the description is not fully complete for an agent to select 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?

The schema provides descriptions for both parameters (limit with default 20, status with allowed values), so schema coverage is 100%. The description adds no extra meaning about the parameters, so it does not improve on the schema. Baseline 3 is appropriate since the schema carries the 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 states a clear verb+resource: 'Get expense claims and reimbursement requests.' It is specific enough to distinguish from many siblings like get_transactions or get_journal_entries, but there is a close sibling 'get_expenses' that could cause confusion. The description does not explicitly differentiate, so it loses a point for lacking sibling 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?

There is no guidance on when to use this tool versus alternatives. It does not mention that get_expenses might be a better choice for certain scenarios, nor any context about when expense claims are relevant. The description implies usage but provides no explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful scoping hint that it lists user-submitted expense claims rather than all expenses, but it does not disclose response shape, ordering, pagination, or any auth expectations. This is moderate added context 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 the core action front-loaded, followed directly by when-to-use guidance. There is no fluff, repetition, or unnecessary detail.

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

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

For a simple read-only list tool with two optional parameters and full schema coverage, the description gives an agent enough to invoke it correctly. The notable gap is the unresolved overlap with the get_expense_claims sibling, which prevents full completeness.

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

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

Schema description coverage is 100%, with both 'limit' and 'status' already documented including defaults and allowed status values. The description does not add parameter-level meaning, so it stays at the baseline 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 gives a clear verb ('List') and resource ('expense claims'), and ties it to user-facing terms like reimbursements and receipts. However, there is a sibling tool named get_expense_claims that appears nearly identical, and the description does not differentiate between them, so it does not earn 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 explicitly states when to use the tool: when the user asks about expenses, expense claims, reimbursements, or submitted receipts. This is clear context, but it offers no exclusions or alternatives, especially failing to clarify when to prefer get_expenses over get_expense_claims.

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 correctly adds deeper behavioral context rather than repeating them: the data is a registry snapshot rather than the live ledger, the agent should present it 'as filed', and micro-entity filings should be reported as lacking turnover/profit rather than coerced to zero. This is exactly the kind of interpretive guidance annotations cannot express.

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

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

The description is dense (~100 words) but every clause earns its place: content inventory, usage triggers, provenance warning, and the micro-entity caveat. The most decision-relevant information (what it returns) is front-loaded, though the opening sentence is long and could arguably be split.

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

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

For a zero-parameter, read-only tool with no output schema, the description is fully self-sufficient: it explains what data comes back, the ordering (newest first), the edge case for micro-entities, and how to present results. An agent has everything needed 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?

The tool has zero parameters and schema coverage is 100%, so the baseline is 4 per the rubric. The description does enrich the semantics by explaining what the returned figures represent and how to interpret edge cases like micro-entity nulls, which compensates for the absence of an 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 opens with a specific verb-resource pair ('year-by-year figures from the accounts this company has filed at Companies House, newest first') and enumerates the exact content: balance sheet lines, average employees, turnover, profit after tax, and reserves movement. It differentiates from sibling tools by contrasting registry snapshots with the live ledger, so an agent can distinguish it from get_profit_and_loss or get_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?

It gives explicit when-to-use triggers ('Use when the user asks how last year or an earlier year went, how the business has grown, what was filed, or wants past figures beside the current books') and a clear when-not: never blend these registry figures with live ledger numbers. It stops short of naming specific alternative sibling tools, but the ledger contrast effectively routes the agent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it returns 'the EXACT numbers on the user's Home dashboard', which tells the agent the values are dashboard-scoped and not computed differently. It also implies a consolidated snapshot rather than a detailed report. Minor gap: no mention of time period for 'this month' or currency, but the dashboard reference anchors it.

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

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

Three sentences, each earning its place: the first defines the resource and scope, the second lists trigger phrases, the third routes to alternatives. The most important information (what the tool returns) is front-loaded, and the alternative routing is compactly placed at the end.

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

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

For a zero-parameter, read-only, idempotent tool with no output schema, the description is complete. It tells the agent what figures are included, when to use it, and which siblings to use instead. There is no missing information an agent would need 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?

The tool has zero parameters, so the schema provides no parameter semantics. The description compensates by clearly defining what the tool returns (cash, open invoices, open bills, net profit this month), which is the only semantic content an agent needs for a no-arg call. Baseline 4 for 0 params 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 ('Get') and resource ('financial snapshot'), and enumerates exactly what figures are included: cash, open invoices, open bills, and net profit this month. It also explicitly ties the tool to the user's Home dashboard, which distinguishes it from sibling tools like get_profit_and_loss, get_balance, and get_invoices.

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

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

The description gives explicit when-to-use guidance with example queries ('how am I doing', 'how much am I owed', 'what do I owe', 'what's my position') and explicitly names alternatives for other use cases: get_invoices/get_bills for line-level detail, and get_aged_debtors/get_aged_creditors for ageing. This is model routing 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 carry the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description adds modest behavioral context by listing return fields and the status filter, but does not disclose ordering, whether disposed records are included by default (the schema covers the default), or any volume/pagination traits. 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?

Three sentences, each earning its place: purpose, usage trigger, and filter capability. The most identifying information is front-loaded, and there is zero filler or repetition of annotation data.

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 enum parameter and no output schema, the description covers the essentials: what fields come back, when to use it, and how to filter. With no output schema, it compensates by naming the returned fields. Minor omissions like result ordering or pagination are low-stakes for an asset-register list.

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

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

Schema description coverage is 100%, so the schema fully documents the status parameter including its enum values and default. The description's 'Filter by active, disposed, or all' merely restates the schema, adding no new meaning. The baseline 3 applies because the schema is doing the heavy lifting.

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

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

The description names a specific verb and resource ('List fixed assets on the register') and enumerates the exact fields returned (cost, net book value, monthly depreciation, status). This is specific enough that an agent can distinguish it from the broader accounting siblings like get_balance_sheet or get_expenses without opening the schema.

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

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

'Use when the user asks about their asset register, depreciation schedules, NBV, or capital items tracked per asset' gives explicit triggering conditions. It stops short of a 5 because it names no alternatives or exclusions (e.g., when to prefer get_capital_allowance_hint for tax-side depreciation), leaving some routing decisions to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only domain context ('business/financial') but no additional behavioral details such as default status behavior, empty result handling, or pagination. Consistent with annotations, so 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?

Two sentences with no redundancy. The core function is front-loaded, and the usage trigger follows immediately. Every word earns its place.

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

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

For a simple read-only tool with two optional parameters and strong annotations, the description is adequate. It communicates purpose and usage clearly. The lack of return-value information is a minor gap since no output schema exists, but it does not impede correct invocation.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters (status and goal_type) and their allowed values. The description adds nothing beyond the schema, matching the baseline of 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 states a specific verb ('Get') and resource ('active business/financial goals and their progress'). This clearly identifies what the tool does and distinguishes it from sibling tools like get_tasks or get_projects, since no other sibling targets goals.

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 specifies when to use the tool: when the user asks about goals, targets, or tracking against objectives. It provides clear context but does not mention alternatives or exclusions, which is acceptable given no direct sibling tool for goals exists.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the context that it is 'official GOV.UK' guidance, which is useful, but does not mention any rate limits, pagination, or return format. With annotations covering the core behavior, a 3 is appropriate.

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

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

Two sentences, front-loaded with the core purpose and followed by usage examples. Zero fluff, every word contributes. Highly efficient.

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

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

With one simple parameter, no output schema, and safety annotations covering the behavioral aspects, the description is sufficient. It explains the source (GOV.UK) and when to use it. The only minor gap is not describing the return format, but for a search tool this 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 description coverage is 100%, so the parameter 'topic' is fully documented with examples. The description does not add any additional parameter-level meaning beyond what the schema provides. Baseline 3 applies.

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

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

The description states a clear verb and resource ('Search official GOV.UK tax and business guidance'), and provides specific example topics. It does not explicitly name a sibling tool for differentiation, but the purpose is unambiguous and distinct from the many accounting/finance tools.

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

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

It gives explicit conditions for use ('Use when the user asks... what does HMRC say about X?', tax rules, filing requirements) and lists example topics. It lacks an explicit 'when not to use' or named alternatives, but the context is clear enough to route the agent correctly.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds valuable context beyond this: the data comes directly from HMRC MTD and requires an active HMRC MTD connection, which is a useful precondition for the agent to know.

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 focused sentences with no filler: it states what the tool reads, when to use it, and what prerequisite exists. Each sentence provides distinct value and the core purpose 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?

Given the tool's low complexity, optional parameters fully covered by the schema, and rich annotations, the description covers all essential operational context: purpose, usage examples, source, and required integration. Nothing critical is missing for an agent to decide whether to call it.

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 both 'from' and 'to' parameters are already documented with their formats and defaults. The description does not add new parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb ('Read') and resource ('company's VAT liabilities') and clarifies what those liabilities are: amounts HMRC says are owed and when they are due. This clearly separates it from related tools like VAT payments or obligations by focusing on outstanding amounts owed.

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

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

The description explicitly tells the agent when to use this tool, citing natural user phrasings like 'how much VAT do I owe HMRC' and 'what's outstanding on my VAT account'. It does not mention exclusion criteria or name alternative tools, 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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context beyond that: the data comes from an external authoritative source (HMRC MTD), the exact shape of returned obligations, and the connectivity requirement. No contradiction between description and annotations.

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

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

Three sentences, each earning its place: the first states core function and output content, the second gives usage triggers, the third states the prerequisite. The core function is front-loaded, and the entire description is roughly 55 words with zero fluff 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?

For a moderate-complexity tool with no output schema, the description adequately covers what is returned (period keys, dates, fulfillment status), the external source, and the prerequisite. Annotations cover the safety and idempotency profile. A minor gap is that it doesn't hint at checking HMRC MTD connectivity first (e.g., via the sibling tool get_integration_status), nor does it address error behavior if unconnected.

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%: both 'from' and 'to' parameters already have descriptions specifying format (YYYY-MM-DD) and defaults in the schema. The description does not add parameter-level meaning beyond what the schema already provides. Since the schema carries the full burden, 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 uses a specific verb ('Read') with a precise resource ('VAT obligations ... directly from HMRC MTD') and enumerates the exact data fields (period keys, start/end dates, due dates, Open/Fulfilled status). This clearly distinguishes it from siblings like get_hmrc_vat_payments and get_hmrc_vat_liabilities, which concern different data types.

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?

Three concrete trigger phrasings are provided ('what does HMRC say I owe a return for', 'when is my next VAT return due according to HMRC', 'reconcile our periods against HMRC's record'), which give the agent clear conditions for selection. The prerequisite ('Requires HMRC MTD connected') is stated. However, alternatives are not named explicitly, and there is no when-not-to-use guidance against similar siblings like get_vat_periods.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is well covered. The description adds meaningful operational context: data comes directly from HMRC MTD and the tool requires HMRC MTD to be connected. No contradiction with annotations exists.

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 short sentences contain only high-signal information: the operation, example triggers, and a prerequisite. The core action is front-loaded and no sentence is wasted.

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

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

For a simple read-only list tool with optional date parametersholidays, the definition is largely complete, especially with annotations covering the safety profile. It could mention the return shape or explicitly route to liability/obligation tools, but nothing essential is missing for calling 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?

Both parameters are already fully documented in the schema with formats and defaults (YYYY-MM-DD, today, ~18 months ago), giving 100% coverage. The description does not add parameter-level detail, so the baseline 3 applies.

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

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

The description opens with a specific verb ('Read') and an unambiguous resource: the VAT payments HMRC has received on the company's account. The example user phrasings further pin down the intent)Skip and the resource is clearly distinct from HMRC VAT obligations or liabilities.

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 concrete trigger questions and states the HMRC MTD connection prerequisiteclude. It does not explicitly say when not to use the tool or name alternatives such as get_hmrc_vat_liabilities, but the usage context is clear enough for correct selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description correctly aligns. It adds behavioral context beyond the annotations: the tool aggregates and does not return raw transactions, it defaults to income direction, and it includes a functional-currency total in the same set. No contradiction exists.

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: it opens with the core function, immediately follows with usage examples, then gives an exclusion, and ends with the default. Every sentence adds value; there is no redundancy or 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 read-only, idempotent tool with only three optional parameters and no output schema, the description fully covers what the agent needs: what it returns (aggregates, not transactions), the distinction between face and functional-currency totals, the direction default, and the explicit warning against using get_transactions. No critical information is missing.

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

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

Schema description coverage is 100%, with each parameter (to_date, direction, from_date) already described in the input schema. The description reiterates the direction default ('Defaults to money-in') and clarifies that direction 'out' means spend, but this largely mirrors the schema. It does not add new parameter-specific semantics beyond the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool returns currency-split income or expense totals, including both face amounts per transaction currency and the functional-currency total. It uses a specific verb ('returns') and resource ('currency-split income/expense totals'), and explicitly differentiates from the sibling get_transactions by noting it returns aggregates only and not a transaction dump. This leaves 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 gives explicit when-to-use triggers with concrete user phrasings ('total income in EUR and in GBP', 'income by currency') and a clear exclusion ('Do NOT page get_transactions to sum'). It also explains the default direction and how to switch to expense mode, providing complete routing 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 and idempotentHint true-delegating the safety profile to structured metadata. The description adds valuable behavioral context beyond annotations: it reveals the tool returns flowing/quiet/error states, last event, 7-day counts, and error messages, and it discloses that API keys are never returned, only connected status. This materially enriches what an agent knows about the call before invoking it.

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 front-loaded with the primary result and scope, followed by clear usage triggers, then precise connection-interaction instructions. Although it is longer than average, every sentence adds actionable information for the agent, and the structure is well organized.

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 zero parameters and rich annotations, the description is fully sufficient for an agent to select and call this tool correctly. It covers the result fields, common failure interpretation, and the exact format for offering a connection, leaving no critical gap in a tool with no output schema.

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

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

The tool has zero parameterschers, so there is no schema burden to describe. With no parameters, the baseline is 4, and the description properly conveys that no filtering is needed because the tool returns all integrations for the current company/user context in one call.

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

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

The description uses a specific verb and resource: 'See every integration for this company and user in one call.' It clearly enumerates what the tool reports (connected, available but not connected, flowing status) and distinguishes its scope from the rest of the sibling tools by focusing entirely on integrations.

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

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

It gives explicit when-to-use guidance: when the user asks about connections or channels, when something needed is not connected, or when data looks stale or missing. It also explains when a dead feed is the real cause and even provides the exact action to offer a connection, which is far beyond minimum guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds useful context about the result scope ('summary stats on outstanding and overdue amounts') but does not reveal further behavioral details such as pagination, limits, or filtering semantics.

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 waste. It leads with the action and object, then gives a direct usage condition. Every word earns its place.

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

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

For an optional-parameter, read-only tool with complete schema coverage and strong annotations, the description is sufficient. It characterizes the return content broadly and gives use cases, and the lack of an output schema is partially mitigated by the mention of summary stats. A more detailed output description would help but is not necessary 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?

The input schema has 100% description coverage, with each parameter (search, status, contact_id) already explained. The description adds no additional parameter-level meaning, so the baseline 3 applies.

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

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

The description clearly states the verb and resource ('Get invoices the user has raised') and adds scope by including summary stats on outstanding and overdue amounts, which distinguishes it from bills and estimates. It does not explicitly name a sibling alternative like get_recurring_invoices, so it stops just short of a 5.

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

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

It provides explicit trigger context: 'Use when user asks about invoices, outstanding payments, or money owed to them.' This gives the agent a clear sense of when to select the tool, though it does not mention when not to use it or compare it with related tools like get_aged_debtors.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral disclosure beyond that—no mention of ordering, pagination, date inclusivity, or any hidden side effects. 'Get' simply echoes the read-only nature already captured by 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 short and front-loaded: the resource is named immediately and the double-entry clarification adds value without fluff. Slight redundancy exists with the title ('Get Journal Entries' vs 'Get General Ledger journal entries'), but the extra context earns its place.

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

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

For a simple read-only tool, the schema and annotations cover basic safety and parameters. However, the description lacks any usage context and does not explain what a returned journal entry looks like or how date filtering behaves, making it minimally adequate but not complete.

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

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

Schema description coverage is 100%, so limit, to_date, and from_date are already documented in the input schema. The description adds no additional parameter semantics, which is acceptable given the schema coverage baseline of 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 names a specific verb ('Get') and resource ('General Ledger journal entries'), and adds a clarifying domain cue ('Double-entry accounting records'). It does not explicitly distinguish itself from similar siblings like get_transactions, so it stops short of a 5.

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

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

There is no guidance about when to use this tool versus alternatives such as get_transactions, get_trial_balance, or get_profit_and_loss. The description states only what the tool returns, not the conditions or use cases that should trigger 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?

Beyond annotations that already declare readOnly, idempotent, and non-destructive behavior, the description adds meaningful detail: the returned confidence metric, the exact exception categories, the default period behavior, and the instruction to surface the message and offer to clear exceptions. This is strong behavioral transparency 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 dense but not bloated. It front-loads the core purpose and output, gives concrete usage triggers, states defaults, and ends with an actionable instruction. Every sentence earns its place.

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

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

With no output schema, the description carries the full burden of explaining what the tool returns, and it does so thoroughly: close-confidence percentage plus all the key exception categories. It also covers default behavior and post-invocation guidance, so an agent has enough to select and 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?

The sole parameter is already fully covered by the schema, which specifies the format (YYYY-MM-01) and the omit-for-last-complete-month behavior. The description repeats the default behavior but adds no new parameter meaning, so the baseline 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 uses a specific verb and resource ('Check how closed a month's books are') and details the exact output: a close-confidence percentage plus the specific exception categories. However, it does not explicitly differentiate from the similar sibling tool 'month_close_summary', so it stops just short of full sibling distinction.

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

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

Gives clear trigger phrases ('is my month done?', 'close my books', 'what's left for May?') and a general close/period-end rule, plus the default to the last complete month. It does not mention when not to use this tool or name an alternative, but the context is sufficiently clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return scope (notes and activity history) but does not disclose other behavioral details such as what happens for invalid IDs or required permissions. This is adequate given the annotation coverage, but adds limited new context.

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

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

A single, front-loaded sentence that states the action, resource, and included content with no wasted words. It is appropriately concise for a simple read 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 one-parameter read operation with safety annotations, the description is largely complete: it names the specific resource and the expected data scope. It could additionally mention how to handle nonexistent IDs or how returned data relates to the input ID, but these are minor gaps for such a 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 input schema has 100% description coverage for the single parameter ('Opportunity/project ID'), so the description does not need to add parameter details. It does not add extra semantics beyond the schema, which matches the baseline of 3 for high schema coverage.

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

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

The description uses a specific verb ('Get') and resource ('specific pipeline opportunity/deal'), and further clarifies the scope by mentioning notes and activity history. This clearly distinguishes it from list_opportunities (plural, list orientation) and other project/opportunity 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 implies the tool is for fetching details about a single opportunity, but it does not explicitly state when to use it versus alternatives like list_opportunities or get_projects. No exclusions or alternative tool names are provided, so the usage 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds what data the summary includes but no deeper behavioral context like return formatting, data source, or edge cases. 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?

Two concise sentences: the first leads with the operation and result contents, the second states when to use it. Every sentence earns its place with no filler.

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

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

For a read-only tool with zero required parameters and no output schema, the description names the key returned information and gives clear invocation triggers. It could mention how tax_year affects the summary, but the schema already covers that, so the definition is nearly complete.

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

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

The schema covers 100% of parameter documentation, including an example and the default behavior for tax_year. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Get') and names a concrete resource with enumerated contents: year-to-date payroll figures, last run date, and next payment due. This clearly differentiates it from finance siblings like get_vat_summary or get_profit_and_loss.

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 'Use when' clause gives explicit user intents: payroll costs, total salary spend, or next payroll run. This is clear context, though it does not name alternatives 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds little beyond the period scoping; it does not disclose response structure, default date behavior, or calculation specifics, but it also does not contradict the annotations.

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

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

The description is a single, front-loaded sentence with no filler. Each term adds meaning: the tool name, the income-statement clarification, and the period scope. It is appropriately concise, though it could have packed in more useful guidance without becoming verbose.

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 report with two well-documented date parameters, the minimal description is mostly sufficient when combined with annotations. However, with no output schema and both parameters optional, the agent is left to infer default behavior and return format, which is a notable 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%, with from_date and to_date already documented as YYYY-MM-DD strings. The description's 'for a period' aligns with these parameters but adds no extra semantics such as defaults, requiredness implications, or range constraints.

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 a specific verb and resource: 'Get Profit and Loss (income statement) report for a period.' The parenthetical synonym and time scope make the tool's purpose unambiguous and help distinguish it from related report tools like get_balance_sheet or get_trial_balance, though it does not explicitly name those siblings.

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

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

Usage is only implied: the phrase 'for a period' suggests this tool is for income statement reporting over a date range. There is no explicit guidance on when to choose this tool over the many financial-report siblings, nor any exclusions or alternative suggestions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context by explaining the computation basis (bank transactions, invoice/bill/expense-claim commitments) and the parameter resolution mechanism (project_name fallback). It does not contradict annotations and enriches them without redundancy.

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

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

Two sentences with no filler. The first sentence states what the tool returns and from what data; the second gives usage triggers and parameter guidance. The purpose is front-loaded, and every word contributes to agent decision-making.

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 fully covers what the tool returns (income, costs, net margin, commitments), data sources, usage cases, and how to choose parameters. No output schema exists, so the description must convey return semantics, which it does. There are no missing pieces an agent needs to call it correctly.

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

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

Schema description coverage is 100%: both project_id and project_name have descriptions. The description adds the preference order ('Pass project_id if known, or project_name to resolve it by name') but this largely mirrors the schema's 'preferred if known' and 'resolve if not known' phrasing. It does not introduce new semantic details beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb 'Get' and resource 'deal/project's mini P&L', and enumerates its contents (income, costs by category, net margin, commitment summaries). It clearly distinguishes from general P&L tools like get_profit_and_loss and get_financial_snapshot by specifying the project scope and data sources.

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 use cases ('how is project X doing', 'project profit', 'mini P&L for a project', final report on completion). It implies it is for project-specific queries but does not explicitly name alternatives or state when not to use it, though the purpose is clear enough that an agent can infer the distinction.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the status scope (pipeline, active, completed) and the default 'all' behavior via the schema, but doesn't add behavioral context beyond that, such as pagination or ordering.

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

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

Two sentences, front-loaded with the action and scope, and the usage trigger follows immediately. No wasted words.

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

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

For a simple read-only list tool with 2 optional parameters, full schema coverage, and safety annotations, the description is nearly complete. It could mention that no parameters are required, but the schema already shows required: 0. The usage trigger covers the main context.

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

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

Schema description coverage is 100%, so both parameters (search, status) are already documented in the schema. The description adds a slight clarification by listing statuses in prose, but it doesn't add meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb ('List') and resource ('projects') and enumerates the statuses covered (pipeline, active, completed). It is clear what the tool does, though it doesn't explicitly distinguish it from the sibling 'list_opportunities' or 'update_project' beyond the resource name.

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

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

It gives a clear usage context: 'Use when the user asks about their projects, deals, or pipeline.' This tells an agent when to invoke it, though it doesn't explicitly state when not to use it or name alternative tools like list_opportunities.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context by listing the returned fields (income split, de minimis status, free zone name, substance declaration state, per-zone hints) and the conditional `applicable: false` behavior. It does not discuss error conditions or response formatting, but the added detail goes well beyond the annotation baseline.

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 purpose, then enumerates return fields, and ends with concrete use cases. Three sentences carry a high density of specific information without redundancy. Each sentence earns its place.

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

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

Despite lacking an output schema, the description thoroughly covers the return fields and usage triggers, which is sufficient for an agent to decide when to invoke and what to expect. The main gap is that it doesn't specify the response format or potential error conditions, leaving minor ambiguity in a no-schema context. For a read-only status tool, this is largely complete but not flawless.

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 and an empty schema, so there is nothing to explain. Per the rule, baseline for 0 params is 4. The description appropriately omits parameter details and focuses on behavior and output.

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 (Get) and resource (QFZP status), defines the acronym, and enumerates the exact return fields. It explicitly notes non-applicability for UK/UAE mainland companies, distinguishing it from generic tax tools in the sibling list. An agent can immediately identify what this tool does and how it differs from others.

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 provides trigger conditions: 'Use when the user asks about QFZP status, whether they still qualify, their de minimis headroom, or whether they'll owe 9% CT.' It also notes the exclusion for UK/mainland companies via `applicable: false`. However, it does not name an alternative sibling tool for those non-applicable cases, so it stops short of full alternative guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the useful detail that results are grouped per bank account and limited to unreconciled transactions, but does not disclose return shape or edge cases. This is adequate but not exceptional.

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

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

Two short sentences: the first states the output, the second gives usage guidance. Every word earns its place, and the core purpose 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 zero-parameter, read-only report, the description tells the agent what data it will receive (unreconciled count per bank account) and when to use it. There is no output schema, but the stated output is sufficient for correct invocation. A minor gap is not covering what 'bank account status' means exactly, especially with a sibling get_bank_accounts.

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 description has no parameter information to add beyond the empty schema. Per the rubric, a no-parameter tool receives a baseline of 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 states a specific verb ('Show') and a precise resource ('unreconciled transaction count per bank account'), which clearly distinguishes this from generic status tools. It goes well beyond the vague title by specifying the exact data returned.

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

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

The description explicitly says when to use the tool ('reconciliation progress, unreconciled transactions, or bank account status'). It does not mention alternatives or exclusions, but the use conditions are clear enough for an agent to route requests correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is fully covered. The description adds a useful nuance that it lists templates rather than invoices, but does not disclose pagination, filtering defaults, or return shape—acceptable for a lightweight read tool.

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

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

Two short sentences with no filler. The action and resource are front-loaded, and the usage triggers follow naturally.

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

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

For a one-optional-parameter read-only list tool with full schema coverage and strong annotations, the description is sufficient for an agent to select and invoke it correctly. The term 'templates' also clarifies what the response represents, mitigating the lack 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 coverage is 100% and the single status parameter already has an enum and default 'active' documented in the schema. The description adds no parameter-specific meaning, 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 states a specific verb ('List') and resource ('recurring invoice templates'), clarifying that this returns template definitions rather than individual invoices. This clearly distinguishes it from siblings like get_invoices.

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

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

The description gives explicit trigger phrases: 'recurring invoices', 'scheduled invoices', and 'subscription billing'. It does not mention when not to use it or point to alternatives, but the usage guidance is direct and actionable.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds no additional behavioral details, such as default return behavior, pagination, or what data is included. It doesn't contradict annotations, but also contributes nothing 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 a single, efficient sentence with no redundant or extraneous words. It is appropriately concise, though it is minimal enough that it borders on under-specification, which is more a completeness issue than a conciseness issue.

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

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

For a tool with no output schema, the description fails to explain the return format or any behavioral nuances. It does not mention what fields a task includes, how pagination works (despite the limit parameter), or any caveats. Given the simple nature of the tool, this is a notable gap in completeness.

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

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

Schema description coverage is 100%, so the parameters (limit, priority, completed) are fully documented in the schema. The description adds no extra meaning beyond what the schema already provides. The baseline of 3 is appropriate since the schema carries the weight.

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

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

The description clearly states the verb 'get' and the resource 'tasks and to-dos' with a scope of 'for the company.' It is specific enough to identify the tool's purpose, though it doesn't explicitly differentiate from sibling read tools like get_goals or get_expenses. The name itself is also informative.

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. It doesn't mention any context, such as 'use this to list tasks' or compare with create_task or other retrieval tools. The agent is left to infer usage from the name and schema alone.

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