TempGuru Event Staffing

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

Goes beyond annotations by stating 'Not a real-time inventory check, TempGuru staffs to demand via a 100,000+ worker W-2 network across 345 markets' and warns 'never present the result as a reservation.' The hint about rush windows being worth submitting also provides useful behavioral context that annotations (readOnlyHint=true, destructiveHint=false) do not cover.

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 front-loaded purpose statement, followed by examples, exclusions, and a hint. It is longer than strictly necessary (e.g., the 100,000+ worker network background is tangential), but every section serves a clear role. Overall, it remains compact and easy to scan.

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

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

An output schema exists, so return values need not be detailed. The description covers purpose, what it returns (lead-time guidance), non-real-time behavior, exclusions, and example invocations. The hint about rush windows adds operational context. Combined with annotations and schema, this is a complete picture for selecting and using the tool correctly.

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

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

Schema description coverage is 100% for all four parameters, so the baseline is 3. The description includes usage examples with parameters (e.g., check_availability(date='2026-08-14', city='Dallas')), but it does not add any new parameter details, formats, or constraints beyond what the input schema already provides.

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

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

The description opens with 'Check expected staffing availability for an event' and specifies it 'Returns lead-time guidance based on city tier and how far out the event is.' It also clearly distinguishes itself from tools like get_role_pricing for cost questions and explicitly notes it is not a real-time inventory check, making its purpose and scope unambiguous.

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

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

