Admin Substitute

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

Annotations already declare readOnlyHint=true, and the description is consistent. The description adds the specific output fields (e.g., chart data) but does not disclose 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?

Two sentences, no fluff. The first sentence front-loads the core value proposition and returned data, the second adds a comparative advantage. Every word earns its place.

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

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

Given the tool's simplicity (one optional param, clear annotations, output schema present), the description fully covers what the tool does and returns. No missing critical information.

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 'days', which includes its own description (enum values 7,30,90 and default). The tool description does not add further parameter meaning. 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 'Quick business overview' and lists specific metrics (total leads, quotes, jobs, revenue, leads this week). It distinguishes itself from the sibling 'analytics.detailed' by claiming to be 'lighter and faster than full analytics', leaving no ambiguity about its purpose.

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

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

The description implies usage for quick overviews versus detailed analysis, but does not explicitly state when not to use or name the exact alternative. The sibling name 'analytics.detailed' provides context, but explicit guidance is lacking.

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 tool is known to be read-only. The description adds the behavioral context that it requires a specific subscription plan, which is useful information beyond annotations. No contradictions.

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

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

The description is a single, clear sentence that covers the tool's purpose and a key requirement. 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?

Given the tool has one parameter with full schema coverage, an output schema, and clear annotations, the description is complete enough. It lists the analytics domains covered, and the schema details the period parameter. 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?

