Admin Substitute

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

The annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that it is 'lighter and faster' but does not disclose any additional behavioral traits such as data freshness, pagination, or scoping constraints. With the annotation covering the safety profile, the description adds minimal value.

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

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

The description is a single sentence comprising two clauses, providing all essential information without redundancy. It is front-loaded with 'Quick business overview' and includes specific metrics. Every word earns its place.

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

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

Given that the tool has an output schema (not shown), the description does not need to explain return values. It sufficiently lists the metrics returned (total leads, quotes, jobs, revenue, leads this week, chart data) and notes performance characteristics. For a simple dashboard tool with one optional parameter, this is complete.

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

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

Schema description coverage is 100% for the single parameter 'days', with full details in the schema. The description does not add any additional meaning or context to the parameter beyond what the schema provides. 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?

Description clearly states it provides a 'Quick business overview' listing specific metrics (total leads, quotes, jobs, revenue, leads this week, chart data). It distinguishes from sibling tools like analytics.detailed and analytics.financials by noting it is 'Lighter and faster than full analytics.' This makes the purpose unmistakable.

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?

Description implies this tool is for a quick, lightweight overview, contrasting with 'full analytics.' However, it does not explicitly state when to avoid this tool or name alternatives, though the sibling tool names provide context. Still, the guidance is clear enough for an agent to infer appropriate use.

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

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

Annotations already declare readOnlyHint=true, which aligns with the analytics nature. The description adds a behavioral detail (subscription plan requirement) not covered by annotations, enhancing transparency.

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

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

Two succinct sentences convey the purpose, scope, and access requirement with zero redundancy or unnecessary text.

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

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

Given the output schema exists and only one parameter, the description adequately covers the tool's functionality. It could mention that data is read-only (but annotations handle that) or typical use cases, but overall is complete.

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

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

Schema description coverage is 100% with a well-described enum parameter. The tool description adds no additional meaning beyond the schema, meeting the baseline.

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

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

The description uses a specific verb ('Detailed business analytics') and enumerates concrete metrics (conversion funnel, revenue trends, etc.), clearly distinguishing it from sibling tools like analytics.dashboard (likely overview) and analytics.financials (likely financial-specific).

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

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

The description only states a precondition ('Requires Growth plan or above') but provides no explicit guidance on when to use this tool versus alternatives like analytics.dashboard or when not to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description's job is reduced. It adds context about the summary contents but does not disclose additional behavioral traits like authorization requirements or rate limits. This is adequate 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?

A single, front-loaded sentence that efficiently conveys the tool's purpose and key metrics. No unnecessary words or redundant information.

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

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

For a simple, read-only summary tool with one parameter and an existing output schema, the description is nearly complete. It could be enhanced by noting that the tool aggregates data over a time period, but the time period parameter is already in the schema.

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

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

Schema coverage is 100%, so the description need not add parameter information. It does not mention the 'days' parameter, but the schema already provides a clear description and constraints. 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 clearly states it provides a financial summary and lists specific metrics: revenue, quote volume, conversion rate, lead count, and paid invoices. This specificity distinguishes it from sibling tools like analytics.dashboard and analytics.detailed, which are more generic.

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

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

No guidance is provided on when to use this tool versus alternatives such as analytics.dashboard or analytics.detailed. The description only explains what the tool does, not the context or conditions for its use.

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

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

The description discloses that the tool returns a URL for human browser payment, implying no immediate charge. Annotations (readOnlyHint=false, openWorldHint=true) already indicate a write operation with external effects. The description adds context about the payment flow but doesn't detail idempotency or error states. 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 two short sentences, front-loaded with the core action and purpose. Every sentence adds value: what it does, what it returns, and how it's used. No wasted words.

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

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

Given the presence of an output schema (not shown), the description appropriately explains the key return value (a URL) and the overall user flow. It's complete for a tool that initiates a payment session, though it could mention session expiration or webhook callbacks.

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 good descriptions for both parameters. The description adds minimal extra meaning beyond the schema, only hinting at 'upgrading or purchasing' to contextualize plan_slug. Baseline of 3 is appropriate as 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 explicitly states the verb 'create', resource 'Stripe Checkout session', and purpose 'upgrading or purchasing a plan'. It distinguishes from sibling tools like billing.get_portal and billing.list_plans by clearly focusing on the payment initiation step.

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

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

The description clearly indicates when to use this tool (for human payment via Checkout), but it does not explicitly mention when not to use it or point to alternatives like billing.get_portal for subscription changes. The context is clear but lacks 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 provide readOnlyHint: true and openWorldHint: true, so the description's role is reduced. The description adds value by specifying the requirement of an existing subscription and that it returns a URL for human interaction. There is no contradiction with annotations. The behavioral disclosure is adequate.

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, tightly crafted sentence that front-loads the core purpose, lists capabilities, and states the requirement. No extraneous words or redundancy. Every element earns its place.

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

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

For a no-parameter tool with an output schema (indicated by context), the description is fully complete. It explains what the tool does, what is required, and what the output is (a URL for human management). There are no gaps given the tool's simplicity.

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

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

The tool has no parameters, so baseline score is 4 per guidelines. The description does not need to add parameter information.

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'), the resource ('Stripe Billing Portal URL'), and the purpose ('for the human to manage their subscription'). It lists specific actions the portal enables (update payment methods, view invoices, change plans, or cancel), distinguishing it from sibling tools like billing.create_checkout or billing.status.

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

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

The description explicitly states a precondition: 'Requires an existing Stripe subscription.' This provides clear context on when the tool is applicable. However, it does not explicitly mention when not to use it or point to alternative tools, though the context is sufficient given the tool's simplicity.

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, so the description's 'Public information' adds limited value. It does not contradict annotations but also does not disclose additional behavioral traits beyond what annotations provide.

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

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

The description is two short sentences that are front-loaded with the tool's purpose and end with a use case. Every word contributes, and there is no extraneous 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?

Given no parameters, an output schema (not shown but noted), and annotations covering safety, the description is complete. It explains the data returned and the appropriate context for use, leaving no significant 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?