Provides explicit use cases with example queries ('Can you staff my event on [date] in [city]?', 'What's the lead time for booking brand ambassadors in [city]?', 'Is it too late to staff a [date] event?'). It gives direct exclusions: 'DO NOT use for cost questions (use get_role_pricing)' and 'never present the result as a reservation,' clearly steering the agent toward correct alternatives.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds behavioral details: unfiltered list is capped, single city check returns yes/no and did-you-mean, and nickname/borough resolution. 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?

Well-structured with front-loaded purpose, use cases, examples, and hints. Slightly verbose due to duplicate examples in text and <examples> block, but still efficiently conveys 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 5 parameters (none required), output schema exists, and the tool supports filtering and single-city checks, the description covers all aspects. It explains return behavior (yes/no, total counts, tier breakdown) and provides hints for state and city formats.

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%, giving a baseline of 3. The description adds significant context: 'city' parameter returns direct yes/no + suggestion, state accepts both code and full name, and city resolves nicknames like NYC and Brooklyn. This far exceeds baseline.

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

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

The description clearly states the tool lists cities or checks coverage of one city, with specific verbs and resource. It distinguishes from siblings like check_availability, get_role_pricing, and plan_staffing by explicitly stating what not to use it for.

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

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

Provides explicit when-to-use scenarios (e.g., 'What cities do you cover?', 'Do you cover [city]?') and when-not-to-use with alternative tool names. Includes concrete examples and hints for parameters.

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 destructiveHint=false; description adds that it returns compliance summary and is non-binding legal info, no contradictions. Provides 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?

Front-loaded with purpose, includes examples and hints. Slightly verbose but every sentence adds value. Could be trimmed slightly without loss.

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 single parameter, existing output schema, and sibling tools, description fully covers usage, return details, and caveats. No gaps for this simple tool.

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

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

Schema coverage is 100%, but description adds concrete examples ('CA', 'Tennessee') illustrating the parameter, enhancing clarity beyond the schema description.

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

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

The description clearly states it retrieves 'event staffing compliance summary for a US state' with specific outputs (minimum wage, overtime rules, quirks), distinguishing it from siblings like get_role_pricing.

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

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

Explicitly states when to use (questions about W-2/1099, minimum wage, compliance gotchas), when NOT to use ('DO NOT use for rates'), and directs to alternative get_role_pricing. Also includes legal disclaimer.

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?

ReadOnlyHint and destructiveHint are true and false respectively, and the description reinforces that this is a read/restore operation. It discloses what happens on not-found (expired, unavailable, wrong ID) and advises re-running plan_staffing or reviewing with the user before request_quote.

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?

Concise and well-structured: the purpose is stated first, followed by when to use, what not to do, an example, and hints. Every sentence adds value without redundancy.

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

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

With an output schema present, the description covers the essential context: restoration scope (30 days, non-PII), usage scenarios, error handling guidance, and integration with sibling tools (plan_staffing, save_staffing_plan, request_quote). No gaps.

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

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

Schema coverage is 100% with a detailed description of plan_id (pattern, length, source). The description adds context that the ID must come from plan_staffing or save_staffing_plan and should not be guessed, providing additional semantics beyond the schema.

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

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

Clearly states the tool restores a non-PII staffing plan created by plan_staffing or save_staffing_plan within the last 30 days. Distinguishes from siblings by specifying when to use and explicitly warns against guessing plan IDs.

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

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

Provides explicit use cases: starting a new conversation, changing agent platforms, or continuing a saved plan before requesting a quote. Also includes DO NOT guidance against enumerating plan IDs, plus examples and hints for error handling.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it's an operational summary, not a contract, and explains edge cases like unknown topics returning a list. 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?

Well-structured with examples and hints. Slightly verbose but front-loaded with main purpose and organized for quick scanning. Could trim the <examples> block slightly.

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?

Fully complete given the presence of an output schema (return values defined), annotations, and thorough description covering special cases, usage context, and limitations.

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. Description adds rich beyond-schema context: examples of valid topics, hint that unknown topics return available list, and note about confirm_with_coordinator markers.

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

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

The description specifies the verb 'Get' and the resource 'TempGuru's published booking and procurement policies', listing concrete policy types. This clearly differentiates it from sibling tools like get_cities or get_plan.

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 usage context: 'Use for real booking questions that otherwise require an email'. Includes examples and hints about topic behavior, but doesn't mention specific alternatives or when not to use.

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

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

Annotations already declare readOnlyHint=true, and description adds limitations: only reports received/queued, not yet quote_sent/won. Also notes 90-day retention and that not-found doesn't mean CRM lead is absent. 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?

Concise yet comprehensive: first sentence states purpose, then usage constraints, followed by examples and hints in structured sections. No wasted words.

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

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

Given the tool has an output schema, the description doesn't need to explain return values. It covers purpose, usage, limitations, and edge cases (not-found fallback), making it complete for this simple tool.

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

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

Schema coverage is 100% with a single parameter, so baseline is 3. Description adds context about when the reference is obtained and includes an example, going beyond the schema description. Minor improvement but not fully compensating for absent shared understanding.

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

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

The description clearly states the tool checks if a TempGuru quote request reference was received or queued, with specific context (CRM/queue). It distinguishes from siblings by noting the authless handoff does not create a reference, providing clear scope.

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

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

Explicitly states when to use (after buyer submits form and gets TG reference, or for historical reference) and when not to use (authless MCP handoff). Hints provide follow-up for not-found results.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral specifics: returns national typical + range, methodology, citation, and that brand ambassadors are shown by market tier. This adds useful context beyond annotations.

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

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

The description is well-structured with clear sections: purpose, use cases, exclusions, examples, and hints. Every sentence adds value, 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?

The description covers the tool's core functionality thoroughly: what it returns, methodology, citation format, use cases, and alternatives. An output schema exists, so return details are not needed. Complete for a national benchmark 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 descriptions. The description adds value by explaining that passing tier adds each role's measured span within that tier (tier_usd), and examples show usage. This clarifies the parameter's effect 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 returns all-inclusive W-2 hourly bill rates by role from 407 markets, with typical rate, national range, methodology, and citation. It distinguishes from siblings by explicitly saying not to use for one city's price or building an event budget.

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

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

Explicitly states perfect use cases (e.g., 'What do event staff cost in 2026?') and exclusions (e.g., 'DO NOT use for one city's price (use get_role_pricing) or to build an event budget (use plan_staffing)'). Also includes hints directing to get_role_pricing for one city.

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 destructiveHint=false. The description adds valuable context: rates include W-2 pay, workers comp, liability, and payroll taxes. It also warns against presenting as binding quote, which is beyond what annotations cover.

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 purpose, usage examples, and hints. It is somewhat long but every sentence adds value. The use of <examples> and <hints> tags helps parsing.

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, the description adequately explains the return (hourly rate range) and includes important caveats (all-inclusive, non-binding). It covers all necessary aspects for the agent to use the tool correctly.

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

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

Schema describes both parameters (role, city) with examples. The description adds meaningful context: examples of valid inputs, hints that both accept names or slugs, and the special floor value for Brand Ambassadors. This goes beyond the schema alone.

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 all-inclusive hourly rate range for a specific role in a specific city.' It provides example questions that directly illustrate the tool's function, and it distinguishes itself from sibling tools like check_availability and plan_staffing.

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 tells when to use ('What does it cost...' questions) and when not to (DO NOT use for availability or dates; never present as binding quote). Directs to alternative tools: check_availability for dates and plan_staffing for multi-role budget.

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

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

Annotations already declare readOnlyHint and destructiveHint. Description adds that returned slugs are the exact values other tools accept, which is useful context beyond annotations.

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

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

Two sentences plus <examples> and <hints>. Front-loaded with purpose, then usage guidance and practical hints. Zero waste.

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

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

Given no parameters, annotations covering safety, and output schema present, the description fully equips an agent to select and invoke this tool correctly.

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

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

Input schema has 0 parameters and coverage is 100%, so description need not add param details. No gaps.

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

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

Description clearly states 'List event staffing roles TempGuru provides, with descriptions and skill tiers.' It gives explicit question examples ('What kinds of event workers can I hire?') and differentiates from get_role_pricing.

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 'DO NOT use for what a role costs, use get_role_pricing with a city.' Also hints that returned slugs are used by other 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?

Discloses important side effects not visible in annotations: may save a non-contact snapshot for 30 days, never accepts contact details, does not reserve staff or create a quote request, and treats totals as estimates. This goes well beyond the default annotations and clarifies the tool's non-obvious behaviors.

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 dense single paragraph with each sentence contributing actionable information (first-call guidance, inputs/outputs, side effects, fallback logic, status branching). It's somewhat long but free of fluff; a bit more structure (e.g., bullets) could improve scannability for a 4.5, but it remains effective.

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

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

For a complex tool with 6 parameters, multiple statuses, and side effects, the description covers inputs, outputs, edge cases (missing roles, city not found), persistence behavior, and relationship to alternatives. It is self-contained enough that an agent can invoke the tool correctly without needing additional 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?

Although the schema already covers all parameters, the description adds meaningful usage guidance, such as 'Omit roles for the catalog and a suggested mix' and connecting inputs (city, date, roles, headcount) to output types. This elevates beyond the baseline 3, though the schema already does heavy lifting.

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

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

The description uses a specific imperative ('CALL THIS FIRST for event staffing requests') and clearly lists the output dimensions (coverage, rate math, estimates, lead-time, compliance flags). It distinguishes itself from siblings by explicitly directing users to granular tools for a single rate, date, or state fact.

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

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

Provides explicit when-to-use guidance: 'CALL THIS FIRST' and 'Use granular tools only for a single rate, date, or state fact.' It also gives precise fallback logic ('call save_staffing_plan once; never save a plan that already has an ID') and status-based branching, covering alternatives and 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 readOnly/idempotent/non-destructive, and the description adds substantial non-obvious behavior: it never accepts or transmits contact details, never creates a CRM lead or quote reference, demands buyer-side form submission for lead creation, and states it is not a reservation with no pricing/availability guarantee. 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?

Purpose is front-loaded in the first sentence and each subsequent sentence adds a distinct compliance or edge-case fact. The description is dense but justified for a PII-sensitive tool; the final sentence packs a privacy instruction that partially restates sentence two's contact-detail boundary, and mixes two unrelated directives, costing a point.

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

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

Given the rich output schema (return shape need not be explained), the description is complete for its complexity tier: preconditions, exact side-effect boundary, buyer's required action, non-guarantees, and two edge cases (continuation URL without plan_id, expired plans). It fully supports correct agent invocation for a compliance-sensitive flow.

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%, setting a baseline of 3. The description adds value for plan_id by reinforcing the non-PII constraint, tying it to specific producing tools, and adding lifecycle semantics ('re-run an expired plan') plus the explicit instruction to never collect contact details for the call. The three optional attribution params are left to the schema, which already describes them adequately.

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

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

The description states a specific verb+resource: it 'returns a prefilled TempGuru-owned review form' for a saved non-PII plan_id, and explicitly contrasts with what it does not do (never creates a CRM lead or quote reference). This clearly distinguishes it from siblings like get_quote_status (status checking) and plan_staffing/save_staffing_plan (plan production).

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 an explicit precondition ('Use only after the buyer reviews a staffing plan and asks to proceed'), required input provenance (plan_id from plan_staffing or save_staffing_plan), and explicit when-not branches: give continuation.form_url directly when no plan_id exists, and re-run an expired plan. Concrete alternative actions are given for the key edge cases.

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

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

Beyond minimal annotations, the description discloses that the server recomputes rates/totals/lead time/compliance, rejects caller-supplied pricing, and does not reserve staff or submit contact details. It also explains status branching (saved, plan_incomplete, rate_limited, storage_unavailable) and that only 'saved' yields a durable plan_id. This significantly exceeds annotation coverage.

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?

Every sentence earns its place and is front-loaded with the core purpose. Although long, the structure flows from purpose to usage conditions to expected inputs/behaviors to status hints, making it dense and valuable without redundancy.

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

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

The description is complete for a complex save operation: it explains prerequisites, what the server does, what it does not do, and how to handle each possible outcome via hints. The output schema and sibling context are well supported, leaving minimal ambiguity.

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

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

Schema coverage is 100% with each parameter described, so baseline is 3. The description adds important contextual meaning: all inputs must match the previously confirmed plan_staffing result, and the server does not accept pricing or totals. This elevates the score above baseline but doesn't fully redefine 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 tool saves a complete non-contact staffing plan for 30 days, with the explicit verb 'save' and resource 'staffing plan'. It distinguishes itself from siblings by noting it is used only when plan_staffing returned plan_complete:true without a plan_id, and contrasts with request_quote.

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

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

Provides explicit when-to-use and when-not-to-use guidance: 'Use only when plan_staffing returned plan_complete:true without a plan_id' and 'Never call this tool when plan_staffing already returned a plan_id.' It also gives alternative handling for rate_limited or storage_unavailable via continuation.form_url.

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