Server Quality Checklist

Tool Scores

• check_availabilityA
  4.5/5.0
  Behavior4/5

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

  Despite annotations covering readOnly/non-destructive, the description adds valuable behavioral context: it clarifies the result is guidance, not a commitment; final coverage requires coordinator confirmation; and results must not be shown as reservations. This exceeds what annotations alone convey, even if it doesn't detail the output structure (which the output schema covers).

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

  Conciseness5/5

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

  The description is concise yet information-dense, with the core purpose front-loaded, followed by caveats, a 'DO NOT' that points to a sibling tool, and a strategic hint. Each sentence serves a clear function in guiding correct invocation.

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

  Completeness5/5

  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, full parameter schema coverage, and behavior annotations, the description adds the right amount of extra context—tier-based, not a reservation, coordinator confirmation, and a useful market hint. The tool is well-specified for each aspect an agent needs to decide whether and how to call it.

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

  Parameters3/5

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

  The input schema already covers all parameters with descriptions (100% coverage). The description adds useful examples demonstrating optional role and count but does not add deeper semantics beyond the schema. The schema handles the parameter documentation well.

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

  Purpose5/5

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

  The description states a specific, distinct purpose: return tier-based lead-time guidance for an event date and configured market. It includes concrete example queries and explicitly differentiates itself from real-time inventory checks and cost queries (get_role_pricing), so an agent can clearly tell it apart from sibling tools.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use guidance with natural language examples, explicit exclusions, and names the alternative tool for cost questions. It also includes a hint about rush windows and instructs the agent not to present the result as a reservation. This is thorough and actionable.

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

• get_compliance_by_stateA
  4.6/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond the annotations: it returns regulatory information, flags that it is not legal advice, and adds a daily-overtime hint (CA, AK, NV, CO). This is meaningful supplementary context.

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

  Conciseness4/5

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

  The description is front-loaded with the core purpose and return contents, followed by targeted usage examples, an explicit exclusion, and a useful hint. It is slightly verbose due to the example questions, but each part adds practical guidance, so the length is justified.

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

  Completeness5/5

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

  For a single-parameter read-only lookup with a rich schema, an output schema, and annotations already present, the description is complete. It covers what the tool returns, when to use it, when not to use it, the non-advice caveat, and an operational hint about daily-overtime states.

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

  Parameters4/5

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

  Schema coverage is 100% and the single 'state' parameter is already well described as accepting either a two-letter code or full state name. The description adds value with concrete example calls such as state='CA' and state='Tennessee', reinforcing accepted formats and making invocation unambiguous.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Get the event staffing compliance summary for a US state', and lists what it returns (minimum wage, overtime rules, state-specific quirks). It also distinguishes itself from get_role_pricing by explicitly disclaiming rates, so an agent can clearly separate this tool from its siblings.

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

  Usage Guidelines5/5

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

  The description gives concrete example questions that should trigger this tool, explicitly says 'DO NOT use for rates (use get_role_pricing)', and includes a 'NOT legal advice' caveat. This provides clear when-to-use and when-not-to-use guidance with a named alternative.

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

• get_rolesA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds useful behavioral context beyond annotations: the tool returns slugs that are the exact values other tools accept, and that entries include descriptions and skill tiers. This helps the agent predict integration behavior, meriting a score above baseline.

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

  Conciseness4/5

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

  The description is slightly longer than typical for zero parameters but each element earns its place: the first sentence states the core purpose, the question examples clarify usage, the DO NOT sentence provides routing, and the hints add cross-tool integration value. It is structured with clear separation, just slightly verbose.

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

  Completeness5/5

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

  For a zero-parameter, read-only tool with a high-quality output schema, the description covers everything an agent needs: what the tool does, when to use it, when to avoid it, how it integrates with other tools, and expected content. No meaningful gap remains.

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

  Parameters4/5

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

  The tool has zero parameters and 100% schema coverage, so no parameter documentation is needed. The description further reinforces this with an example call get_roles() showing it accepts no arguments, which is helpful for the agent. A 4 aligns with the 0-parameter baseline.

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

  Purpose5/5

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

  States a specific verb and resource ('List event staffing roles TempGuru provides') and immediately separates itself from get_role_pricing by explicitly naming it as the alternative for cost questions. The example user questions anchor the resource in concrete intents, leaving no ambiguity about what get_roles returns.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use signals via representative question examples ('What kinds of event workers can I hire?', 'Do you have brand ambassadors?') and explicitly states when not to use it ('DO NOT use for what a role costs, use get_role_pricing with a city'). Names the sibling tool directly, leaving no inference required.

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

