Server Quality Checklist

Tool Scores

• get_intakeA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals the meaning of `submitted: false` and characterizes `doctor_brief` as a concise, ready-to-read paragraph. This goes beyond a bare 'retrieve' statement, though it does not cover error cases or explicit read-only confirmation. It adds meaningful behavioral context without contradicting any 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 appropriately sized and front-loaded. The first sentence states the core purpose, followed by two explanatory paragraphs that add valuable detail, and ends with a practical example. Every sentence earns its place, with no fluff. The structure flows logically from purpose to behavioral nuance to usage.

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

  Completeness4/5

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

  Given the tool's simplicity (one parameter, output schema present), the description is nearly complete. It explains key return behavior (`submitted: false`), the nature of `doctor_brief`, and names the associated `submit_intake` tool. It does not cover error handling or potential exceptions, but for a straightforward retrieval tool with an output schema, it covers the essential context sufficiently.

  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 0%, so the description must compensate. It provides a concrete example (`get_intake(appointment_id=12)`) and mentions 'for an appointment', which helps clarify that `appointment_id` refers to the appointment's identifier. However, it does not elaborate on the parameter's constraints or format. The example is a minimal compensation; the description adds some meaning but not extensive semantics.

  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 starts with a specific verb+resource: 'Retrieve the intake form for an appointment, plus a ready-to-read doctor brief.' This clearly states what the tool does and distinguishes it from siblings like submit_intake, which is the write counterpart. The added detail about the doctor brief further clarifies the tool's unique output.

  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 provides clear when-to-use guidance: it explains the `submitted: false` return value is 'your cue to collect one with submit_intake', explicitly naming an alternative and the condition for using it. It also instructs on how to use the output ('read that to the doctor'), giving practical usage context beyond mere retrieval.

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

• list_doctorsA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It usefully discloses that availability_summary is a regular weekly pattern, not live openings, and that doctor_id is used by downstream tools. It does not clarify the effect of include_inactive, but the main behavioral caveat is covered.

  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 four short, purposeful sentences plus an example. It is front-loaded with the main action, then provides usage guidance, a caveat, and a usage example with no wasted words.

  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 list tool with an output schema, the description is sufficiently complete. It covers what the tool does, when to use it, the key limitation of availability_summary, and how the result connects to other tools. The missing include_inactive detail is a minor parameter-level issue and does not undermine overall completeness.

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

  Parameters2/5

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

  The only parameter, include_inactive, is not mentioned in the description, and the schema provides no description either. The example call with no arguments implies it is optional, but the active/inactive distinction is left entirely to inference from the parameter name and default. This is a notable gap.

  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 states the tool's purpose: list the clinic's doctors with specialty and usual weekly hours. It also differentiates the tool by noting that the returned doctor_id is what check_availability and book_appointment expect, positioning it distinctly among 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 explicitly says to use this tool first when the caller does not name a doctor, and directs the agent to call check_availability for actual free slots instead of relying on the availability_summary. This provides clear when-to-use and when-not-to-use guidance with an alternative named.

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

• process_due_remindersA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that cancelled appointments' reminders are dropped, failed deliveries stay pending for the next run, and the limit controls batch size. This is meaningful behavioral context beyond the bare operation name.

  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 compact, front-loaded with the core purpose, and uses a clear structure with a short paragraph, Args section, and example. Every sentence contributes useful information without redundancy.

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

  Completeness4/5

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

  The tool has one optional parameter, an output schema, and moderate complexity. The description covers the core processing behavior, edge cases (cancelled/failed), and usage cadence. It omits return-value details, but the presence of an output schema reduces the need to describe them in prose.

  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 only lists 'limit' as an integer with a default of 50, but the description defines it as 'Maximum to process in one pass.' This adds clear semantic meaning that the schema alone does not convey.

  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 'Send every reminder that has come due' and then elaborates that it picks up all pending reminders with passed send times and active appointments. This clearly identifies the tool as a batch reminder-processing action, distinguishing it from the single-purpose sibling tool 'send_reminder'.

  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 phrase 'Run this periodically' gives explicit guidance on when to use the tool, and the details about cancelled and failed reminders explain the operational context. However, it does not explicitly mention when to prefer send_reminder over this tool or list exclusions.

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