The single parameter 'days' is fully covered by the input schema (enum, type, description). The main description does not add any additional meaning about parameters, but with 100% schema coverage, this is acceptable. 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 provides 'Detailed business analytics' and lists specific types (conversion funnel, revenue trends, etc.), distinguishing it from siblings like analytics.dashboard (likely high-level) and analytics.financials (likely finance-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 the requirement 'Requires Growth plan or above' which is a usage prerequisite. However, it does not provide explicit guidance on when to use this tool versus its siblings (analytics.dashboard, analytics.financials), so usage context is implied but not contrastive.

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 doesn't need to reiterate safety. It adds value by specifying the metrics included, which goes beyond annotations. However, it doesn't describe other behavioral traits like pagination, data freshness, or aggregation method.

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

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

The description is a single, well-structured sentence that immediately states the tool's purpose and lists key metrics. It is front-loaded and contains no filler or redundancy.

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

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

The tool is simple with one optional parameter and an output schema (indicated). The description adequately covers the purpose and metrics. It omits details about output formatting, but that is handled by the output schema. It feels complete for the complexity level.

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

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

Schema description coverage is 100% for the single parameter 'days', so the description adds no new semantic information beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool provides a financial summary with specific metrics: revenue, quote volume, conversion rate, lead count, and paid invoices for a time period. It distinguishes from sibling analytics tools like 'analytics.dashboard' and 'analytics.detailed' by listing concrete metrics, but doesn't explicitly contrast 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 lacks any guidance on when to use this tool versus alternatives. There is no mention of usage context, prerequisites, or exclusions. The agent must infer purpose from the metric list alone, which is insufficient for decision-making.

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

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

The description adds value beyond annotations by stating the output is a URL for the human to complete payment, clarifying the tool's role is to initiate but not finalize the transaction. Annotations already indicate a write operation (readOnlyHint=false), and no contradictions are present.

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

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

The description is two concise sentences that front-load the action and output. Every sentence provides necessary information without redundancy or unnecessary details.

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

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

Given the schema coverage and presence of an output schema, the description sufficiently explains the tool's purpose and output (URL). It lacks details on error handling or post-payment behavior, but for a straightforward checkout creation tool, the information is 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?

Input schema has 100% description coverage, with clear parameter descriptions (plan_slug with examples, billing_cycle with enum and default). The tool description does not add further parameter semantics beyond the schema, but it adequately reinforces the context of plan purchase/upgrade.

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

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

The description clearly states 'Create a Stripe Checkout session for upgrading or purchasing a plan,' which precisely identifies the action and resource. It distinguishes itself from sibling tools like billing.get_portal and billing.list_plans by specifying it initiates a payment flow.

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 explains the tool produces a URL for the human operator to complete payment in a browser, indicating when to use it. However, it doesn't explicitly list alternatives or when not to use it, though context from sibling tools provides some differentiation.

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 confirms it's a read operation returning a URL. It adds value by detailing what the portal allows (update payment methods, view invoices, change plans, cancel). 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?

Two sentences, front-loaded with action and resource, no extraneous words. Every sentence serves a purpose: what it does and what it requires.

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

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

Given the simplicity (no params, read-only, output schema present), the description is complete. It covers purpose, preconditions, and what the portal enables.

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 (schema empty, coverage 100%). Baseline for 0 params is 4. Description naturally adds no parameter info, which is acceptable here.

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 gets a Stripe Billing Portal URL for managing subscriptions, with specific actions listed (update payment methods, view invoices, etc.). It distinguishes from siblings like billing.create_checkout (new subscriptions) and billing.status (status checks).

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

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

The description says 'Requires an existing Stripe subscription,' which sets a clear precondition. It implies use when a human needs to manage billing, but does not explicitly mention alternatives (e.g., billing.create_checkout for new subscriptions, billing.list_plans for browsing). Slight gap, but context is clear.

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

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

Annotations already provide readOnlyHint=true. The description adds that the data is 'public information,' reinforcing the read-only and non-destructive nature. It does not mention rate limits or caching, but the combination with annotations is sufficient for transparency.

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

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

The description is two short sentences. The first sentence states the purpose and content, the second provides context. Every word earns its place; no fluff.

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

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

Given no parameters, a valid output schema (as indicated in context), and annotations, the description fully covers what the tool does and what data it returns. No gaps are apparent.

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

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

There are no parameters, so schema description coverage is 100% by default. The description adds value by explaining what the output contains (pricing, features, limits, feature flags) and that it is public, which goes beyond the empty 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 lists all available plans with pricing, features, limits, and feature flags. This is a specific verb (list) on a specific resource (plans) with detailed content. It distinguishes from sibling tools like billing.create_checkout and billing.status, which are for purchasing and status respectively.

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

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

The description says 'Public information — useful for discovering what plans exist before purchasing or upgrading.' This gives clear context on when to use the tool (before purchase/upgrade). It does not explicitly mention when not to use or alternatives, but the context is sufficiently clear for an agent.

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

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

Annotations provide readOnlyHint=true; description aligns with 'check' and adds 'feature access' context. Consistent, no contradiction, but does not add extra behavioral detail beyond read-only nature.

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

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

Two concise sentences, front-loaded with action and resource, no 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 no parameters and presence of output schema, description adequately covers tool purpose. Could mention that it returns current plan details, but output 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?

No parameters, schema coverage 100%. As per guidelines, baseline 4 for zero params. Description adds no param info (not needed).

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 'check' specifying what is checked: subscription status, plan details, billing cycle, feature access. No sibling duplicates this exact function.

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

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

States usefulness for understanding capabilities on current plan, but does not explicitly differentiate from siblings like billing.list_plans or billing.usage. No when-not guidance.

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

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

The description adds context beyond annotations: it specifies what metrics are checked (API calls, SMS, email, LLM credits) and the comparison against plan limits. The annotations already declare readOnlyHint=true, which aligns with the check operation. The description provides useful behavioral details without contradicting annotations.

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

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

The description is a single sentence that front-loads the purpose and lists key metrics. Every part is meaningful, no redundant or filler content.

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

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

The tool has zero parameters and an output schema (though not detailed here), so the description adequately covers the operation. It identifies the specific usage categories checked. Slightly more detail on the return format (e.g., usage vs limits) could be added, but with the output schema present, it is sufficiently 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 input schema has zero parameters, and schema coverage is 100%. Baseline for zero parameters is 4. The description does not need to document parameters and appropriately focuses on the operation. No additional parameter meaning is necessary.

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 'Check' and specifies the resource 'API and resource usage vs plan limits', listing concrete items like API calls, SMS credits, email credits, and LLM calls remaining. It effectively distinguishes from sibling billing tools such as billing.status (likely overall status) and billing.list_plans (listing 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 context (checking usage against limits) but does not explicitly exclude alternatives or mention when not to use this tool. The context is clear enough for the agent to infer typical usage, but lacks explicit guidance on sibling tools like billing.status or analytics.dashboard.

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

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

Annotations already indicate readOnlyHint=true, and the description adds value by detailing the return content (revenue, invoices, etc.) and mentioning a 'value context' showing time saved. This complements the annotations without contradiction, though it lacks explicit discussion of any edge cases or limitations.

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

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

The description is well-structured with a clear opening sentence and a bullet-like list of outputs. It is informative but not overly verbose. A slight improvement could be trimming the final sentence's redundancy, but overall it is concise and organized.

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

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

Given that an output schema exists, the description covers the key return elements and use cases. It addresses common cash flow questions. However, it does not mention any configuration options or variations in the forecast period, which could be needed for full context.

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

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

The input schema has zero parameters with 100% coverage, so no parameter explanation is needed. The description focuses on what the tool returns rather than parameters, which is appropriate. It does not add parameter semantics because there are none, but this is fine.

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 the tool as a 30-day cash flow forecast with a weekly breakdown, listing specific financial elements. It distinguishes itself from sibling tools like analytics.dashboard by focusing specifically on cash flow, and it includes explicit use cases ('Can I afford to hire?'), making the purpose highly specific and actionable.

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

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

The description provides clear use cases ('Essential for answering...'). However, it does not explicitly state when not to use this tool or compare it to alternatives like analytics.financials, which could clarify when to choose this over others.

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 lists additional output fields (job count, quote count, revenue) but does not disclose rate limits, pagination behavior, or data freshness. Adds minimal 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 concise sentences that immediately state purpose and utility. No 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?

With output schema present, description adequately covers filtering criteria and extra fields. Sufficient for a list tool with no complex side effects.

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

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

Single 'limit' parameter has 100% schema description coverage, so the schema already documents its meaning. The tool description adds no extra semantics for 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?

Specifies verb 'list', resource 'clients', and clarifies that it only includes leads with at least one job, distinguishing it from leads.list. Provides additional context on returned data fields (job count, quote count, revenue).

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 'useful for identifying repeat customers' but does not explicitly mention when to use vs alternatives or when not to use. No alternative tools named or exclusions 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 aligns with the readOnlyHint annotation by stating 'View' history, implying no destructive actions. It adds filtering capabilities but does not disclose other behavioral traits like rate limits, authentication needs, or return format. Since annotations already convey read-only nature, the description provides minor added 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 two sentences long, no unnecessary words. It front-loads the purpose and filtering options, then adds a use case. Every sentence contributes value, making it highly concise and well-structured.

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

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

The tool has 3 optional parameters and an output schema. The description covers purpose and filtering but omits details like sorting, pagination (limit is explained in schema), and the fact that 'delivery status' is not a filter. The error about delivery status reduces completeness. Overall, adequate but with a notable gap.

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

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

The description claims filtering by 'delivery status,' but the schema does not include such a parameter, creating misleading information. The schema covers all three parameters (type, limit, channel) with descriptions, so baseline is 3, but the inaccuracy reduces it to 2. The description adds the 'auditing' use case but fails to accurately reflect available filters.

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: 'View sent SMS and email message history.' It specifies filtering options ('Filter by channel, message type, or delivery status') and a use case ('Useful for auditing communications'). This distinguishes it from sibling tools like comms.send_email and comms.send_sms, which are for sending, not listing.

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

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

The description provides context for when to use the tool ('auditing communications') and implicitly differentiates it from sending tools. However, it does not explicitly state when not to use it or mention alternative tools for similar purposes. Given the clear domain (communications history), the guidance is adequate 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 indicate mutation (readOnlyHint=false) and side effects (openWorldHint=true). Description adds quota and HTML support but lacks details on quota enforcement, error handling, or cost implications.

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?

Extremely concise (two sentences) with main action first. No unnecessary words. Front-loaded with clear purpose.

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

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

Covers core function and key constraints (quota, HTML) but insufficient for a mutation tool with open world hint. Missing details on quota limits, error states, and side effects. Output schema exists but not described.

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 completely (100% coverage). Description redundantly notes 'HTML body supported' which matches schema body description. No additional semantics 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 'Send an email on behalf of the company,' which is a specific verb+resource. Distinguishes from sibling comms.send_sms by being for email, 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?

Implied usage for sending emails, but no explicit guidance on when to use vs alternatives (e.g., send_sms) or when not to use. Mentions quota as a constraint but not how to handle 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 indicate readOnlyHint=false and openWorldHint=true. The description adds behavioral context: the SMS must be to an Australian mobile number and is subject to a monthly quota. It does not contradict annotations and provides useful constraints beyond what annotations offer.

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-load the primary purpose and then add constraints. No redundant or 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 the tool complexity (5 parameters, with output schema), the description is fairly complete. It covers the core action, key constraints, and scope. Minor gaps exist in explaining optional parameters (jobId, leadId, messageType) but the schema covers those.

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 all parameters described. The description does not add significant parameter-level meaning beyond the schema, but does provide overarching context (e.g., Australian number requirement relates to 'to' parameter). Baseline 3 is appropriate.

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

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

The description clearly states the verb 'send', the resource 'an SMS message', and the scope 'on behalf of the company'. It also specifies constraints (Australian mobile number, quota). This distinguishes it from sibling tools like 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 mentions the requirement for a valid Australian mobile number and monthly quota, giving context for when to use. However, it does not explicitly differentiate from comms.send_email or provide when-not-to-use guidance, which would strengthen the 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?

The description transparently indicates the output is a draft requiring human review, and references standard regulations. Although annotations include readOnlyHint=true, the generation of a document is not clearly contradictory; the description adds context beyond annotations about the draft nature and plan requirement.

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 convey purpose, regulatory compliance, draft nature, and plan requirement. Every word adds value; 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?

With full schema coverage and an output schema, the description covers necessary context: regulatory compliance, draft alert, and plan requirement. It is complete enough for the tool's complexity.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds minimal to parameter semantics, briefly noting output content (hazards, controls, PPE, emergency procedures) but not directly enhancing parameter understanding.

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

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

The description explicitly states it generates a site-specific SWMS compliant with specific regulations and standards. The verb 'generate' and resource 'SWMS' are clear, and the regulatory references differentiate it from any siblings.

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

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

The description mentions the output is an AI draft that must be reviewed and signed, and requires a Growth+ plan. However, it does not explicitly state when not to use it or compare to alternatives, which is acceptable given no direct 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 indicate readOnlyHint=false and openWorldHint=true, consistent with the description of writing to external storage. The description adds auto-generation behavior but lacks details on side effects like file overwrite behavior or error handling. No contradiction with annotations.

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

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

Two sentences with no wasteful words. Front-loaded with the key action and destination, followed by the auto-generation detail. Every sentence adds necessary 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 existence of an output schema (which presumably documents return values), the description covers the essential input and behavior. It could mention whether the file URL is returned, but completeness is adequate for a filing 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 parameters. The description adds value by explaining that entityType drives auto-generated folder paths, enhancing understanding beyond the schema. This justifies a score above baseline 3.

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

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

The description clearly states the action (file a document) and the destination (connected cloud storage) with specific resources (Google Drive/Dropbox). It distinguishes from sibling tools by mentioning organized company folder structure and auto-generation based on entity type, which no other sibling tool covers.

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 (filing documents to cloud storage with automatic organization) but does not explicitly state when to use this tool over alternatives or provide exclusions. No mention of prerequisites or 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 behavioral context beyond that by explaining the referral commission mechanism and that agents can refer other agents and businesses. 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 that front-load the purpose and add relevant context. Every word earns its place; no redundancy.

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

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

For a simple read tool with no parameters and an existing output schema, the description covers all necessary context: what it retrieves, why it's used, and the commission mechanism. Complete for the tool's complexity.

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

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

The tool has zero parameters, and schema coverage is 100% trivially. Per guidelines, baseline is 4 for zero params. The description adds no parameter info as none is needed.

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 the company referral link and code, with a specific verb 'Get' and resource. It differentiates itself by explaining its purpose in generating commission for referrals, which no sibling tool directly addresses.

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 use (sharing with tradies to earn commission) and mentions target users (agents, businesses). However, it lacks explicit alternatives or when-not-to-use conditions, though the tool's simplicity and lack of similar siblings make this less critical.

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

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

Annotations declare readOnlyHint=true, and the description's 'Get a checklist' is consistent with a read operation. The description adds value beyond annotations by detailing the checklist content (steps, time, costs), but does not mention any edge cases or limitations.

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

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

The description is a single sentence of 20 words, front-loaded with the main verb and resource, and includes key specifics without extraneous information. Every sentence earns its place.

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

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

Given the presence of an output schema (indicated by 'Has output schema: true'), the description does not need to explain return values. It covers the checklist scope comprehensively for a formation tool, and annotations provide read safety 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% – both 'state' and 'trade' parameters are documented. The tool description does not add significant new meaning beyond the schema, only contextualizing that they are used for generating a checklist. 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 retrieves a 'complete step-by-step business formation checklist' for a specific trade and state, listing included items (ABN registration, GST, licensing, etc.) and mentioning time estimates and costs. This is specific and distinct from sibling tools like formation.requirements or formation.demand_hotspots.

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 needing a formation checklist, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., formation.requirements, formation.funding). No exclusions or conditions are stated.

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

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

Annotations already declare readOnlyHint: true and openWorldHint: false, so the description does not need to repeat that. It adds context about the output fields and regional scope, but no additional behavioral traits like rate limits or pagination.

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

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

The description is three short sentences, all necessary: it states the action, lists returned data, and gives a use case. No wasted words, front-loaded with key information.

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

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

Given the presence of an output schema (unseen but implied), the description adequately covers purpose, output fields, and use case. It could mention that results are per trade regionally, but it is sufficiently complete for most scenarios.

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 parameters are well-defined in the schema. The description does not add significant meaning beyond what the schema provides, but it does imply the use of 'trade' and 'limit' contextually.

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

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

The description uses a specific verb 'Get' with a clear resource 'trade demand hotspots across Australian regions', and explicitly states the return fields and use case. It distinguishes itself from sibling tools like formation.location_score and analytics.dashboard by focusing on trade-specific demand 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 includes explicit usage guidance: 'Use to advise where to start a trade business for maximum impact.' This clearly indicates when to use the tool, though it does not mention alternatives 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. Description adds context: it's for Australian government programs targeting trade businesses, and filtering by category. No behavioral surprises beyond what 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?

Two concise sentences with no unnecessary words. First sentence states purpose and scope; second explains filtering. Information is front-loaded effectively.

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 optional parameter and an output schema, the description covers purpose, scope, filtering, and target audience. No critical information is missing.

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

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

Schema coverage is 100% with description for the 'category' parameter. The description adds value by listing the valid categories (apprenticeship, small-business, export, digital, training) which helps the agent understand available filters.

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 action 'Get' and specific resource 'Australian government grants, incentives, and funding programs'. It distinguishes from sibling tools like funding.eligibility_scan and funding.program_details by indicating it retrieves a broad list with optional category filter.

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 explains when to use this tool (when needing available funding programs) and how to filter by category. However, it lacks explicit guidance on when not to use it or alternatives like funding.eligibility_scan or funding.program_details.

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?

Description discloses outputs and non-modifying nature (read-only plan generation), aligning with readOnlyHint annotation. Adds context about return structure 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?

Front-loaded purpose, compact single paragraph listing six output types. Slightly dense but efficient, earning 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?

Covers purpose, inputs, outputs (including output schema existence), and usage order. Adequately complete for a complex tool with high parameter coverage.

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 description need not repeat parameter details. Description summarizes key parameters (trade, state, qualifications, budget, goals) but adds little 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?

The description explicitly states it is the recommended entry point for business formation, lists specific outputs (pathway, task list, portal links, etc.), and distinguishes itself from siblings like formation.checklist and formation.requirements by being the first call.

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?

Directly instructs to call this FIRST and then use the recommended tool chain for deeper dives, providing clear when-to-use and alternative guidance.

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

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

The description adds behavioral details beyond the readOnlyHint annotation, including the score range (0-100), the factors considered, and the return of a score breakdown and recommendation. 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 very concise: two sentences that front-load the core purpose and include key details about factors and return. Every sentence is valuable.

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

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

With 2 parameters, an output schema (implied by title), and clear mention of score breakdown and recommendation, the description is complete for a scoring tool. 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?

The input schema already provides detailed descriptions for both parameters (trade lists categories, region describes slug format). The description does not add new meaning beyond the schema, so baseline 3 is appropriate given 100% coverage.

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

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

The description clearly states the tool calculates an opportunity score (0-100) for a specific trade+region combination, with factors and return details. It distinguishes from sibling formation tools like formation.demand_hotspots.

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 usage: it's for a specific trade and region combination, and it cross-references formation.demand_hotspots to discover regions. However, it does not explicitly state when not to use this tool or compare to 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?

The description discloses the tool's behavior: it scores all 9 trade categories across 4 factors and returns top 5 ranked recommendations with detailed outputs. Annotations already indicate readOnlyHint=true, and the description does not contradict them. It adds value by explaining the scoring mechanism and output structure.

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 is informative and front-loaded with the purpose. It uses clear language and covers necessary details without being overly verbose. Could be slightly more structured, but efficiency is good.

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

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

Given the tool's complexity (14 parameters, AI recommendation), the description provides a complete picture of functionality and output. It lists the output details (startup costs, licence requirements, revenue scenarios, etc.), which compensates for the presence of an output schema. The tool's purpose and behavior are fully covered.

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

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

Schema description coverage is 100%, so the schema itself documents all 14 parameters. The description mentions some key inputs (budget, state, goals) but does not add significant new meaning beyond the schema. A baseline score of 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool's purpose: an AI trade recommendation engine that takes user inputs and returns ranked recommendations. It specifies the verb 'recommend', the resource 'trade', and the output (top 5 with detailed factors). This distinguishes it from sibling tools like formation.requirements or formation.demand_hotspots.

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 includes a usage hint: 'Perfect for "what trade should I start?" questions.', implying the tool is for broad trade recommendations. However, it does not explicitly state when not to use it or provide alternatives among the many sibling formation tools. The guideline is clear but not exhaustive.

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 detailing the rich output (licence type, cost estimates, insights, links). It does not conflict with annotations and provides transparency about the toolboxwithout mentioning side effects, which is appropriate for a read-only tool.

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

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

The description is a single sentence that is front-loaded with the core purpose. It uses a list format to enumerate return items, which is efficient. Minor improvement would be brevity, but overall it is well-structured and avoids 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 presence of an output schema and annotations, the description covers the tool's purpose, inputs, and outputs comprehensively. It lacks mention of error handling or prerequisites, but for a straightforward data retrieval tool, it is sufficiently 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 clear parameter descriptions. The tool description adds no new semantic information about parameters beyond what the schema already provides, maintaining 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 Australian states, with a specific verb ('get') and resource. It distinguishes from sibling formation tools by detailing unique return content including trade-specific insights and government links, which are not mentioned in other formation tool descriptions.

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 obtaining requirements but does not explicitly state when to use this tool over alternatives like formation.checklist or formation.recommend_trade. No exclusions or contextual cues are provided, leaving the agent to infer based on tool name and return content.

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 provides rich behavioral context beyond annotations: it discloses that it uses real Australian 2025-26 tax brackets, 10% GST, 12% super rate, and trade-specific cost profiles. It lists all output categories and milestone detection, making the behavior fully transparent and consistent with readOnlyHint=true.

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 appropriately sized (~140 words) and front-loaded with the core purpose. Every sentence adds value: defining the tool, listing inputs, detailing outputs, and noting data sources. No redundant or wasteful 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 complexity (15 parameters, business logic, output schema exists), the description provides sufficient context for an AI agent: it explains what the tool does, the domain (Australian trade businesses), and what outputs to expect. It covers the key decision factors without needing to elaborate on return format or every parameter.

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

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

Schema description coverage is 100% so the baseline is 3. The description only mentions a subset of parameters (trade, state, startup capital, working hours, scenario) and does not add meaning beyond what the schema already provides for the other parameters. It adds value by summarizing key inputs but does not enhance parameter understanding further.

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 it is a '12-Month Business Simulator — financial projection engine for Australian trade businesses' and lists specific inputs and outputs. It clearly distinguishes itself from sibling tools like cashflow.forecast by covering a broader scope and specific Australian tax context.

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

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

The description implies when to use it (e.g., for Australian trade business projection) but does not explicitly state when not to use it or mention alternatives among siblings like cashflow.forecast or analytics.financials. Usage 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 indicate readOnlyHint=true, consistent with 'scan' and 'return' verbiage. No side effects described. Adds context about estimated total funding, enhancing 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?

Two sentences, no fluff, immediately informative. Front-loaded with key action and scope.

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 7 parameters, complete schema descriptions, output schema present, and clear annotations, description covers the purpose and output sufficiently. Does not detail return format but output 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?

Schema has 100% description coverage. Description adds context that tool is for trade businesses, complementing schema. No parameter details beyond schema, but overall adds 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?

Description clearly states it scans over 20 funding programs and returns eligibility for a specific trade business, listing program types and output. Distinguishes from sibling funding.program_details by focusing on broad eligibility vs. specific program details.

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 case (trade business eligibility check) but does not explicitly state when not to use or mention alternatives like funding.program_details. Lacks exclusion criteria.

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

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

Annotations already declare readOnlyHint=true. Description adds specific behavioral context: what information is returned (eligibility, process, tips, links). 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 sentence covering purpose and content efficiently. Could be slightly more structured but is clear and concise.

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

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

Simple tool (1 param, output schema present). Description adequately covers what the tool provides without needing to detail return values.

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?

Only one parameter (programId). Schema description covers it fully (examples, reference to eligibility_scan). Description adds no additional parameter details 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?

Description clearly states it gets detailed information about a specific government funding program, listing included content (eligibility, process, tips, links). Distinguishes from sibling funding.eligibility_scan.

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 use when a specific program is known, but does not explicitly state when to use vs. alternatives. The input schema hints at using eligibility_scan first, but the description itself lacks this guidance.

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

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

The description adds context about the workflow steps but does not disclose behavioral traits beyond what the readOnlyHint annotation already provides. It doesn't mention permissions, rate limits, or side effects, though the annotation indicates it is a safe read operation.

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

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

The description is a single, well-structured sentence that front-loads the purpose. Every word adds value; no redundancy or unnecessary detail.

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

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

Given the output schema exists and schema documentation covers parameters, the description fully explains the tool's domain and scope. It is complete for an agent to understand when and why to use this tool.

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

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

Schema coverage is 100% with descriptive parameter names and descriptions. The description adds overall context (Australian trade businesses, incentive claims) that helps understand the purpose of the parameters, but does not add syntactic detail beyond the schema.

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

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

The description clearly states the tool gets the complete 6-step apprenticeship workflow for Australian trade businesses, listing specific covered steps (finding provider, recruitment, etc.). This is specific and distinguishes from sibling tools that focus on other workflows or analytics.

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 apprenticeship workflow but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusion criteria or alternative suggestions 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 readOnlyHint=true, and the description adds transparency by detailing the outputs (capacity score, burnout risk, lost revenue, urgency). It accurately portrays a read-only analysis without contradicting annotations, though it does not mention potential side effects or data sources.

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, clear sentence that immediately states the tool's purpose and outputs. It is concise with no unnecessary words, well-structured for quick comprehension.

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 9 parameters and an output schema, the description provides a solid overview of what it does and returns. However, it lacks details on when to use it relative to other similar tools, which would enhance completeness.

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

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

The input schema has 100% description coverage, so parameters are already documented. The description does not add extra meaning beyond the schema. It lists required fields in the schema but not in the description, offering no additional semantic 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 the tool analyzes a solo tradesperson's capacity utilization and returns specific metrics like capacity score, burnout risk, lost revenue, and hiring urgency. It is distinct from siblings like 'hiring.readiness_score' which likely assesses general readiness, making the purpose specific and differentiated.

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 others such as 'hiring.cost_calculator' or 'hiring.readiness_score'. The description only states what it does without indicating prerequisites or contexts where it is most appropriate.

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

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

Annotations already indicate readOnlyHint: true. The description adds value by listing the specific compliance areas covered (NES, Modern Awards, STP, etc.), giving the agent a clear understanding of the checklist's content. 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 a single, front-loaded sentence that efficiently conveys purpose and scope without 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?

Given the tool's simplicity (one optional parameter, output schema exists), the description sufficiently covers what the tool does, its geographic scope, and the compliance areas included. No gaps are apparent.

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 coverage is 100% with a description for the only parameter 'category' listing valid values. The description adds minimal extra meaning beyond the schema; it restates filtering. With high coverage, 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 'Get the Fair Work compliance checklist for hiring employees in Australia,' specifying the verb and resource. It distinguishes itself from siblings like formation.checklist and compliance.generate_swms, which are in different domains or generate different outputs.

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

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

The description implies use when needing a compliance checklist for Australian hiring, but it does not explicitly compare with alternatives or provide when-not-to-use guidance. The context is clear, but lacks direct differentiation from other compliance tools like compliance.generate_swms.

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, and the description aligns with a read-only calculation. However, the description adds no behavioral details beyond what annotations provide (e.g., no mention of auth needs or rate limits). No contradiction.

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

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

Two concise sentences: first states purpose and scope, second lists included components. Front-loaded with essential information, no extraneous 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?

Covers overall purpose and key cost components. Output schema exists to handle return values. Could mention state-specific variations or edge cases for completeness, but sufficient for a calculator tool given schema and 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 coverage is 100%, so baseline is 3. The description adds value by explaining baseSalary context ('Use hiring.wage_data to find market rates') and listing included components (super, workers comp, etc.), enhancing parameter meaning beyond schema definitions.

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, with specific verb 'calculate' and resource 'cost'. It distinguishes from sibling tools like hiring.apprentice_workflow and 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 implies usage for cost estimation but provides no explicit guidance on when to use vs alternatives like hiring.capacity_analysis or when not to use. No exclusions or context-specific recommendations.

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, consistent with the description's calculation purpose. The description adds context about the output (hire-type recommendation) but does not disclose any behavioral traits beyond what annotations provide. No contradiction with annotations.

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

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

The description is two sentences, front-loading the core action and outcome. Every word contributes meaning; there is no redundant or verbose phrasing.

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 10 parameters and an existing output schema, the description adequately covers the tool's purpose and outcome. It does not detail all parameters but groups them meaningfully by dimension. The output schema handles return structure, so the description is sufficiently complete for an agent to understand the tool's role.

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, parameters are fully described in the schema. The description adds value by grouping parameters into three dimensions (financial, operational, systems), providing a high-level semantic structure that aids interpretation beyond individual parameter 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's purpose: calculating a hiring readiness score across three specified dimensions (financial, operational, systems) and making a hire-type recommendation. It uses a specific verb ('calculate') and resource ('readiness_score'), and the output recommendation distinguishes it from sibling tools like scaling.readiness_score or 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 implies the tool is used for assessing business metrics to inform hiring decisions, but it does not explicitly state when to use it versus alternatives like hiring.capacity_analysis or hiring.cost_calculator. The context is clear but lacks direct exclusionary guidance.

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

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

Annotations already declare readOnlyHint=true, and the description adds that the tool shows adapter implementation status (live vs coming-soon). This adds value beyond annotations by clarifying the data scope 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?

The description is two sentences: the first is a clear, informative statement of the tool's action, and the second provides usage guidance. 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?

Given complete schema descriptions, annotations, and presence of an output schema, the description covers purpose, usage, and key output features, making it fully adequate for a read-only discovery tool.

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

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

Schema coverage for parameters is 100%, so the description does not need to add meaning. It correctly implies filtering options but does not expand 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 lists all available integration providers (not just connected ones), specifying the returned information (name, category, auth type, features, adapter status). It distinguishes from sibling tools like integrations.list_connections by emphasizing 'available' vs 'connected'.

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 using the tool to help users discover what they can connect, providing clear context. While it does not explicitly exclude alternative tools, the purpose is self-evident given sibling names.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds value by specifying the data included (last sync results, error logs, supported operations). No contradictions. It provides useful behavioral context beyond the annotations.

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

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

The description is extremely concise: two sentences, no fluff, front-loaded with the core action. Every word earns its place.

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

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

Given the simple schema (1 param), high schema coverage, and existence of output schema, the description adequately covers what the tool does and returns. It mentions key return elements. Could be slightly more explicit about prerequisites (e.g., connection must exist), 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 has high coverage (100%) with one parameter (providerId) described clearly. The description does not add further parameter details beyond what the schema provides, so baseline score is appropriate.

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

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

The description clearly states the tool retrieves detailed status for a specific integration connection, listing concrete data (sync results, error logs, supported operations). It distinguishes from siblings like integrations.list_connections (list) and integrations.sync (trigger).

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

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

The description provides explicit use case: 'diagnosing sync failures'. This gives clear context for when to use the tool. It doesn't explicitly list when not to use or alternatives, but the purpose is distinct enough.

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

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

Annotations already mark readOnlyHint=true. The description adds value by specifying the fields returned and the discovery purpose. However, it slightly misstates the default scope ('active' connections) when the tool can return all statuses, creating minor inconsistency with the schema.

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

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

Two concise sentences with no wasted words. The first sentence states the primary purpose, and the second adds usage context. Perfectly front-loaded.

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

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

The description covers purpose, output fields, and usage context. With an output schema present, it does not need to detail return values. For a simple list tool with two optional filters, 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% with clear parameter descriptions. The description does not add additional parameter semantics beyond the schema, so 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 verb 'list' and resource 'integration connections', specifies the returned fields (provider name, status, last sync time, entity types), and distinguishes from sibling tools like integrations.push_entity and integrations.sync by advising use before pushing/pulling 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?

Provides clear context for when to use the tool ('before pushing/pulling data'), but does not explicitly mention when to use alternatives like integrations.connection_status. The guidance is practical but lacks exclusion criteria.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds valuable context by stating the requirement for an active connection with push capability, which helps agents anticipate failure cases. It does not contradict the annotations.

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

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

The description is extremely concise—two sentences plus an example and a prerequisite. It front-loads the core purpose and uses clear, direct language without any 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?

Given the high schema coverage and existence of an output schema, the description covers the essential aspects: purpose, examples, and a key prerequisite. It does not address error handling or rate limits, but the annotations (openWorldHint=true) suggest some flexibility. Overall, it is sufficiently complete for an agent to use the tool effectively.

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 with descriptions for all three parameters. The description further clarifies the entity types with real-world examples (lead, job, invoice) and mentions provider IDs like slack, xero, discord, adding 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 pushes a specific entity to a connected integration, provides concrete examples (push job to Slack, invoice to Xero), and distinguishes it from sibling tools like integrations.sync, which likely handles bulk syncs.

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 specifies a prerequisite (active connection with push capability) and gives examples of when to use. However, it does not explicitly state when not to use or mention alternative tools 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 provide basic safety hints (readOnlyHint=false, destructiveHint=false). The description adds that behavior depends on provider configuration and requires active connection, but lacks details on side effects like overwriting or creation. No contradiction with annotations.

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

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

Three sentences, each providing essential information: action, behavior, prerequisite. Front-loaded with core purpose. No redundant 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?

The description covers the main function and prerequisite. With an output schema present, return values are not required. It lacks explicit mention of error handling or timeouts, but is adequate for a sync trigger 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?

All three parameters have descriptions in the input schema (100% coverage). The description adds no new parameter-specific meaning beyond mentioning 'direction' implicitly, but baseline is 3 due to full schema coverage.

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

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

The description clearly states the verb (trigger sync), resource (integration connection), and scope (pulls/pushes entities). It distinguishes from siblings like integrations.push_entity by focusing on bulk sync rather than individual entity pushes.

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 prerequisite (active connection) but does not explicitly state when to use this tool versus alternatives like push_entity or list_connections. Usage context is implied rather than explicitly guided.

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 all key behaviors: GET returns overdue invoice details, SEND triggers email/SMS with 3-tier escalation, logging, and recovery tracking. It includes a performance metric (60-70% payment within 48 hours) and notes Stripe integration. Annotations (readOnlyHint: false) are consistent, and the description adds substantial context beyond them.

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

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

The description is fairly long but well-organized, with the main purpose stated upfront, followed by mode-specific details. Every sentence adds value, though it could be slightly tightened without losing clarity. Given the tool's complexity, the length is justified.

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 completely: GET mode return format (overdue invoices with days, chase level, total $), and SEND mode side effects (email/SMS, logging, recovery metrics, payment link). With 3 parameters fully described and an output schema present, no gaps remain for effective 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?

Parameter schema coverage is 100%, and the description enriches every parameter: explains that omitting jobId lists all invoices, includes jobId triggers send, clarifies tone enum values with concrete day thresholds (7+, 14+, 30+), and describes sendSms default behavior. This adds significant meaning 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 finds and chases overdue invoices with two distinct modes: GET (list overdue) and SEND (send reminders). It uses specific verbs and resources, and differentiates from sibling tools like invoicing.recovery by detailing the dual-mode functionality and escalation levels.

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 (no jobId) vs SEND mode (with jobId + tone), providing clear context. However, it does not explicitly mention when to prefer this tool over similar sibling tools like invoicing.recovery or workflows.chase_payment, which would have strengthened the 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 indicate mutability and potential side effects (readOnlyHint=false, openWorldHint=true). The description adds specific behavioral details: creates a payment link if Stripe Connect is active, and returns invoice number, total, and payment URL. It does not describe failure modes or behavior if Stripe is not active, so adequate but not high.

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 covering purpose, behavior with Stripe, required input, and next step. No unnecessary words, efficiently front-loaded.

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

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

For a simple tool with one parameter and an output schema, the description covers the main use case, requirements, and output. It lacks details on error scenarios or what happens when Stripe Connect is inactive, but overall it's sufficiently complete 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?

Schema coverage is 100% with a clear description for jobId: 'Job ID to invoice. Required. The job should be in Completed status.' The tool description adds context (e.g., requires from jobs.list) but does not significantly enhance parameter semantics 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 clearly states the verb 'Generate', the resource 'invoice', and the specific condition 'for a completed job'. It distinguishes itself from siblings by mentioning automatic payment link creation via Stripe Connect, contrasting with tools like payments.send_link. The return values are also listed.

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 requires 'job_id from jobs.list (job must be status=Completed)' and suggests 'Next step: payments.send_link if needed'. This tells when to use and what to do next, though it does not explicitly list when not to use beyond the requirement.

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 by detailing the two returned metrics (total $ and count), which is beyond what annotations provide. However, it does not disclose whether data is real-time or cached, or scope limitations.

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

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

Two sentences with no waste. First sentence states purpose, second adds value proposition. 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 zero parameters and presence of output schema, the description is mostly complete. It specifies what the tool returns. However, it lacks time period scope (e.g., all time, current month) and whether it is company-specific.

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 is empty, so no parameters to describe. Per guidelines, baseline is 4. The description effectively adds meaning about what the tool returns, compensating for lack of params.

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 tracks recovered money from auto-chase reminders, specifying outputs: total $ and count of invoices that were overdue, chased, then paid. It distinguishes from sibling tools like invoicing.chase and analytics.financials.

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 as a 'proof the platform pays for itself' metric but does not explicitly state when to use it versus alternatives or provide when-not guidance. Among many analytics siblings, no differentiation 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?

Discloses that sendReviewRequest defaults to true and consumes email/SMS credits, and that satisfaction rating is optional. Annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) align, and description adds resource consumption details 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?