• plan_staffingA
  4.6/5.0
  Behavior5/5

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

  The description goes well beyond annotations by disclosing side effects like saving a non-contact snapshot for 30 days, returning plan_id and continuation, not confirming coverage, not accepting contact details, and treating totals as estimates. It also tells the caller to branch on specific statuses, giving a clear behavioral contract.

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

  Conciseness4/5

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

  The description is dense but every sentence contributes important operational guidance. It is longer than average, but the length is justified by the complexity of the tool's branching, side effects, and exclusions.

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

  Completeness5/5

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

  It covers main use, limitations, follow-up tools, side effects, parameter behavior, and status branching. With an output schema present, the lacking return-format detail does not create a gap.

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

  Parameters3/5

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

  The schema has 100% documented parameter coverage, so the description is not required to add param-level detail. It does call out inputs like city, date, roles, and headcount and mentions omitting roles for a catalog, but most of this is already captured in the schema descriptions.

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

  Purpose5/5

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

  The description opens with 'CALL THIS FIRST for event staffing requests' and names the concrete outputs: catalog match, W-2 rate math, estimates, lead-time guidance, and compliance flags. It distinguishes itself from granular and persistence tools, making the purpose unmistakable.

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

  Usage Guidelines5/5

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

  It gives explicit when-to-use guidance, instructs to use granular tools for single facts, names save_staffing_plan as the persistence fallback, and says never to save a plan that already has an ID. This is strong usage-routing guidance.

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

• request_quoteA
  4.6/5.0
  Behavior5/5

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

  The annotations already carry readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful non-obvious behavior: it never transmits contact information, never creates a lead itself, requires the buyer to open and submit the form, and does not reserve or guarantee pricing/availability. There is no contradiction with the annotation object.

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

  Conciseness4/5

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

  The description is dense but front-loaded with the trigger condition and key requirement. It is arguably a little long and contains a couple of repeated privacy-related caveats, but each sentence carries a meaningful operational or safety instruction for an agent.

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

  Completeness5/5

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

  Given the schema covers all parameters, an output schema exists, and annotations cover the read-only behavior, the description supplies what is left: preconditions, fallback behavior, expiration handling, and the PII boundary. The tool is fully covered from the perspective of an agent deciding whether and how to invoke it.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline applies. The description does reinforce that plan_id must be a saved non-PII plan reference from plan_staffing or save_staffing_plan, but it adds no new meaning for skill_id, skill_version, or source_platform beyond what the schema already documents.

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

  Purpose5/5

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

  The description names a specific verb and resource: after a buyer asks to proceed, return a TempGuru-owned pre-filled review form for a saved plan_id. It explicitly states the tool does not create a quote reference or CRM lead, which clearly distinguishes its purpose from quote-status or lead-creation tools.

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

  Usage Guidelines5/5

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

  It gives an explicit trigger condition, required input source, and the buyer's required follow-up action. It also gives concrete when-not guidance by saying to give continuation.form_url directly when no plan_id exists, to never collect contact details, and to re-run an expired plan.

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