There are no parameters, and schema description coverage is 100%. The description adds no parameter-level detail, which is acceptable since there are none. The baseline for zero parameters is 4, and the description does not detract.

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

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

The description uses a specific verb 'List' and resource 'all available plans with pricing, features, limits, and feature flags'. It clearly distinguishes this from other billing tools like 'billing.status' or 'billing.usage' by focusing on plan discovery.

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 tool is for discovering plans before purchasing or upgrading, providing clear context. However, it does not explicitly mention when not to use it or name alternatives, so it stops short of fully comprehensive guidelines.

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 the description adds behavioral context by detailing what the tool checks (plan details, feature access). No contradictions. Adds value beyond annotations.

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

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

Two concise sentences: first enumerates checked items, second states purpose. No wasted words, front-loaded with key functionality.

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 parameters and an output schema present, the description adequately covers what the tool does and why it is useful. No missing information for an agent to select and invoke 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?

No parameters, so schema coverage is 100%. Description explains what the tool returns (status, plan, billing cycle, feature access), adding meaning beyond the empty input schema. Baseline adjusted to 4 for zero-param case.

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 specifies verb 'Check' and resource 'subscription status, plan details, billing cycle, and feature access'. Clearly states what the tool does and distinguishes from siblings like billing.list_plans (listing plans) and billing.usage (usage) without needing explicit contrast.

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

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

Explicitly states when to use: 'useful for understanding what the business can and cannot do on their current plan'. Provides clear context, though does not mention when not to use or list alternative tools.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by specifying exactly which resources are checked (API calls, SMS, email, LLM calls), going beyond the annotation.

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

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

A single, focused sentence that front-loads the purpose with no redundancy or wasted words.

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

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

Given zero parameters and an existing output schema, the description sufficiently explains the tool's purpose. It could mention that it returns current usage and limits, but the output schema likely covers return format.

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

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

With zero parameters, baseline is high, and the description adds meaning by listing what will be returned (usage vs limits for specific resources).

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 ('Check') and lists exact resources (API calls, SMS credits, etc.), clearly distinguishing it from sibling billing tools like billing.status or billing.list_plans.

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 (checking usage vs limits) but provides no explicit guidance on when to use this tool versus alternatives like analytics.dashboard or billing.status.

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

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

Annotations already indicate readOnlyHint=true, confirming no destructive behavior. The description adds value by detailing the output (forecast and time-saving metric), but does not disclose limitations like data recency or recalculation frequency. 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 paragraph that efficiently front-loads the core purpose and then lists the included data points. It is appropriately sized—no wasted sentences—though a bulleted list might improve scannability without adding length.

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 zero parameters and an output schema exists, the description provides all necessary context: the forecast scope, included metrics, and even a note on the value context. It fully equips an agent to understand and invoke the tool correctly.

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

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

The input schema has no parameters, so baseline is 4. No parameter information is needed, and the description does not attempt to add any, 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 it provides a '30-day cash flow forecast with weekly breakdown' and enumerates specific financial metrics (revenue, outstanding invoices, overdue invoices, etc.), distinguishing it from sibling tools like analytics.financials or analytics.dashboard which serve broader analytical purposes.

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 calls out its use for answering questions like 'Can I afford to hire?' or 'How's my cash flow?', providing clear context. However, it does not specify when not to use it or mention alternatives, though the sibling list offers other analytics tools that might be used for different financial questions.

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

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

Annotations already mark the tool as read-only, and the description adds that it returns aggregated metrics. However, it does not disclose pagination, ordering, or other behavioral traits. The added value beyond annotations is moderate.

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

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

The description is two concise sentences: the first defines the tool's primary action, the second explains its utility. No extraneous 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 list tool with good annotations and an output schema, the description provides sufficient context: what is returned and its use case. Minor omissions like ordering or pagination details are non-critical.

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

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

Schema coverage is 100% for the single parameter 'limit', and the schema description already details its range and default. The tool description adds no further parameter context beyond what the schema provides.

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

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

The description clearly defines 'clients' as leads with at least one job, and lists the included aggregated fields (job count, quote count, total revenue). This distinguishes it from siblings like 'leads.list' and 'jobs.list'.

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

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

The phrase 'Useful for identifying repeat customers' provides context on when to use the tool, but does not explicitly state when not to use or name alternative tools.

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

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

Annotations already declare readOnlyHint=true, so the description's statement 'View sent ... history' aligns and adds minor context about the scope (sent messages, audit use). No additional behavioral details like pagination, rate limits, or data freshness are provided, but given the annotation coverage, the description suffices without contradicting the annotations.

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

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

The description is two sentences, starting with the main action and followed by filtering options and use case. It is concise but contains an inaccurate claim ('delivery status') that could have been avoided. Still, it is front-loaded and generally 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?

For a simple read-only list tool with 100% schema coverage and an output schema, the description covers the essential purpose and suggests a use case. However, the incorrect claim about delivery status undermines completeness. The description could be improved by accurately listing filterable parameters and noting defaults like limit=50.

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, so the baseline is 3. However, the description adds 'Filter by ... delivery status' which is not a parameter in the schema, creating confusion. It does not provide any meaningful details beyond the schema for the actual parameters (type, limit, channel). The description misleads about available filtering options, reducing its 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 clearly states 'View sent SMS and email message history', specifying the verb (view) and resource (history of sent messages). It also mentions filtering options, distinguishing it from sibling tools comms.send_email and comms.send_sms which are for sending, not viewing.

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 indicates the tool is useful for auditing communications and describes filtering by channel, message type, or delivery status. However, it does not provide explicit when-not-to-use or alternative tools, and the claim about 'delivery status' is misleading because the input schema does not include a delivery_status parameter. This omission impacts clarity on when to use this tool effectively.

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?

Discloses monthly email quota and HTML support, adding value beyond annotations (readOnlyHint=false indicates mutation). Does not describe success/failure, rate limits, or side effects.

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

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

Three concise, front-loaded sentences. Every sentence adds value without redundancy.

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

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

Covers core action, quota, HTML support. No mention of sending behavior (immediate/scheduled) or response but output schema exists. Minor gaps but largely sufficient.

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

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