Three concise sentences: first states purpose and options, second recommends usage, third provides dependencies and next steps. No wasted 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?

With annotations, full schema, and output schema present, the description covers main behavior, options, and workflow. Agent can confidently understand when, how, and what to expect.

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 description reinforces key parameter context: jobId from jobs.list, notes as completion notes, satisfaction rating range, and sendReviewRequest default and cost. Adds meaningful value 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?

The description clearly states the tool marks a job as completed, with optional satisfaction rating and auto review request. It is a specific verb+resource and distinguishes from sibling tools like jobs.create, jobs.list, and jobs.update.

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 'This is the recommended end-of-job action' and provides a clear workflow: requires jobId from jobs.list, then next steps of invoicing.generate → payments.send_link → reviews.request. This provides strong when-to-use and sequence 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 (readOnlyHint=false, destructiveHint=false) are consistent. The description adds behavioral context about auto-set status based on date and requirements beyond the annotations.

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

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

Three sentences, front-loaded with core purpose, no redundancy. Every sentence adds value (purpose, status rules, prerequisites/next steps).

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

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

Covers creation, status, requirements, and workflow. Output schema exists, so return values need not be explained. Minor gaps: no mention of confirmation or error cases, but overall complete for its 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. The description adds extra value by explaining the status logic based on scheduledDate and linking to quotes for pricing context, going 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 'Schedule a job for a lead' with options to link a quote and assign a technician, and distinguishes from sibling tools like jobs.update and jobs.complete by mentioning next steps.

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 prerequisites ('Requires: lead_id from leads.list') and next steps (jobs.update → jobs.complete → invoicing.generate), but does not explicitly state when not to use the tool or provide 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?