• get_policiesA
  4.7/5.0
  Behavior5/5

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

  The description goes well beyond the annotations by disclosing how unsupported values are marked, instructing agents to never infer missing numbers, noting that unknown topics return an available-topic list, and adding the interpretive caveat that the output is 'an operational summary, not a contract.' These are high-value behavioral details.

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

  Conciseness5/5

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

  Info is front-loaded with the core purpose first, followed by usage guidance and examples. Every sentence contributes context that affects invocation behavior, and the format with examples and hints is efficiently structured without padding.

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

  Completeness5/5

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

  Given the single optional parameter, rich schema, and annotations, the description is fully complete for invocation. It covers what happens with omission, unknown topics, aliases, unsupported values, and how to treat the response. The output schema exists, so return-value details are not required here.

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

  Parameters4/5

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

  Schema coverage is 100%, so a baseline of 3 applies, but the description adds meaning beyond the enum by explaining that omitting the topic returns all policies or a broader answer, that aliases are accepted, and that unknown topics return the list of available topics. It also provides concrete examples.

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

  Purpose5/5

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

  The description clearly identifies the resource (TempGuru's published booking and procurement policies plus public offers) and uses a specific verb ('get'). It sets the tool apart from sibling tools like get_cities or get_roles by specifying a uniquely policy-related resource and scope.

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

  Usage Guidelines4/5

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

  The description explicitly says to 'Use for real booking questions that otherwise require an email,' which gives clear context for when to invoke it. It does not explicitly list exclusions or alternative sibling tools, but the guidance is strong and contextual.

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

• get_role_pricingA
  4.7/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by explaining that rates are all-inclusive, non-binding, and not a quote, which shapes how the agent should present results.

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

  Conciseness5/5

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

  The description is dense but every sentence earns its place: it defines output semantics, gives user-style queries, routes to alternatives, adds exclusion guidance, and provides examples and hints. It is front-loaded with the core purpose.

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

  Completeness5/5

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

  For a simple two-parameter read-only tool with a full output schema, the description is complete: it states the exact inputs, the meaning of the returned range, the non-binding caveat, and alternative tools for related tasks.

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

  Parameters4/5

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

  Schema descriptions already cover 100% of the parameters with names and slug examples. The description adds value beyond the schema with call examples and a useful pricing hint: 'Brand Ambassadors floor at $40/hour in every market.' This helps agents choose valid parameter values.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Get the all-inclusive hourly rate range for a specific role in a specific city.' It clearly distinguishes itself from siblings like check_availability and plan_staffing through question examples and explicit exclusions.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance with natural language examples, and explicit when-not-to-use guidance: 'DO NOT use for availability or dates (use check_availability)' and 'For a multi-role budget, use plan_staffing.' This leaves little ambiguity about tool routing.

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

• save_staffing_planA
  4.7/5.0
  Behavior5/5

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

  Goes well beyond annotations by stating the server recomputes rates, totals, lead time, and compliance; does not accept client-supplied pricing; does not reserve staff, submit contact details, or request a quote; and saves for 30 days. The status hints also disclose how different outcomes behave 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.

  Conciseness5/5

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

  The description is front-loaded with purpose, then states when/not to call, then summarizes behavior, and ends with structured hint branching. Every major sentence earns its place, and the hints are organized in a readable conditional style despite their density.

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

  Completeness5/5

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

  Given an existing output schema, the description still covers the necessary context: prerequisite conditions, persistence, exclusion of alternatives, server-side behavior, and handling of all possible return statuses. Nothing essential is missing for an agent to decide when and how to call this tool.

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

  Parameters3/5

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

  With 100% schema description coverage, the schema already documents all parameters. The description adds useful integration context, such as submitting the same confirmed values and the server not accepting pricing or totals, but it does not materially deepen per-field semantics beyond what the schema provides.

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

  Purpose5/5

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

  States a specific verb and resource: explicitly save a complete non-contact staffing plan for 30 days with persistence. It clearly distinguishes itself from plan_staffing by saying it is used only when plan_staffing returned plan_complete:true without a plan_id, and it also distinguishes from request_quote by noting it does not request a quote.

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

  Usage Guidelines5/5

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

  Gives an explicit condition for use ('only when plan_staffing returned plan_complete:true without a plan_id and the user needs persistence') and an explicit exclusion ('Never call this tool when plan_staffing already returned a plan_id'). It also provides alternative routing information via status hints, including when request_quote is not appropriate.

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

• get_citiesA
  4.9/5.0
  Behavior5/5

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

  Annotations already mark it read-only, non-destructive, and closed-world, and the description adds important behavior beyond that: catalog presence is not availability/order coverage, a coordinator confirms after buyer submission, nickname/borough resolution works, unfiltered results are capped, and there are 345 configured entries. 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.

  Conciseness5/5

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

  The description is front-loaded with the core capability and key caveat, then lays out intents, alternatives, examples, and hints in a scannable structure. Each section adds distinct value, and the angle-bracketed examples and hints keep the prose tight.

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

  Completeness5/5

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

  For a 5-parameter, 0-required-parameter read-only tool, the description covers what triggers it, how to invoke it for the key 'Do you cover...' case, input-form nuances, cap behavior, and the necessary caveat about confirmation. With an output schema present, return details need not be spelled out; nothing critical is missing.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the parameter semantics are already documented well. The description adds useful extra guidance through concrete examples and hints: state accepts full names, country accepts 'US'/'CA', city resolves nicknames/boroughs, and limit affects returned rows while counts remain in totals. This is meaningful but not essential enrichment.

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

  Purpose5/5

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

  The description states a specific action ('List' / 'match') and a specific resource ('configured market entries'), and further clarifies that catalog presence is distinct from availability/order coverage. It names sibling tools it is NOT (check_availability, get_role_pricing, plan_staffing), so an agent can differentiate it from the rest of the toolset.

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

  Usage Guidelines5/5

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

  It explicitly maps natural-language intents to this tool ('What markets are configured in [state]?', 'Is [city] in the catalog?', 'Do you cover [city]?') and provides the exact invocation pattern with city. It also states when to use sibling tools instead: get_role_pricing for rates, check_availability for dates, plan_staffing for a full plan.

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

• get_planA
  4.9/5.0
  Behavior5/5

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

  Beyond the readOnly and destructive hints, the description discloses the 30-day expiration window, the provenance requirement for plan_id, a do-not-guess/enumerate guardrail, and not-found failure semantics. This adds meaningful behavioral context an agent would not infer from the annotations or schema alone.

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

  Conciseness5/5

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

  The description is appropriately triaged: the core purpose and when-to-use are front-loaded, then the warning guardrail, then an example, then failure and workflow hints. Every sentence earns its place and supports correct invocation without redundant filler.

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

  Completeness5/5

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

  Given the output schema is present, it doesn't need to enumerate return fields. It covers selection criteria, required input provenance, failure interpretation, and post-restore actions, which gives the agent everything needed to call the tool correctly and handle the result appropriately.

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

  Parameters4/5

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

  The schema already covers plan_id thoroughly with a regex pattern, length, and source description, so the baseline is high. The description adds value with 'DO NOT guess or enumerate plan IDs', an explicit example call, and a clear statement that only user-supplied or tool-supplied IDs are valid, which strengthens anti-hallucination behavior.

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

  Purpose5/5

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

  The description uses a specific verb ('Restore') and a precise resource ('complete non-PII staffing plan created by plan_staffing or save_staffing_plan within the last 30 days'). This clearly identifies what the tool does and differentiates it from siblings like get_quote_status or plan_staffing.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use conditions: buyer starts a new conversation, changes agent platforms, or wants to continue a saved plan before requesting a quote. It also provides a fallback action on failure ('re-run plan_staffing') and a workflow guardrail ('Review the restored plan with the user before request_quote'), which is strong practical guidance.

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

• get_quote_statusA
  4.9/5.0
  Behavior5/5

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

  The description adds important behavior beyond the annotations: this is a v1 status stub that only reports received/queued, does not yet expose quote_sent or won, retains status records for 90 days, and not-found results do not prove the CRM lead is absent. This is rich, honest behavior disclosure.

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

  Conciseness5/5

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

  The description is front-loaded with the purpose, followed by concrete usage rules, limitations, an example, and retention hints. Every sentence carries meaningful information, and the structured examples/hints tags make the details easy for an agent to parse.

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

  Completeness5/5

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

  For a simple read-only status-checking tool, this is complete: purpose, usage constraints, sibling distinction, current limitations, retention behavior, and a not-found caveat are all covered. The output schema handles return-value details, so no additional information is needed here.

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

  Parameters4/5

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

  The schema already documents the reference parameter with a pattern, maxLength, and example, so it carries most of the semantic load. The description adds valuable extra context by clarifying that only form-submission references are valid and that the authless request_quote handoff does not generate one.

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

  Purpose5/5

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

  The description uses a specific verb and resource ('Check whether a TempGuru quote request reference was received by the CRM or durably queued'), and clearly differentiates itself from siblings by noting that the authless MCP request_quote handoff does not create a reference. It is precise and disambiguates the tool from request_quote.

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

  Usage Guidelines5/5

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

  Explicit usage conditions are given: 'Use only after the buyer personally submitted a TempGuru website form and received a TG reference, or for a historical reference.' It also states an exclusion — the authless MCP request_quote handoff does not create a reference — making it clear when not to use this tool.

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

• get_rate_benchmarkA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavioral details beyond that: it returns a national typical plus range, handles brand ambassadors by market tier, and describes the optional tier parameter as adding 'tier_usd' data for each role.

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

  Conciseness5/5

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

  The description is more detailed than average, but every sentence contributes: scope, data source, return value, example use cases, exclusions, citation, and parameter hints are all covered. It is front-loaded with the core result and the guidance to use alternative tools.

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

  Completeness5/5

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

  For a tool with two optional parameters, an output schema, and clear annotation coverage, this description is complete. It covers the dataset, measurement scope, tier handling, citation format, and appropriate alternatives. An agent can confidently decide when to invoke this tool and understand the shape of the result before even opening the output schema.

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

  Parameters4/5

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

  Schema coverage is 100%, so parameter basics are already documented. The description adds extra value by explaining what the tier parameter actually does ('adds each role's measured span within that tier (tier_usd)') and by showing concrete example calls with different parameter combinations, which helps an agent understand how to pass arguments correctly.

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

  Purpose5/5

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

  The description clearly identifies the resource (TempGuru Event Staffing Rate Index) and the specific output: all-inclusive W-2 hourly bill rates by role from 407 markets, with a typical rate plus the national range. It also explicitly distinguishes itself from related tools like get_role_pricing and plan_staffing by stating what the tool is NOT for.

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

  Usage Guidelines5/5

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

  Usage guidance is explicit and actionable. It provides example queries, states when to use the tool ('What do event staff cost in 2026?', 'Industry benchmark'), and gives clear exclusions: do not use for one city's price (use get_role_pricing) or to build a budget (use plan_staffing).

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