Schema coverage is 100% (all 6 parameters described). Description adds only 'HTML body supported' which relates to body param but doesn't significantly augment 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?

Specific verb+resource: 'Send an email on behalf of the company.' Distinct from sibling comms.send_sms. Constraints (quota, HTML support) add clarity.

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?

Implies use for official company emails but no explicit when-to-use or when-not-to-use. No mention of alternatives like comms.send_sms.

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 mutation (readOnlyHint=false) and open world (openWorldHint=true). Description adds quota and number format constraints, but lacks details on failure modes, idempotency, or side effects beyond the quota note.

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 action and constraints. No filler, every word adds value.

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

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

With output schema present, return value explanation is unnecessary. Description covers key constraints (Australian number, quota) and purpose, but could mention character limit explicitly (though schema covers it). Adequate for this tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. Description does not add semantic value beyond the schema descriptions (e.g., 'Australian mobile number' is already in the to parameter description).

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

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

Clear verb+resource: 'Send an SMS message to a phone number on behalf of the company.' Distinguishes from sibling tools like comms.send_email and comms.list by specifying the channel (SMS) and constraints (Australian number, quota).

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?

States when to use (send SMS) and implicit constraints (Australian number, monthly quota). Does not explicitly exclude scenarios or contrast with alternatives like email, but context is sufficient for basic guidance.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is safe. The description adds valuable behavioral context: the output is an AI draft that must be reviewed by a competent person and requires a specific plan, which annotations lack.

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

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

The description is three sentences, front-loaded with purpose and compliance, then content, then critical warning. No wasted words; every sentence adds essential 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?

Given the tool's complexity (7 parameters, output schema exists), the description is complete: it explains the regulatory basis, document contents, draft nature, and plan requirement. It doesn't detail output format, but the output schema likely covers that. Slight gap in not mentioning file format or return type.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds regulatory context (compliance details) but does not repeat or enhance parameter semantics beyond what the schema provides. 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 clearly states the tool generates a site-specific SWMS compliant with WHS Regulations and Safe Work Australia standards, with explicit details about content (hazards, controls, PPE, emergency procedures). The verb 'generate' and resource 'SWMS' are specific and distinguish this from sibling tools, which are unrelated.

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

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

The description provides clear context: the output is an AI draft that must be reviewed and signed, and a Growth+ plan is required. It implies when to use (for generating SWMS) but does not explicitly exclude alternatives or compare to other tools, though no direct sibling 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 indicate a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). Description adds that it auto-generates folder paths. However, it does not disclose behaviors like file overwrite, size limits, or error handling. Adequate but not comprehensive.

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 (25 words) conveying the core functionality. Front-loaded with action and outcome. No unnecessary 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?

With 3 parameters and an output schema (not shown), description covers the main purpose and auto-folder generation. Lacks mention of prerequisites (e.g., cloud storage connection) but overall comprehensive given 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 covers all 3 parameters with descriptions (100% coverage). Description adds context that folder paths are based on entityType, which clarifies its role. However, no extra detail on entityId or fileName beyond 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 clearly states the tool files a document to cloud storage with auto-generated folder paths. The verb 'file' and resource 'document' are specific. It distinguishes from sibling tools by focusing on document organization and cloud storage.

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

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

No explicit guidance on when to use this tool vs alternatives. No mentions of prerequisites (e.g., cloud storage setup), or when to avoid it. Only implies use for filing documents to organized folders.

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

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

Annotations already provide readOnlyHint=true. The description adds context about return values (link and code) and business logic (commission). However, it does not disclose additional behavioral traits like auth needs or rate limits, which is acceptable for a simple 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?

The description is extremely concise: two sentences that front-load the core action and then add context. Every word adds value with zero waste.

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 an output schema exists, the description adequately explains the tool's purpose and business context (commission, sharing). It could mention that it's read-only, but annotations already cover that. Overall 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, and schema coverage is 100%. The description does not need to add parameter details beyond what the schema provides, and the baseline for zero parameters is 4.

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

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

The description clearly states the tool's purpose: 'Get the company referral link and code.' It uses a specific verb (get) and resource (referral link/code), and adds context about commission and sharing, which helps differentiate it from other tools like workflows.referral_program.

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 (when you need a referral link to share), but does not explicitly state when to use this tool versus alternatives, nor provide any exclusions or comparison to sibling tools.

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

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

Annotations already declare readOnlyHint=true, so the agent knows it's a safe read. The description adds that the return includes a complete checklist with time estimates and costs, providing behavioral context beyond the annotation. No contradictions.

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

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

The description is two sentences, both front-loaded and concise. Every sentence adds value: first states the main purpose, second expands on content. No wasted words.

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

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

Given the tool has an output schema, the description need not detail return values. It covers the checklist's scope (categories) and key features (time estimates, costs). The information is sufficient for an agent to understand what the tool provides.

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 both parameters (state and trade). The description does not add new parameter semantics beyond restating 'specific trade and state', 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 tool returns a step-by-step business formation checklist for a given trade and state, listing included categories (ABN, GST, licensing, etc.) and mentioning time estimates and costs. This distinguishes it from siblings like formation.requirements or formation.guided_setup, which focus on specific aspects.

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

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

The description implies the tool should be used when a comprehensive checklist with time/costs is needed, but it does not explicitly state when not to use it or name alternative sibling tools. Usage guidelines are present but minimal.

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 provide readOnlyHint and openWorldHint, which the description aligns with. The description adds geographical scope ('across Australian regions') but lacks details on data freshness, pagination, or any side effects, which would improve transparency beyond annotations.

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

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

The description is two sentences, front-loading the core function and then providing usage context. No extraneous words, making it 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?

Given the existence of an output schema, the description appropriately lists return fields without unnecessary detail. It adequately covers purpose, usage, and key aspects for a simple data retrieval 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?

With 100% schema coverage, the schema already documents both parameters. The description does not add new meaning or constraints beyond what is in the schema, so it meets the baseline but does not exceed it.

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

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