The annotations declare readOnlyHint=true, and the description adds value by stating it includes linked lead and quote data and supports cursor-based pagination. This provides behavioral context beyond 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?

The description is two sentences, efficiently front-loading the main purpose and key details. Every sentence adds value, with no redundancy or filler.

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

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

With an output schema present and full parameter documentation, the description covers the main return fields and pagination behavior. It is adequate but could mention ordering or default sorting for full completeness.

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

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

Schema description coverage is 100%, with each parameter already described (limit, cursor, status). The description adds no further parameter-level meaning beyond the schema, achieving baseline for high coverage.

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

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

The description clearly states it lists jobs with specific fields like status, dates, technician assignment, and invoice info, including linked lead and quote data. It distinguishes from sibling tools like jobs.create, jobs.update, etc., by using the verb 'list' and specifying the resource.

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 viewing jobs and mentions cursor-based pagination, giving context for retrieval. However, it does not explicitly state when to use this tool over alternatives like other list tools or when not to use it, but the purpose is clear enough 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 already declare readOnlyHint=true, ensuring safe read. Description adds behavioral detail: returns totals, breakdown by service type, and identifies profitable services. No hidden 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?

Description is moderately concise, front-loaded with purpose. The last sentence ('The insight that separates...') is somewhat fluff but not detrimental. Could be tightened.

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

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