• daily_summaryA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the nature of the output (overview, gaps, actionable intakes/reminders) and the default date behavior. It does not mention side effects or explicit read-only status, but the tool is clearly a read-only summary, so the description is reasonably transparent.

  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 compact, front-loaded with purpose, then usage, then parameter details, and an example. Every sentence adds value without redundancy, and formatting improves readability.

  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?

  The complexity is low (one optional parameter) and an output schema exists, so the description covers purpose, usage, parameter semantics, and example. It is complete for an agent to select and invoke the tool correctly without further info.

  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 has one parameter with zero description coverage, so the description entirely compensates. It provides format ('YYYY-MM-DD'), context ('clinic-local'), and default behavior ('Defaults to today') along with a concrete example. This is sufficient for a single optional parameter.

  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 ('Give') and resource ('doctor-by-doctor overview of one day') with clear scope (appointments, free time, gaps). This clearly differentiates it from sibling tools like get_appointments or check_availability, which serve related but distinct purposes.

  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?

  Explicitly provides when to use ('what does today look like?', 'where attention is needed') and highlights actionable elements. However, it does not explicitly mention when not to use it or name alternative tools, so it falls just short of a 5.

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

• get_appointmentsA
  4.6/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full behavioral disclosure. It states that unfiltered calls return everything and advises passing at least one filter for a busy clinic, defines the date as clinic-local, and enumerates valid statuses. It doesn't mention pagination or result limits, but the output schema covers return structure.

  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?

  Every sentence earns its place: main action, use cases, filter warning, parameter explanations, and an example. It is front-loaded and free of fluff.

  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 exists and the tool is a query/list operation, the description covers action, filter combinations, usage contexts, parameter provenance, and the unfiltered-query caveat. This is sufficient for an agent to select and invoke correctly.

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

  Parameters5/5

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

  Schema covers 0% of parameter semantics; the description compensates fully. It explains each parameter: patient_id from find_patient, doctor_id from list_doctors, date format 'YYYY-MM-DD', and status enum. A concrete example ties the parameters together.

  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?

  Description opens with 'List appointments, filtered by any combination of patient, doctor, date and status', which is a specific verb+resource+scope. It distinguishes itself from siblings by explicitly stating it finds the appointment_id needed by reschedule_appointment and cancel_appointment, and supports reviewing a doctor's day.

  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?

  Provides clear contexts: answering 'when is my appointment?', finding appointment_id for reschedule/cancel, reviewing a doctor's day. It also warns that with no filters it returns everything. However, it does not explicitly exclude alternatives like check_availability for open slots, so it lacks explicit when-not guidance.

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

• submit_intakeA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool replaces prior intake data and regenerates a doctor brief as a side effect. It also instructs to record patient statements verbatim and avoid interpretation, adding important non-obvious constraints. However, it doesn't discuss error handling or response format, though the output schema may cover that.

  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 well-structured: it opens with a clear purpose, then gives usage timing, behavioral guidance, parameter definitions, and an example. Every sentence contributes necessary information, and the format makes it easy to scan. The length is justified by the tool's complexity.

  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 tool has 7 parameters, a side effect (regenerating the brief), and no annotations, the description covers all critical aspects: when to use it, what to collect, how to record data, resubmission behavior, and an example. Since an output schema exists, it need not explain return values. The description is fully self-contained for an agent to invoke correctly.

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

  Parameters5/5

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

  The schema description coverage is 0%, so the description must compensate. It does so exceptionally well by providing a dedicated Args section that explains each parameter's meaning and source, e.g., 'appointment_id: From get_appointments or book_appointment,' and gives an illustrative example. This adds significant value beyond the bare schema.

  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 states the tool's purpose: 'Record pre-visit intake for an appointment and regenerate the doctor brief.' The verb 'record' and resource 'pre-visit intake for an appointment' are specific, and the additional detail 'regenerate the doctor brief' distinguishes this from sibling tools like get_intake.

  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 says 'Collect this after booking,' providing clear timing guidance. It also notes that 'Re-submitting replaces the previous intake, so it is safe to call again,' implying a usage pattern. While it doesn't explicitly name alternative tools for exclusions, the context is sufficient for an agent to decide when 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.