The description clearly states the tool retrieves trade demand hotspots across Australian regions, listing specific data points (demand scores, shortage severity, etc.). It distinguishes itself from sibling formation tools like formation.recommend_trade by focusing on location-based demand 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?

The description explicitly advises using it for advising where to start a trade business, providing clear contextual guidance. However, it does not explicitly mention when to avoid using it or suggest alternative tools, leaving some ambiguity among siblings like formation.location_score.

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, indicating a safe read operation. The description adds no conflicting or additional behavioral traits beyond the read-only nature and the optional filtering capability. It does not mention any limitations or side effects.

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

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

The description is a single sentence that efficiently conveys the purpose and filter capability. No unnecessary words or repetitions.

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

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

Given the output schema exists (not shown but inferred), the description is sufficient for a simple list tool. However, it could more explicitly state that it returns a list of programs, and mention that the filter narrows results. Overall adequate for the complexity.

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

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

The input schema covers the single optional parameter 'category' with 100% description coverage. The description repeats the filter categories listed in the schema but does not add new semantic details such as format constraints or special values.

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 Australian government grants and funding programs for trade businesses, with a specific verb 'Get' and resource 'grants, incentives, and funding programs'. It distinguishes from sibling tools like 'funding.eligibility_scan' and 'funding.program_details' by focusing on listing available programs.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'funding.eligibility_scan' (which likely checks eligibility) or 'funding.program_details' (which likely gives details on a specific program). The description does not mention prerequisites or exclusions.

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

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

Describes the input (person context) and output (formation plan with specific sections) in detail. Annotations indicate readOnlyHint=true, which is consistent with the description. 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?

Single paragraph with front-loaded 'RECOMMENDED ENTRY POINT' and a numbered list of outputs. Every sentence contributes meaning; no wasted words.

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

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

Given the tool's complexity (13 params, output schema), the description covers purpose, usage, and outputs comprehensively. It explains what the plan contains, including follow-up questions and recommended next steps, making it self-contained.

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 baseline is 3. Description adds value by summarizing key parameter groups (trade, state, qualifications, budget, goals) and hinting at usage context, but does not detail each of the 13 parameters individually.

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 clearly states it is an intelligent business formation engine that produces a personalised plan with six specific components. It distinguishes itself from sibling tools by being the recommended entry point.

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 says 'RECOMMENDED ENTRY POINT' and 'Call this FIRST, then use the recommended tool chain for deeper dives', providing clear when-to-use and sequential guidance.

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

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

Annotations already indicate readOnlyHint=true. The description adds value beyond annotations by stating the return includes a score breakdown and recommendation, providing behavioral context about output. No side effects or additional traits are disclosed, but the safety profile is clear.

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

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

The description is extremely concise with two focused sentences: the first clearly states the core function, and the second adds relevant context (factors and return). No filler or repetition, earning full marks.

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 presence of an output schema (not shown but assumed), the description adequately covers the tool's purpose, input hints, factors considered, and return type. For a simple scoring tool with two string parameters, this is fully complete and leaves no ambiguity.

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 both 'trade' (list of allowed categories) and 'region' (slug format, hints for discovery). The description mentions factors used in scoring but does not add new parameter-level details beyond what the schema provides, so 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 calculates an opportunity score (0-100) for a trade+region combination, using specific verb 'Calculate' and resource 'opportunity score'. It distinguishes from sibling tools like formation.demand_hotspots (region discovery) and formation.recommend_trade (trade recommendation), making its role unique.

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 explains the tool considers factors like shortage severity and growth trends, and explicitly directs users to use formation.demand_hotspots to discover regions. However, it does not provide explicit guidance on when not to use this tool or compare it to other scoring or recommendation 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 confirm readOnlyHint=true (safe, non-destructive). The description adds detail about the scoring process (4 factors, all 9 trades, top 5 results) and output fields (startup costs, revenue scenarios, etc.), leaving no behavioral surprises.

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 paragraph but efficiently packs information: purpose, input specifics, scoring details, output fields, and use case. It is front-loaded and each sentence adds value, though slightly longer than minimal.

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

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

Given the complexity (14 parameters, output schema exists, read-only), the description covers the core functionality and output. It mentions the 9 trades and 4 factors not in schema, and the output schema covers return structure. Missing edge cases or error conditions, but adequate for typical 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 coverage is 100% with descriptions for all parameters. The description adds value by introducing the 4 scoring factors (budget fit, time to revenue, revenue upside, barrier to entry) and grouping inputs conceptually, which goes 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 it is a trade recommendation engine that takes user inputs (budget, state, goals, etc.) and returns ranked recommendations with specific output details. It distinguishes itself from siblings like formation.checklist or formation.demand_hotspots by focusing on trade selection.

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 'Perfect for "what trade should I start?" questions', indicating when to use. However, it does not provide explicit when-not-to-use guidelines or compare with alternative tools, though siblings are available.

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

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

Annotations already indicate readOnlyHint=true, so the tool is known to be safe. The description adds value by detailing the returned data including government links and trade insights, providing context beyond safety. No contradictions 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, informative sentence that front-loads the purpose, but it is somewhat long (three lines). It could be split for readability while remaining concise overall.

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

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

Given the output schema exists, the description need not detail return fields. It effectively summarizes the rich output including trade-specific insights and government links, making the tool's value complete for an agent.

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

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

Schema describes both parameters (state and trade) with full coverage. Description does not add significant extra meaning beyond what schema provides, earning 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 clearly states the tool retrieves trade licensing and compliance requirements for an Australian state, listing specific outputs like licence type, requirements, cost estimates, and trade insights. This is distinct from sibling tools like formation.checklist or formation.funding, making the purpose unambiguous.

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

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

The description implies usage for getting licensing requirements but does not provide explicit guidance on when to use this tool versus alternatives like formation.recommend_trade or formation.guided_setup. No when-not-to-use or context for exclusions are given.

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

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

Annotations provide readOnlyHint=true (safe read) and openWorldHint=false. The description adds valuable behavioral context: it uses real Australian 2025-26 tax brackets, 10% GST, 12% super rate, and trade-specific cost profiles. No contradictions 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 paragraph of 4-5 sentences, front-loaded with purpose, and includes all key details without unnecessary words. It earns its place but could be slightly more structured (e.g., bullet points for outputs).

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

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