Given no parameters, output schema exists, annotations are present, and description covers return values and business purpose comprehensively. Complete for an agent to understand 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?

No parameters exist in input schema (100% coverage by default). Baseline 4 applies per rule for zero parameters. Description adds no parameter info but is not needed.

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 'Per-job profit analysis for completed jobs' with specific returns (revenue, cost, profit, margin). Distinguishes from sibling analytics tools by focusing on completed jobs and service type profitability.

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 usage for profit analysis of completed jobs, but does not explicitly compare with alternatives like analytics.dashboard or analytics.financials. The context of 'completed jobs' provides some 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?

Description discloses the tool sends notifications and can include ETA, but does not detail side effects like overwriting previous notifications, behavior if contact info is missing, or whether it logs or triggers workflows. Annotations already indicate mutability (readOnlyHint=false) and non-destructiveness.

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

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

Two concise sentences with no redundancy; states action, target, optional input, and benefit. Front-loaded with key verb and resource.

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

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

For a simple notification tool with two parameters and existing output schema, description covers core purpose and benefit. Could mention that it sends to multiple channels or constraints on job state, but still 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?

Input schema covers both parameters with clear descriptions (e.g., 'human-readable text' for eta, 'Must have a linked lead with contact info' for jobId). Description does not add further semantic value beyond schema; baseline 3 is appropriate due to high schema coverage.

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

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