• find_patientA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses that the tool returns a count, interprets count values (0 = new, >1 = multiple records), and warns against guessing. This is valuable behavioral context beyond the raw schema. It does not discuss edge cases like empty query or authentication, but the core ambiguity resolution behavior is clearly explained.

  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 compact and front-loaded: purpose in the first sentence, usage context next, count interpretation and real-world rationale, then examples. Every sentence adds value; there is no fluff. The structure flows logically from what to usage to how to interpret results.

  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 tool's simplicity (one param, output schema exists), the description is complete. It covers when to use, how to interpret the count, and what to do in ambiguous cases. The output schema handles return-value specifics, so the description need not repeat that. The only minor gap is lack of explicit error handling, but that is not critical for this straightforward search tool.

  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 only defines 'query' as a string with no description. The description compensates by explaining that query accepts partial name or phone number, and provides concrete examples. It does not specify case sensitivity or phone number formatting, but for a single parameter with 0% schema coverage, this is a solid addition.

  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 begins with a specific verb and resource: 'Search patients by partial name or phone number.' This clearly differentiates it from siblings like register_patient, book_appointment, or list_doctors. It also states the direct use case: 'Use this before booking for someone who says they have been here before.'

  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: use before booking for existing patients. It also provides an alternative: 'A `count` of 0 means they are new: use register_patient.' It further instructs on handling multiple matches: 'When `count` is greater than 1, ask the caller which record is theirs.' This is exactly the when/when-not/alternatives guidance required.

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

• send_reminderA
  4.7/5.0
  Behavior4/5

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

  Given no annotations, the description carries the transparency burden. It discloses delivery channel: 'printed to the server log by default, or SMS when Twilio is configured.' Also notes manual trigger ahead of scheduled time. It does not mention error behavior, but that's acceptable for a simple send action.

  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?

  Five short sentences plus example; each sentence adds value. Front-loaded with primary action; no fluff.

  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?

  Tool is simple (one param, no annotations). Description covers purpose, when-to-use, delivery behavior, and examples. Output schema exists, so return format isn't needed. Adequate for an agent to select and invoke correctly.

  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 provides only appointment_id as an integer with no description. The description compensates with an example call: 'send_reminder(appointment_id=12)' and contextualizes it as 'this appointment's reminder.' However, it doesn't elaborate on semantics beyond the parameter name, so it's helpful but not exhaustive.

  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 a specific verb and resource: 'Send this appointment's reminder now, ahead of its scheduled time.' It clearly distinguishes from the automatic process_due_reminders by stating routine reminders go out on their own.

  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?

  Explicitly states when to use: 'Use when a caller asks to be reminded again, or to confirm details in writing.' Also provides exclusion: 'Normal reminders go out on their own via process_due_reminders — you do not need this for routine bookings.' Names the alternative tool.

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

• add_faqA
  4.8/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full transparency burden. It discloses the action (add), the acceptable content scope, and the required answer format ('Write it as speech, not a document'). However, it does not mention what happens if the question already exists or whether the tool updates or appends, leaving a minor behavioral gap.

  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 well-structured and front-loaded: it states the purpose in the first sentence, then usage triggers, scope constraints, parameter guidance, and a practical example. Every sentence earns its place with no redundancy or 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 tool's simplicity and the presence of an output schema (so return values need no explanation), the description covers all essentials: purpose, when to use, parameter semantics, and content constraints. It is complete enough for an agent to correctly select and invoke the tool.

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

  Parameters5/5

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

  The schema provides only titles and no descriptions (0% coverage), so the description fully compensates. The Args section defines each parameter precisely: 'question' as a caller would ask it, 'answer' as exact speech-ready wording, and 'keywords' as comma-separated synonyms/misspellings with a concrete example. This adds substantial meaning beyond the schema.

  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 'Add an entry to the clinic FAQ' – a specific verb and resource. It clearly distinguishes itself from the sibling answer_faq by being the write counterpart, and further clarifies the scope with 'Only for clinic logistics... Never add medical guidance.' This makes the purpose unambiguous.

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

  Usage Guidelines5/5

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

  It explicitly states when to use the tool: 'when staff tell you something the FAQ does not cover yet, or after answer_faq returns match: "none"'. It also gives a clear exclusion: 'Never add medical guidance; clinical questions must keep routing to the doctor.' Both positive and negative guidance are provided, which is exemplary.

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