Given the complexity (15 parameters, 8 required) and the existence of an output schema (referenced), the description is comprehensive: it lists output categories, input parameters, and geographical/regulatory context. It provides enough information for an agent to understand what the tool 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 baseline is 3. The description adds context for some parameters (e.g., 'Reduces vehicle costs' for hasVehicle, 'Override average job value' for averageJobValue) but does not significantly enhance meaning beyond schema descriptions.

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

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

The description clearly states it is a '12-Month Business Simulator' for 'Australian trade businesses'. It lists specific inputs (trade, state, startup capital, etc.) and outputs (gross revenue, expenses, GST, etc.), distinguishing it from sibling formation tools like formation.checklist or formation.recommend_trade, which serve different purposes.

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

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

The description implies use for financial projections but does not explicitly state when to use this tool vs alternatives. There is no 'when to use' or 'when not to use' guidance, nor mention of related siblings.

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

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

Annotations already indicate readOnlyHint=true, so the description adds value by specifying the types of programs included (federal, state, apprenticeship incentives, etc.) and the output of estimated total funding. 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 concise sentences: first for main action, second enumerates program types, third for output. No fluff, front-loaded with the most important 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?

Given the presence of an output schema (not shown but indicated), the description sufficiently covers the tool's scope, program categories, and output. It is complete for a scanning tool with no missing 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 baseline is 3. The description does not add additional meaning or constraints beyond what the schema already provides for each parameter.

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

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

The description uses a specific verb 'Scan' and clearly identifies the resource as 'government funding programs' with a defined scope (trade business eligibility). It distinguishes itself from the sibling tool 'funding.program_details' which likely provides details on individual programs.

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

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

The description implies use for broad eligibility scanning but does not explicitly state when to use this tool versus alternatives like 'funding.program_details' or when not to use it. No exclusions or alternative recommendations are provided.

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

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

Annotations declare readOnlyHint=true, so the read‑only nature is already conveyed. The description adds that it returns eligibility criteria, application process, tips, and links, but does not disclose other behavioral traits like rate limits or authentication requirements. It does not 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?

A single, well‑structured sentence that front‑loads the core purpose ('Get detailed information') and enumerates key content types. No extraneous 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 tool with one required parameter and an output schema, the description sufficiently covers what the tool returns. Annotations handle safety, and no additional information is needed for effective 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 for programId is generic ('Program ID'), but the description provides concrete examples (e.g., 'kap') and advises using eligibility_scan to discover values, adding meaningful context 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 retrieves detailed information about a specific funding program, including eligibility, application process, tips, and links. This distinguishes it from sibling 'funding.eligibility_scan' which discovers programs.

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

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

The description does not explicitly state when to use this tool versus alternatives. However, the parameter description hints at using 'funding.eligibility_scan' for discovery, implying this tool for known programs. No explicit when-not or exclusion criteria are provided in the description field.

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

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

Annotations already indicate readOnlyHint=true, so the description's claim of getting data is consistent. It adds the context of Australian trade businesses and the six steps, but no additional behavioral details like permissions or side effects beyond what annotations provide.

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

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

The description is concise (two sentences) and front-loaded with the main action. Every sentence adds value, and the bullet list of covered areas is 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 an output schema present and two optional parameters, the description covers the overall workflow and its contents sufficiently. No missing information that would hinder invocation.

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

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

Schema coverage is 100%, meaning the JSON schema already describes both parameters. The description mentions specific step numbers and trade categories, which aligns with the schema but does not add significant new semantics.

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

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

The description clearly states the tool returns the complete 6-step apprenticeship workflow for Australian trade businesses, listing the specific areas covered. It is distinct from sibling tools like hiring.capacity_analysis.

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 indicates the tool is for getting the apprenticeship workflow. While it doesn't explicitly exclude alternatives, the context of sibling tools and the specific coverage makes its use clear. No when-not-to-use guidance 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?

The description describes a read-only analysis operation, which matches the readOnlyHint annotation. No additional behavioral details are provided beyond what the annotation already conveys, but there is no contradiction.

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

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

The description is a single sentence that clearly states the purpose and key outputs. It is front-loaded and contains no extraneous information.

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

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

The description covers the main outputs and is sufficient given the presence of a detailed input schema and output schema. It could mention the required parameters, but the schema handles that.

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% coverage for all 9 parameters with descriptions. The tool description itself does not add any additional meaning to the parameters beyond what the schema already provides, 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 clearly states the tool analyzes capacity utilization for solo tradespeople and returns specific metrics (capacity score, burnout risk, lost revenue, hiring urgency). This distinguishes it from sibling tools like hiring.readiness_score or hiring.cost_calculator.

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 to determine if a tradesperson has hit their capacity ceiling, but it does not provide explicit guidance on when to use this versus other hiring or analytics tools, nor any 'when-not-to-use' scenarios.

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

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

Annotations already indicate readOnlyHint true; description adds value by detailing covered areas (NES, Awards, etc.), enhancing understanding of scope without contradicting annotations.

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

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

Description is a single sentence with a bullet-list of topics. No wasted words, front-loaded with purpose.

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

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

Given one optional parameter, 100% schema coverage, read-only annotation, and simple return type (checklist), the description fully covers the tool's scope and behavior.

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

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

Schema already describes the single parameter fully (category filter). Description does not add new meaning beyond what the schema provides, so baseline score 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 it retrieves a Fair Work compliance checklist for hiring in Australia, listing specific topics covered. It distinguishes from siblings like compliance.generate_swms or formation.checklist.

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

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

The description implies usage for hiring compliance needs but provides no explicit when-to-use or alternatives. It could mention not to use for SWMS or formation.

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 declare readOnlyHint: true, indicating this is a calculation without side effects. The description adds behavioral context by listing all cost components included (super, workers comp, etc.) and mentioning state-specific calculations, which goes beyond what annotations provide.

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

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

Two sentences, no wasted words. The first sentence states the core purpose, and the second lists key components. Ideal front-loading and length for an AI agent to quickly understand the tool.

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

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