Description clearly states the tool sends an 'on my way' notification via SMS/email with optional ETA, distinguishing it from generic communication tools like comms.send_email or comms.send_sms by specifying the job-related context.

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

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

While description implies usage for improving customer experience before a job, it lacks explicit guidance on when to use this tool over alternatives (e.g., comms.send_email for non-arrival messages) or when not to use it (e.g., if no client contact info).

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 idempotentHint=true and destructiveHint=false. The description adds no behavioral traits beyond the expected update operation. It is consistent but does not disclose side effects or authorization needs.

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

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

Two concise sentences with no filler. The verb 'Update' is front-loaded, and the pipeline sequence is efficiently described.

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 the core update functionality and pipeline progression. Does not explain error cases or that status can also revert to Quoted or Cancelled, but output schema likely handles return details.

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. The description adds pipeline progression context beyond the schema, enhancing understanding of status transitions.

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

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

The description clearly states the tool updates job status, schedule, notes, or technician and mentions pipeline progression (Scheduled → In Progress → Completed). However, it omits other valid statuses (Quoted, Cancelled) from the enum, which could mislead about allowed transitions.

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 siblings like jobs.create or jobs.list. The status parameter schema mentions using jobs.complete for full completion flow, but the description itself lacks usage context.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds behavioral context beyond annotations, such as auto-assigning to the authenticated company and defaulting source to 'mcp'. 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 concise sentences, front-loaded with the core purpose, and contains no extraneous words. Every sentence 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 an output schema present, the description does not need to explain return values. It covers creation, auto-assignment, and source default. It could mention potential side effects or permissions, but it is generally complete for a create operation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explicitly noting the source default and auto-assignment behavior, which are not fully captured in the schema descriptions. However, it does not elaborate on other parameters 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 verb 'create' and the resource 'lead/prospect', and distinguishes itself from siblings like leads.list and leads.update by being the creation operation. It also adds specific context about auto-assignment and default source.

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 creating new leads but does not explicitly state when to use this tool vs alternatives like leads.list or leads.update. No prerequisites or exclusions are mentioned.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. Description confirms the read-only nature but adds no additional behavioral context 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 plus a concise tip. Front-loaded with action and output, 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?