• cancel_appointmentA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses that cancellation is irreversible, that the confirm parameter gates the actual cancellation, and that confirming releases the slot and cancels the pending reminder. The preview behavior is clearly explained, giving the agent a complete safety picture.

  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 well-organized with a clear lead sentence, a rationale for the two-step gate, and a concrete example. Every line adds value without redundancy.

  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 that the output schema exists and the operation is relatively simple, the description covers the complete workflow, including prerequisites (appointment_id source), safety protocol, and consequences. Nothing critical is missing for an agent to use this correctly.

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

  Parameters5/5

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

  Schema coverage is 0%, yet the description fully explains both parameters: appointment_id comes from get_appointments, and confirm must be True to actually cancel. The example showing preview vs real call makes the semantics 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 opens with a specific verb and resource ('Cancel an appointment') and immediately distinguishes this from sibling tools like reschedule_appointment by emphasizing it is a cancellation, not a rescheduling. The two-step confirmation gate is also part of its identity.

  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?

  It provides explicit step-by-step instructions (preview first, confirm only after explicit user consent), which is clear guidance. It does not name alternative tools such as reschedule_appointment for when the user wants a different time instead of cancellation, so it falls slightly short of the highest bar.

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

• answer_faqA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the match result handling, the medical question redirect, and the caution about never supplementing clinical information. It even explains the reasoning ('a confident wrong answer about money is worse than a short delay'). This is deeply transparent.

  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 well-structured: a one-sentence summary, a usage directive, bullet-point instructions for match handling, a special case for medical questions, and an example. Every sentence adds value; the bullet format improves scanability without unnecessary 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?

  The tool is simple (one parameter) and has an output schema, so the description doesn't need to explain return types. It covers the essential runtime behaviors (match handling, medical redirect, no improvisation), includes an example, and provides sufficient detail for an agent to invoke and interpret the tool correctly.

  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 input schema has only a 'question' string with no description (0% coverage). The description compensates by using the parameter in the example (answer_faq(question="...")) and by framing the entire tool as 'Answer a question about the clinic.' However, it doesn't explicitly define the parameter's constraints or format beyond the example, so it's not a perfect 5.

  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 states the tool answers questions about the clinic (timings, fees, location, payment, insurance). It distinguishes itself from sibling tools by explicitly contrasting informational vs. transactional uses, making it easy for an agent to select it.

  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 guidance is provided: 'Use this for anything informational rather than transactional.' It also details how to handle different match levels (high, medium, none) and instructs against improvising answers for fees/insurance/policy. This gives clear when-to-use and when-not-to-use context, including the alternative of checking with the front desk.

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

• book_appointmentA
  5/5.0
  Behavior5/5

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

  With no annotations, the description fully carries the burden. It discloses the reminder side effect, validation constraints (free slot, working hours, grid alignment), and error behavior (returns nearest alternatives). It also mentions the confirmation return value, giving a complete behavioral picture.

  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 well-structured: one-sentence summary, procedural guidance, validation constraints, parameter list, and example. Each section adds value and is front-loaded with the main purpose. No extraneous content.

  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?

  Despite no annotations, the description covers prerequisites, validation rules, side effects, parameter meanings, and an example. It is comprehensive enough for an agent to invoke the tool correctly, especially since an output schema exists to handle return values.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate. It does so thoroughly: each parameter has a source or format explanation (e.g., patient_id from find_patient, starts_at in clinic-local ISO 8601, not UTC). An example further clarifies usage.

  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 ('Book'), resource ('appointment'), and an additional side effect ('queue a reminder for 24 hours beforehand'). It clearly distinguishes from siblings like reschedule_appointment and cancel_appointment by focusing on new bookings.

  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 guidance: 'Call check_availability first', and explains how to handle taken slots by offering nearest alternatives. This tells the agent exactly when and how to use the tool, including a prerequisite step and error recovery.

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