Given the presence of an output schema and high schema coverage, the description is complete. It explains what the tool does, what inputs are relevant, and includes cross-references to another tool (hiring.wage_data). No gaps identified.

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 descriptions for all 7 parameters. The description adds value by explaining the purpose of 'baseSalary' (use hiring.wage_data for market rates) and the 'trade' parameter (incentive calculation), enriching the schema information.

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 calculates the true cost of hiring an employee or apprentice in an Australian state, listing specific components like super, payroll tax, and incentives. This distinguishes it from sibling tools like hiring.capacity_analysis or hiring.compliance_checklist.

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

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

The description provides clear context for when to use the tool (cost calculation) but does not explicitly exclude alternatives or specify when not to use it. The sibling list suggests many other hiring tools, so adding explicit guidance would improve this dimension.

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 include readOnlyHint=true, and the description ('Calculate... Recommends') confirms read-only behavior. The description adds context about the recommendation output but does not disclose additional traits like required inputs or edge cases 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 sentences, front-loading the primary action in the first sentence. Every sentence provides essential information without redundancy.

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

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

Given the existence of an output schema (not shown) and high schema coverage, the description adequately covers the tool's purpose and output recommendation. It lacks details on expected parameter ranges or usage context but remains sufficient for selection.

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

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

All 10 parameters have descriptions in the input schema (100% coverage). The tool description adds no additional parameter-level information, so it meets the baseline expectation but does not enhance understanding.

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

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

The description states 'Calculate hiring readiness score' and specifies it 'Recommends apprentice vs employee vs contractor vs admin-first hire', providing a specific verb and resource. It distinguishes from the sibling 'scaling.readiness_score' by focusing on hiring dimensions.

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

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

The description implies usage for hiring readiness assessment but does not explicitly state when to use this tool versus alternatives like 'scaling.readiness_score' or other analytics tools. No when-not or alternative guidance 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 include readOnlyHint=true, consistent with listing. Description adds details on what fields are shown (name, category, auth type, features, adapter status). 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?

Two efficient sentences with no filler. Front-loaded with the essential action and output 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?

Description covers purpose, usage, and output fields. With an output schema present and annotations providing safety cues, the description is fully adequate.

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

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

Schema coverage is 100%, so baseline 3. Description adds value by listing example categories (accounting, communication, marketing, etc.), providing useful context 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?

Description clearly states it lists all available integration providers, not just connected ones. It distinguishes from sibling tools like integrations.list_connections which lists connected ones.

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 says 'Use this to help users discover what they can connect', giving clear context. While it doesn't mention when not to use, the purpose is well differentiated from sibling tools.

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

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

Annotations already declare readOnlyHint=true, and the description adds behavioral detail about what the status includes (sync results, error logs). No contradictions. However, it does not mention authentication or rate limits.

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, front-loaded with the action and key details. 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 tool with one parameter and an output schema, the description covers what the tool does, its return data, and its use case. Adequately 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 single parameter providerId is well-described in the schema with examples in the description. Schema coverage is 100%, so baseline is 3; the description adds value by listing valid examples (xero, slack, etc.).

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

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

The description clearly states the tool gets detailed status for a specific integration connection, listing included data (last sync results, error logs, supported operations) and the use case (diagnosing sync failures). It distinguishes from siblings like integrations.list_connections.

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

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

The description provides a clear use case ('diagnosing sync failures') but does not explicitly state when not to use or compare with alternatives like integrations.sync. Still, the context is useful.

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, so safety is clear. Description adds output fields but says 'active' connections first, while schema allows filtering by other statuses. This could mislead about default behavior, lowering transparency slightly.

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 purpose. No wasted words. Efficient and immediately 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?

With only two optional parameters well-documented in schema and an output schema present, the description covers the essential context. Slight issue with 'active' vs default unfiltered behavior, but overall sufficient.

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

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

Schema coverage is 100% with good parameter descriptions. Description does not add additional meaning beyond what schema 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?

Clearly states 'List all active integration connections' with explicit verb and resource. Distinguishes from siblings by noting use case for discovering connections before push/pull, differentiating from push, sync, and status tools.

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

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

Provides explicit use case: 'Use this to discover what external systems are connected before pushing/pulling data.' Implicitly tells when to use, though does not mention alternatives like integrations.connection_status.

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 idempotent, non-destructive, and not read-only. Description adds that it requires an active connection, but does not disclose further behavioral traits (e.g., error handling, side effects, or rate limits).

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 purpose, followed by examples and requirement. No redundant text.

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

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

Description is adequate for a tool with an output schema. It covers purpose and key requirement. Could mention immediate vs queued execution or error scenarios, but overall satisfactory.

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 baseline is 3. Description adds no additional meaning beyond what schema provides; it lists entityType examples but omits some enum values (contact, payment).

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 clearly states the verb 'push' and the resource 'specific entity', lists examples (lead, job, invoice), and differentiates from sibling tools like integrations.sync by requiring an active connection with push capability.

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

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

Provides clear context: requires an active connection with push capability for the entity type. Gives example use cases (push job to Slack, invoice to Xero). However, does not explicitly state when not to use or compare with alternatives like integrations.sync for bulk operations.

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

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

Annotations already provide readOnlyHint=false, destructiveHint=false, etc. The description adds the behavioral detail that the tool pulls or pushes depending on provider config, and mentions the need for an active connection. However, it does not explain non-idempotency or open-world effects beyond what annotations convey.

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: first states the primary action, second adds behavioral nuance and a prerequisite. No unnecessary words, front-loaded with core purpose.

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

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

Given the presence of an output schema and annotations covering safety, the description adequately explains the tool's function, prerequisite, and basic behavior. It could be more explicit about the effects of repeated calls or concurrency, but overall sufficient for basic 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?

Input schema documentation covers 100% of parameters, each with a description. The tool description does not add additional parameter-level detail beyond what the schema provides, so it meets baseline but does not exceed it.

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

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

The description clearly states the tool triggers a sync operation for a specific integration connection, and explains it pulls or pushes entities based on provider configuration. This distinguishes it from sibling tools like push_entity which is more specific, and list_connections which is read-only.

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

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