Has output schema explaining return fields. Description covers key context: output fields, filtering, pagination. 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 descriptions cover 100% of parameters with clear meanings. Description adds a tip but no extra parameter semantics beyond schema baseline.

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

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

Clearly states it lists leads and prospects, specifies exact fields returned, and mentions filtering and pagination. Differentiates from sibling tools like leads.create and leads.update.

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 a tip on using leads.create then leads.list to verify. However, does not compare to other list tools like jobs.list or clients.list for when to use this one instead.

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 show idempotent and non-destructive hints. The description adds 'Only provided fields are updated,' reinforcing partial update behavior and no side effects beyond the given fields. No contradiction.

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

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

Two short, direct sentences with no wasted words. The essential information is front-loaded.

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

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

With an output schema present and high schema coverage, the description is fully complete. It identifies the action, usage, and required parameter without needing to explain return values.

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 each parameter has its own description. The description's general statement adds no extra meaning 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 states 'Update an existing lead' with the verb and resource, and specifies the partial update behavior ('Only provided fields are updated'). It 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?

The description tells when to use ('Pass the lead ID and any fields to change') and implies context (updating leads). No explicit when-not or alternatives, but the sibling list makes it clear.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: it returns current stage, signals, transition triggers, recommendations, and blockers. No contradictions, and it enriches the agent's understanding of the tool's output.

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 redundancy. The first sentence states the core action and stages, the second lists the return content. Efficiently front-loads critical 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 complexity (13 parameters, output schema present), the description covers the tool's purpose and outputs thoroughly. It mentions all key return fields and the stage progression, leaving no major 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% with all 13 parameters described. The description adds minimal extra meaning beyond the schema, only hinting that inputs are used to assess stages. Baseline 3 is appropriate as schema carries the load.

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

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

The description clearly states the tool's purpose: assessing business lifecycle stage and returning readiness score, current stage, signals, triggers, recommendations, and blockers. It lists the specific stages (formation to scaling), making it highly specific and distinguishable from generic assessment tools.

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

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

The description implies use for overall lifecycle assessment but lacks explicit guidance on when to use this tool versus siblings like 'scaling.readiness_score' or 'formation.checklist'. No when-not 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.