• check_availabilityA
  5/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses key behaviors: past slots are excluded automatically, return includes 'next_available' for alternatives, and time zone is clinic-local. This goes beyond the schema and gives the agent confidence in side-effect-free checking.

  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?

  Every sentence earns its place—summary, usage rule, behavior note, parameter details, and example. It is compact yet comprehensive, with clear front-loading of purpose and no redundant phrasing.

  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?

  The description covers standard usage (pre-booking), edge cases (no open slots), and all parameters with defaults. It even explains the 'next_available' field, supplementing the output schema. The tool is fully contextualized within the booking workflow.

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

  Parameters5/5

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

  The Args section compensates for the 0% schema description coverage by explaining each parameter: doctor_id sourced from list_doctors, date format and default, and how days_ahead scans. The example call ties it together, making parameter usage 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 opens with a specific verb and resource: 'Find open appointment slots for a doctor, in clinic-local time.' It clearly differentiates from sibling tools by explicitly positioning itself as a pre-booking check ('Always call this before book_appointment').

  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 provides explicit when-to-use guidance ('Always call this before book_appointment') and practical context for the 'days_ahead' parameter ('Use 7 for "sometime next week"'). It also explains the fallback behavior via 'next_available' for handling empty availability.

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

• register_patientA
  5/5.0
  Behavior5/5

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

  With no annotations, the description fully carries behavioral disclosure. It reveals idempotent behavior (returns existing record with `created: false`), phone number normalization, the non-clinical nature of notes, and the role of dob in distinguishing same-name patients. This gives the agent critical expectations beyond what a schema could provide.

  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 well-structured with a clear purpose, workflow guidance, Args section, and example. No filler sentences; each part adds value, and the length is appropriate for the tool's complexity.

  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?

  The description covers the tool's purpose, workflow (call find_patient first), idempotency, parameter details, and an example. Given the output schema exists, it doesn't need to explain return values beyond the `created: false` flag, which it does. It is complete for an 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.

  Parameters5/5

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

  Schema coverage is 0%, so the description is the only source of parameter meaning. It explains each arg: name, phone (including format normalization), dob (optional, useful for distinguishing patients), and notes (non-clinical). The example call further clarifies usage.

  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 states the tool's function: 'Register a new patient, or return the existing record for that phone number.' It specifies the resource (patient) and the action (register/return), and distinguishes itself from the sibling find_patient by noting it returns existing records rather than just looking them up.

  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 guidance is provided: 'Call find_patient first' and 'Confirm the spelling of the name and the phone number with the caller before calling this.' This tells the agent when and how to use the tool, including prerequisites and a step to avoid duplicate registrations.

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

• reschedule_appointmentA
  5/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses side effects: 'The old slot is released and the 24-hour reminder is re-queued for the new time.' It also states a behavioral rule: cancelled appointments cannot be rescheduled. This goes beyond basic functionality and helps the agent anticipate consequences.

  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 tightly structured: a one-line purpose, then usage guidance, behavioral notes, parameter documentation, and an example. Every sentence earns its place with no redundancy. It is both concise and information-dense.

  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 two-parameter tool with an output schema, the description covers all necessary context: preconditions (check availability), side effects, exclusions, and argument formats. It is sufficient for an agent to invoke the tool correctly without ambiguity.

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

  Parameters5/5

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

  Despite 0% schema description coverage, the description fully explains both parameters: appointment_id is sourced from get_appointments, and new_starts_at requires clinic-local ISO 8601 with a concrete example. This adds meaning beyond the raw schema.

  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 begins with 'Move an existing appointment to a new time and update its reminder,' which clearly identifies the action and resource. It distinguishes itself from sibling tools like cancel_appointment and book_appointment by focusing on rescheduling and reminder updates.

  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 guidance is given: 'Use check_availability first to confirm the new time is free' provides a direct prerequisite and references an alternative tool. 'Cancelled appointments cannot be rescheduled — book a new one instead' gives a clear when-not-to-use condition and suggests an alternative. This is exemplary.

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