The description mentions a prerequisite (requires an active connection) but does not explicitly state when to use this tool versus alternatives like push_entity. The context of synchronization is implied, but no when-not or explicit comparisons are provided.

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

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

Annotations indicate mutability (readOnlyHint=false), and the description confirms sending emails/SMS, logging, and tracking recovery. It adds context like Stripe payment link and 48-hour recovery metrics. 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 detailed but front-loaded with the core purpose. Each sentence adds value (modes, escalation, revenue impact). Could be slightly more structured with bullets, but overall concise given the complexity.

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

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

The description covers both modes, escalation details, output format (days overdue, chase level, total outstanding), and side effects (logging, tracking). With an output schema present, the description is thoroughly 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 coverage is 100%, so baseline is 3. The description adds meaning: explains tone as escalation level, jobId as mode switch, sendSms default behavior. This goes beyond the schema's enum and type 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 states the tool finds and chases overdue invoices, with two distinct modes (GET and SEND). It specifies the resource (invoices) and actions (list, send reminders), differentiating it from siblings like invoicing.recovery or comms.send_email.

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 explains when to use GET mode (list overdue) vs SEND mode (with jobId and tone). It provides escalation levels and their thresholds. However, it does not explicitly exclude cases where alternative tools (e.g., comms.send_email) might be preferred.

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 indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds behavior: conditional creation of payment link if Stripe Connect is active, and returns specific fields. 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, front-loaded with purpose, no fluff. Every sentence adds value: purpose, conditional behavior, prerequisites, next step.

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 output schema present and annotations, description provides prerequisites, conditional behavior, return values, and next step. Complete for a single-param 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?

Single parameter jobId has 100% schema coverage. The description restates that it is required and job must be Completed, but does not add new semantics beyond the schema. 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 generates an invoice for a completed job, distinguishing it from siblings like invoicing.chase and invoicing.recovery. It mentions the conditional Stripe Connect behavior, adding specificity.

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

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

Explicitly states when to use (job must be 'Completed'), requires jobId from jobs.list, and suggests next step (payments.send_link). This provides clear guidance on usage and 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 and openWorldHint=false. The description adds that the tool returns recovered amount and count from auto-chase reminders, confirming it is a read-only aggregation with a fixed scope. No contradictions; the description provides useful behavioral 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?

Two sentences with no wasted words. The first sentence states the purpose and outputs, the second provides context and a use-case hook. Front-loaded and 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?

Given the tool's simplicity (no input params, no nested objects) and the existence of an output schema, the description fully explains what the tool returns and why it matters. No gaps remain.

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 no parameters (coverage 100%), so the description need not add parameter details. It implicitly justifies the lack of parameters by making the tool a fixed dashboard metric. Score 4 reflects the baseline for zero-param tools.

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 what the tool does: 'Track how much money has been recovered through auto-chase reminders.' It specifies the return values (total $ and count) and distinguishes it from sibling tools like invoicing.chase, which triggers chases, and invoicing.generate, which creates 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 frames the tool as 'the proof the platform pays for itself' metric, implicitly guiding use to demonstrate ROI to users. While it doesn't explicitly state when not to use it or provide direct alternatives, the context is clear enough for an AI agent to infer appropriate usage.

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 the tool is not read-only (readOnlyHint false), not destructive (destructiveHint false), and idempotent. The description adds context about triggering review requests but does not disclose irreversibility or permanent state changes beyond what the annotations imply.

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

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

The description is concise, with two sentences followed by clear bullet points for prerequisites and next steps. Every sentence is informative and 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 tool with 4 parameters and an output schema, the description covers the core functionality, prerequisite, and recommended workflow. It does not elaborate on return values (but an output schema exists) or error handling, but is sufficient for typical usage.

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

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

The input schema already describes all parameters (100% coverage). The description adds a summary of optional behaviors (satisfaction rating and review request) but does not provide new semantics beyond the schema descriptions.

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 marks a job as completed, optionally records satisfaction, and triggers a review request. It differentiates itself from sibling tools like jobs.create and jobs.update by explicitly being the 'recommended end-of-job action'.

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 advises when to use it ('recommended end-of-job action') and provides a prerequisite ('Requires: job_id from jobs.list') and recommended next steps. However, it does not specify when not to use it or explicitly compare to alternatives like jobs.update.

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

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

Describes auto-set status behavior (Scheduled vs Quoted) based on date input, going beyond annotations. No contradictions with annotations. Could mention if any destructive action occurs, but none expected.

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 succinct sentences with front-loaded purpose, efficient use of words, 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?

Covers purpose, parameters, prerequisites, and next steps; adequate for a creation tool with output schema and good annotations.

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

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

Schema covers all parameters with descriptions (100% coverage). Description adds context on status auto-setting and lead_id source, enhancing understanding beyond 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?

Clearly states the tool creates/schedules a job for a lead, with optional linking to quote and assigning technician. Differentiated from siblings like jobs.update and jobs.complete.

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

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

Explicitly states prerequisite (lead_id from leads.list) and recommended next steps (jobs.update → jobs.complete → invoicing.generate), providing clear when-to-use and workflow context.

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

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

Annotations already declare readOnlyHint=true. The description adds context about included linked data and cursor-based pagination, which are useful for agent behavior understanding.

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

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

The description is a single sentence that conveys essential information efficiently 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?

Given the existence of an output schema, the description adequately covers the scope of returned data and pagination. It is complete for a list tool.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The tool description adds no additional parameter-level information beyond what's in the schema.

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

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

The description clearly states the tool lists jobs with specific fields (status, scheduled dates, technician assignment, invoice info) and includes linked lead and quote data. It distinguishes from sibling tools like jobs.create or jobs.complete by being a read-only list 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?

The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for listing jobs, but lacks when-not or alternative tool references.

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. The description adds context about the returned data (sorted by profit, identifies winners/losers) but does not disclose any additional behavioral traits beyond what annotations provide. No contradiction.

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

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

The description is reasonably concise, with key information front-loaded. Minor promotional language ('The insight that separates surviving tradies') adds slight fluff but does not detract significantly.

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

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

Given an output schema exists, the description need not explain return values, but it does, listing them in useful detail. It covers the tool's purpose and output. No mention of scope (e.g., time period) but acceptable given no parameters.

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

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

There are 0 parameters (schema coverage 100% trivially). Per guidelines, baseline for 0 params is 4. Description does not add parameter semantics because none exist.

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

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

The description clearly states 'Per-job profit analysis for completed jobs' and enumerates the return fields (revenue, cost, profit, margin, breakdown by service type). It has a specific verb and resource, distinguishing it from sibling analytics tools, though it does not explicitly contrast with 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?

The description provides no guidance on when to use this tool versus alternatives like analytics.dashboard or analytics.financials. It does not state prerequisites, when-not-to-use, or any context for 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 indicate it's not read-only, not destructive, and not idempotent. The description adds no further behavioral details beyond the notification action. It does not disclose if the job status changes or if contact info is used.

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 plus a benefit phrase, front-loaded with the core action. Every word is purposeful with no redundancy.

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

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

Given the simple tool (2 params, output schema exists), the description provides sufficient context for purpose and benefit. It does not need to explain return values due to 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 description does not add any additional meaning beyond the schema. The schema already describes both parameters adequately.

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 (send notification), the resource (client), and the context (on my way with optional ETA). It distinguishes from sibling tools like comms.send_email and comms.send_sms by being specific to the 'on my way' scenario.

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

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

The description implies usage when you want to notify the client en route, mentioning the benefit of reducing no-shows. However, it does not explicitly state when NOT to use the tool or provide alternatives among siblings.

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

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

Annotations already indicate idempotent=true and readOnly=false, so the description's mention of 'Progress jobs through the pipeline' adds context about allowed status transitions. No contradictions, and it provides useful behavioral cues 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?

Two sentences, front-loaded with key purpose, and no extra words. Every sentence adds value: the first lists updatable fields, the second explains the pipeline progression.

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

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

Given the tool's complexity (5 parameters, 1 required, enums, output schema exists), the description covers the essential behaviors. It doesn't explain return values, but the output schema likely handles that. Sufficient for an agent to use 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?

All 5 parameters have descriptions in the schema (100% coverage), so the description's value is limited. However, it adds pipeline ordering context and explicitly advises using jobs.complete for completion flow, which enhances understanding of the status enum.

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 'update' and the resource 'job', lists specific fields (status, schedule, notes, technician) that can be updated, and indicates the pipeline progression. This distinguishes it from sibling tools like jobs.complete and jobs.create.

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

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

Explicitly states when to use this tool (for updating job details or progressing through pipeline) and provides a clear alternative: 'Use jobs.complete for the full completion flow with review 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?

Annotations provide readOnlyHint=false and destructiveHint=false. Description adds auto-assignment to authenticated company and source defaulting to 'mcp', which are useful behavioral traits 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?

Two sentences, no fluff. Front-loaded with main purpose, 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 8 parameters (2 required) and an output schema, the description covers key behaviors but doesn't mention return value format or error cases. Still adequate for a creation tool.

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

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

Schema description coverage is 100%; the description only mentions source defaults, which is already in schema. No new parameter meaning added beyond what schema provides.

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

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

Clearly states 'Create a new lead/prospect' with specific verb and resource. Adds auto-assignment and default source, distinguishing from siblings like leads.update and leads.list.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., leads.update or other creation tools). Does not state prerequisites or exclusions.

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

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

Consistent with readOnlyHint; describes returned fields and pagination support, adding valuable behavioral context beyond the annotation.

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

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

Two brief sentences and a tip, efficiently communicating purpose, returned data, and usage hint. No wasted words.

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

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

Given the presence of an output schema and full parameter documentation, this description sufficiently covers filtering, pagination, and the specific data returned. No gaps.

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

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

Schema coverage is 100% so baseline is 3; the description adds 'filtering and cursor-based pagination' context but does not deepen understanding beyond what schema descriptions provide.

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?

Clearly states 'List leads and prospects' and specifies returned fields. The tip mentioning leads.create distinguishes this read operation from its write 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?

Provides implicit usage guidance via tip linking leads.create to leads.list for verification. Does not explicitly state when not to use or name alternatives like clients.list.

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

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

Annotations already provide safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true). Description adds key behavioral detail 'Only provided fields are updated', consistent with idempotency.

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

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

Two sentences, no wasted words, front-loaded with purpose and behavior.

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

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

With output schema and annotations present, the description is adequate for a simple update operation. Could mention that lead must exist, but not critical.

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

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

Schema coverage 100% with descriptions. Description adds value by clarifying that only provided fields are updated, which is important for understanding the id and optional 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?

Description clearly states verb 'Update', resource 'lead', and the partial update behavior. Distinguishes from siblings like leads.create and leads.list.

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

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

Provides clear usage: pass lead ID and any fields to change. Implicitly covers when to use this tool for updating leads. Could add when not to use, but sufficient.

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

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

Annotations already declare readOnlyHint=true, so the description's mention of 'returns' is consistent. It adds value by detailing the output structure (current stage, signals, triggers, recommendations, blockers), which supplements the annotations without 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 cover purpose, stages, and outputs with no redundant words. Every sentence provides essential information, making it efficient and easy to parse.

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

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

Given the complexity (13 parameters, 5 stages) and the presence of an output schema, the description adequately maps inputs to outputs. It briefly mentions 'provide business metrics' and lists all outputs. Could slightly improve by hinting at required inputs (hasABN, hasLicence) but schema covers that.

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 13 parameters fully. The description does not add semantic detail beyond listing the stage names. 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 ('assess') and resource ('business lifecycle stage'), explicitly lists the five stages, and mentions the readiness score and specific outputs. It clearly distinguishes from sibling tools like scaling.readiness_score or formation.checklist by its comprehensive lifecycle focus.

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

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

The description states what the tool does but offers no guidance on when to use it vs. sibling tools like scaling.readiness_score or formation.checklist. There are no explicit when-to-use or when-not-to-use indications, leaving the agent to infer context from the name alone.

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