Chia Health MCP Server

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

Annotations indicate readOnlyHint=true, which aligns with the 'check' action. The description adds valuable behavioral context beyond annotations: it specifies polling frequency (10-15 seconds), automatic token upgrade on payment detection, and the unlocking of portal tools (care plan, refills, etc.). No contradictions with annotations are present.

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

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

The description is front-loaded with the core purpose, followed by usage instructions and behavioral details in three concise sentences. Each sentence adds essential information without redundancy, making it efficient and well-structured.

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

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

Given the tool's complexity (authentication and payment flow), the description is complete: it covers purpose, usage, behavioral traits, and prerequisites. With annotations providing safety context and an output schema present (implying return values are documented elsewhere), no critical gaps remain.

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

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

The input schema has 100% description coverage, with the parameter 'bearer_token' documented as 'Guest token from auth_verify_otp.' The description adds minimal extra context by repeating this requirement ('Requires the guest token from auth_verify_otp as bearer_token'), so it meets the baseline score of 3 without significantly enhancing parameter understanding.

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

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

The description clearly states the tool's purpose with specific verbs ('check if the patient has completed payment' and 'upgrade the token to full scope'), identifies the resource (payment status and token), and distinguishes it from siblings by explicitly mentioning its role in the authentication flow after sharing a checkout link.

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

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

The description provides explicit usage guidance: 'Call this after sharing the checkout payment link with the patient' and 'Poll every 10-15 seconds.' It also implies alternatives by referencing 'portal tools' unlocked after payment, though it doesn't name specific sibling tools for comparison.

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 destructiveHint=true (implying mutation) and non-idempotent, which aligns with the description's action of resending a code. The description adds valuable context beyond annotations: it specifies the 5-minute expiration window and clarifies that no email is needed, enhancing behavioral understanding without contradicting annotations.

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

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

The description is front-loaded with the core action, followed by usage conditions and prerequisites in two concise sentences. Every sentence earns its place by providing essential information without redundancy, making it efficiently structured and easy to parse.

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

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

Given the tool's complexity (simple resend operation), 100% schema coverage, annotations covering safety traits, and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage, constraints, and prerequisites adequately without needing to explain parameters or outputs in detail.

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

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

Schema description coverage is 100%, with the parameter 'session_id' fully documented in the schema as 'Session ID from auth_start'. The description repeats this requirement but adds no additional semantic details beyond what the schema provides, meeting the baseline for high coverage without extra value.

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

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

The description clearly states the verb 'resend' and the resource 'verification code to the patient's email', specifying the exact action. It distinguishes from siblings like auth_start (initiates) and auth_verify_otp (validates) by focusing on re-sending after expiration or non-receipt, making the purpose specific and differentiated.

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

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

The description explicitly states when to use this tool ('if the original code expired (5-minute window) or was not received') and provides prerequisites ('Requires the session_id from auth_start — no email needed'). It also implies an alternative (using auth_start for initial code) and excludes use without a session, offering clear contextual guidance.

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

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

The description adds valuable behavioral context beyond annotations: it explains that the tool sends a verification code via email with specific subject format, returns a session_id (not a token), and requires no authentication. While annotations indicate destructiveHint=true (implying state change), the description clarifies the exact nature of the destruction (initiating a session with verification). No contradiction with annotations exists.

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 and front-loaded with the core purpose. Each sentence adds value: the first states the action, the second explains the verification mechanism, the third clarifies the return value and next steps, the fourth provides email search guidance, and the fifth gives usage context. No wasted words or redundancy.

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

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

Given the tool's complexity (session initiation with verification), the description provides complete context: purpose, behavioral details (email sending, session_id return), usage timing, and relationship to other tools. With annotations covering safety aspects and an output schema presumably documenting the session_id return, the description fills all necessary gaps without duplicating structured data.

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

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

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description doesn't add significant parameter semantics beyond what's in the schema (e.g., it doesn't explain format constraints like email validation or phone number parsing). The baseline score of 3 is appropriate since the schema carries the parameter documentation burden.

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

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

The description clearly states the tool's purpose: 'Start a patient session by providing their contact information. Sends a 6-digit verification code to the patient's email.' It specifies the verb ('Start'), resource ('patient session'), and mechanism (sending verification code), distinguishing it from sibling tools like auth_verify_otp or auth_resend_otp.

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

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

The description provides explicit usage guidance: 'Call this when the patient is ready to proceed with their medical intake — after browsing medications and checking eligibility.' It also mentions 'No authentication required' and references sibling tools (auth_verify_otp) for next steps, giving clear context on when to use this tool versus alternatives.

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

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

The description adds valuable behavioral context beyond annotations: it explains the token scope ('guest-scope bearer token for intake, consent, order, and checkout tools') and the upgrade path to full scope. While annotations indicate destructiveHint=true (likely for token generation), the description clarifies this is part of a multi-step auth flow without contradiction.

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

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

The description is efficiently structured in three focused sentences: purpose, prerequisites, and next steps. Each sentence earns its place by providing essential information without redundancy. It's front-loaded with the core functionality.

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

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

Given the tool's complexity (authentication with token generation), the description is complete: it explains the purpose, prerequisites, token scope, and subsequent steps. With annotations covering safety hints and an output schema presumably detailing the token, no critical information is missing for agent understanding.

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

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

With 100% schema description coverage, the input schema already fully documents both parameters. The description mentions 'session_id from auth_start' and '6-digit code from the email,' which aligns with but doesn't add significant meaning beyond the schema. This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Verify the 6-digit code') and resource ('sent to the patient's email'), distinguishing it from siblings like auth_start (which initiates the process) and auth_resend_otp (which resends the code). It explicitly identifies the tool's role in the authentication flow.

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

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

The description provides explicit guidance on when to use this tool: 'Requires the session_id from auth_start' establishes a prerequisite, and 'After checkout and payment, call auth_check_payment to upgrade the token' specifies the next step. It clearly differentiates this tool from alternatives in the authentication sequence.

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

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

The description adds valuable behavioral context beyond annotations: it specifies that it 'Releases any held inventory and cancels the associated Stripe PaymentIntent if not yet captured' and 'Requires authentication.' Annotations indicate destructive and non-read-only operations, but the description elaborates on side effects and authentication needs, enhancing transparency.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by critical behavioral details and authentication requirement. Each sentence adds essential information without waste, making it highly concise and well-structured.

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

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

Given the tool's complexity (destructive operation with side effects), rich annotations (readOnlyHint, idempotentHint, destructiveHint), and the presence of an output schema, the description is complete. It covers purpose, behavioral traits, and authentication, leaving return values to the output schema.

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

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

With 100% schema description coverage, the schema fully documents both parameters (checkout_id and bearer_token). The description does not add meaning beyond the schema, such as explaining parameter interactions or usage nuances, so it meets the baseline of 3.

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

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

The description clearly states the specific action ('Cancel an in-progress checkout session') and resource ('checkout session'), distinguishing it from siblings like checkout_complete, checkout_create, and checkout_status by focusing on cancellation rather than completion, creation, or status checking.

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

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

The description provides clear context for when to use this tool ('Cancel an in-progress checkout session') and implicitly contrasts with alternatives like checkout_complete for finalizing sessions. However, it does not explicitly state when not to use it or name specific sibling alternatives, keeping it at a 4.

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 this is a destructive, idempotent, non-read-only operation. The description adds valuable context beyond annotations: it specifies the payment technology (Stripe ACP/SPT), mentions authentication requirements, and references alternative workflows. There's no contradiction with annotations - 'Complete payment' aligns with destructiveHint=true and readOnlyHint=false.

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 perfectly concise with three sentences that each serve a distinct purpose: stating the tool's function, providing usage guidelines, and noting authentication requirements. It's front-loaded with the core purpose and wastes no 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 that this is a payment completion tool with destructive annotations and an output schema exists, the description provides excellent context. It covers the specific technology requirements, alternative workflows, authentication needs, and distinguishes this from sibling tools - all crucial information for an agent to use 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?

With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description doesn't add parameter-specific details beyond what's in the schema, but it does provide important context about the shared_payment_token being 'provisioned by the client platform' which helps understand its source.

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 specific action ('Complete payment') using a specific technology ('Stripe ACP/Shared Payment Token'), distinguishing it from sibling tools like checkout_create (which creates a checkout) and checkout_status (which checks status). It precisely identifies both the verb and resource.

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

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

The description provides explicit guidance on when to use this tool ('Only use this if your platform supports Stripe Agentic Commerce Protocol and can provision an SPT') and when to use alternatives ('If your platform does NOT support ACP, use the payment_url from checkout_create instead, then poll checkout_status'). It also mentions authentication requirements.

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

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

The description adds valuable behavioral context beyond annotations: it discloses the two payment paths (Stripe ACP vs payment link), authentication requirements, and that it returns checkout details. While annotations cover idempotency and destructive nature, the description provides practical payment workflow details that aren't captured in structured fields.

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 efficiently structured: it opens with the core purpose, immediately explains the two payment paths with clear formatting, and ends with authentication requirement. Every sentence serves a distinct purpose with zero wasted words.

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

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

Given the presence of output schema (which handles return values), 100% parameter schema coverage, and comprehensive annotations, the description provides complete contextual information. It covers authentication, payment workflows, and sibling tool relationships without needing to repeat what's already in structured data.

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

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

With 100% schema description coverage, the schema already fully documents both parameters. The description doesn't add any additional parameter semantics beyond what's in the schema, so it meets the baseline expectation without exceeding it.

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

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

The description clearly states the specific action ('Initiate a checkout session') and resource ('for a medication order'), and distinguishes it from siblings like checkout_complete, checkout_status, and checkout_cancel by focusing on session creation rather than completion, status checking, or cancellation.

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?

It provides explicit guidance on when to use this tool (to start payment for an order) and when to use alternatives: checkout_complete for ACP payments and checkout_status for polling payment links. This clearly differentiates it from sibling tools in the payment workflow.

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

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

The annotations already declare readOnlyHint=true, indicating this is a safe read operation. The description adds valuable behavioral context beyond annotations: it explains that the tool 'detects the payment, triggers order fulfillment, and returns the confirmation' - revealing side effects (order fulfillment) that aren't obvious from just 'check status'. It also specifies polling frequency and authentication requirements, though it doesn't mention rate limits or error conditions.

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 efficiently structured with four sentences that each serve distinct purposes: stating the core function, providing usage context, explaining behavioral outcomes, and giving operational guidance. There's no wasted language, and the most critical information (what the tool does) comes first.

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

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

Given that annotations cover the read-only nature, the schema fully documents parameters, and an output schema exists (so return values don't need explanation), the description provides excellent contextual completeness. It covers purpose, usage patterns, behavioral consequences, and operational guidance - everything needed for an agent to use this tool effectively in the checkout workflow.

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

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

With 100% schema description coverage, the schema already fully documents both parameters (checkout_id and bearer_token). The description doesn't add any parameter-specific information beyond what's in the schema. However, it does provide context about how checkout_id relates to checkout_create, which adds some semantic value.

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

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

The description clearly states the specific action ('Check the payment status') and resource ('checkout session'), distinguishing it from sibling tools like checkout_create (creates payment links) or checkout_cancel (cancels sessions). It explicitly identifies the tool's role in detecting payments and triggering order fulfillment, which is distinct from other payment-related tools like auth_check_payment.

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

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

The description provides explicit guidance on when to use this tool ('poll for completion after sending the patient a payment link'), when to poll ('every 5-10 seconds while waiting'), and references a specific alternative ('the payment_url from checkout_create'). It also mentions authentication requirements, though it doesn't explicitly state when NOT to use it.

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

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

The description adds valuable behavioral context beyond annotations: it specifies that updates occur 'before payment is completed' and 'requires authentication.' The annotations already indicate destructiveHint=true and idempotentHint=true, but the description complements this by clarifying the timing constraint and auth requirement without contradicting annotations.

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

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

The description is appropriately concise with two sentences that efficiently convey purpose, scope, and requirements. It's front-loaded with the main action and avoids unnecessary details. However, it could be slightly more structured by explicitly separating usage conditions from behavioral notes.

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

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

Given the tool's complexity (mutation with authentication), rich annotations (destructive, idempotent), and the presence of an output schema, the description is reasonably complete. It covers key behavioral aspects like timing and auth, though it could benefit from more explicit sibling differentiation or error handling notes.

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

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

With 100% schema description coverage, the schema already documents all parameters thoroughly. The description mentions what can be modified ('shipping method, apply promo codes, or update customer details'), which loosely maps to the 'updates' parameter but doesn't add significant semantic value beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Update an existing checkout session') and specifies what can be modified ('shipping method, apply promo codes, or update customer details'), which distinguishes it from siblings like checkout_create or checkout_cancel. However, it doesn't explicitly differentiate from checkout_complete or checkout_status, which slightly reduces clarity.

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

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

The description provides some context ('before payment is completed') which implies when to use this tool, but it doesn't explicitly state when NOT to use it or mention alternatives like checkout_cancel or checkout_complete. It also mentions authentication requirements, but no clear sibling differentiation is provided.

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

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

Annotations provide readOnlyHint=true, and the description adds valuable context beyond this: it specifies that authentication is required (though bearer_token is in the schema), lists the types of consents included (e.g., telehealth, HIPAA), and explains the workflow (consents must be fetched individually and confirmed later). It does not contradict annotations.

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

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

The description is front-loaded with the core purpose, followed by details on returns, included consents, and workflow steps. Every sentence adds value (e.g., listing consent types, explaining next steps), with no wasted words, making it efficient and well-structured.

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

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

Given the tool's moderate complexity, rich annotations (readOnlyHint), and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage context, behavioral details like authentication and workflow, and does not need to explain parameters or outputs further.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (intake_id and bearer_token). The description implies intake_id is needed but does not add meaning beyond the schema's descriptions, such as format or examples, resulting in a baseline score of 3.

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

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

The description clearly states the verb ('Get') and resource ('list of all consent documents a patient must accept before ordering medication'), with specific details about what it returns (consent IDs, titles, summaries, order) and distinguishes it from sibling tools like consent_text (which fetches individual consents) and consent_submit (which confirms them).

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

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

It provides clear context for when to use this tool (to get required consents before ordering medication) and mentions alternatives (consent_text for fetching individual consents, consent_submit for confirmation), but does not explicitly state when not to use it or compare it to all sibling tools like consent_status.

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

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

Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds valuable context beyond annotations: it discloses that this is a 'gate' with downstream implications (order_create will reject if incomplete), mentions authentication requirements ('Requires authentication'), and describes the return format (status of each consent and whether the patient can proceed). This enriches behavioral understanding without contradicting annotations.

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

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

The description is highly concise and front-loaded, with three sentences that each serve a distinct purpose: stating the tool's function, explaining its role as a gate, and noting authentication requirements. There is no wasted language, and the structure efficiently conveys critical information for agent decision-making.

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

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

Given the tool's moderate complexity, rich annotations (readOnlyHint), and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage guidelines, behavioral context (gate function, authentication), and does not need to detail parameters or outputs due to structured data support, making it fully adequate for agent use.

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

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

Schema description coverage is 100%, with both parameters (intake_id and bearer_token) fully documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or additional constraints. However, it implicitly reinforces the intake_id's purpose by mentioning 'patient intake', but this is minimal added value.

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

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

The description clearly states the specific verb 'Check' and resource 'consent status for a patient intake', distinguishing it from siblings like consent_list (list consents) and consent_submit (submit consents). It precisely defines what the tool does: verifying completion of required consents and determining if the patient can proceed to ordering.

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

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

The description explicitly states when to use this tool: as a 'gate' before order_create, which will reject if consents are incomplete. It provides clear context for usage (checking consent completion for an intake) and names an alternative (order_create) with a specific exclusion condition, guiding the agent on when this tool is necessary versus when to proceed directly.

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

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

The description adds valuable behavioral context beyond annotations: it mentions that 'All consent records are retained for 10 years per HIPAA requirements' and 'Requires authentication.' Annotations already indicate it's not read-only (false), idempotent (true), and destructive (true), but the description provides additional regulatory and security details that enhance transparency for the agent.

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 and front-loaded with the core purpose, followed by prerequisites, required parameters, return details, and additional context. Every sentence adds value (e.g., HIPAA retention, authentication requirements) without redundancy, making it efficient and easy to parse.

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

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

Given the tool's complexity (destructive, idempotent, with authentication needs), the description is complete: it covers purpose, prerequisites, key parameters, return values (consent record with details), regulatory context (HIPAA), and security. With annotations providing safety hints and an output schema likely detailing the return structure, no significant gaps remain.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds minimal param semantics beyond the schema, such as examples for patient_confirmation ('e.g. 'I agree'') and agent_platform options, but doesn't significantly enhance understanding. This meets the baseline of 3 when schema coverage is high.

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 specific action ('Record a patient's consent confirmation'), the resource ('for a specific consent document'), and distinguishes it from sibling tools like consent_text (which provides the text) and consent_list/consent_status (which list or check status). It explicitly mentions the verb 'record' and the exact purpose of submitting consent.

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

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

The description provides explicit guidance on when to use this tool: 'The agent must have already presented the full consent text (from consent_text) to the patient and received explicit confirmation.' It names the prerequisite tool (consent_text) and specifies the condition (explicit confirmation received), giving clear context for usage versus alternatives.

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

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

Annotations already declare readOnlyHint=true, but the description adds valuable behavioral context: the agent MUST present content verbatim, includes specific content elements (version number, effective date, etc.), and mentions authentication requirements. 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?

Front-loaded with core purpose, followed by critical behavioral instructions, content details, and prerequisites. Every sentence adds essential information with zero 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 annotations (readOnlyHint), 100% schema coverage, and an output schema exists (mentioned in context signals), the description provides complete context: purpose, usage guidelines, behavioral constraints, content details, and authentication requirements.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add parameter-specific information beyond what's in the schema, but the baseline is 3 when schema coverage is high.

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 specific action ('Fetch the full text'), resource ('a specific consent document'), and purpose ('for patient review'). It distinguishes from sibling tools like consent_list (which lists consents) and consent_submit (which submits consent confirmation).

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 ('before the agent can call consent_submit') and provides clear alternatives by listing available consent types. It also specifies prerequisites ('Requires authentication') and behavioral constraints ('do not summarize or paraphrase').

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 openWorldHint=true, but the description adds valuable behavioral context beyond these annotations. It specifies the exact eligibility criteria (age 18+, specific state requirements, BMI 20+, pregnancy restrictions, disqualifying conditions) and describes what the tool returns (eligibility status, available medications, disqualifying reasons). This provides crucial operational details not captured in the annotations.

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

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

The description is perfectly structured and concise. The first sentence establishes the core purpose, followed by a bullet-like list of specific checks, and concludes with the return values. Every sentence adds essential information with zero wasted words, making it easy for an agent to parse quickly.

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

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

Given the tool's complexity (7 parameters, specific business rules) and the presence of both comprehensive annotations and an output schema, the description provides exactly what's needed. It explains the eligibility logic, mentions the return format, and gives enough context for an agent to use the tool effectively without duplicating schema information.

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

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

With 100% schema description coverage, the baseline would be 3. However, the description adds significant semantic context by explaining how parameters relate to eligibility criteria: age must be 18+, state must be where providers are licensed, BMI must be 20+, pregnancy status has specific restrictions, and medical conditions include disqualifying ones. This connects parameter values to business logic beyond what the schema descriptions provide.

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

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

The description clearly states the tool's purpose: 'Pre-screen a patient's basic eligibility for telehealth prescription services.' It specifies the exact checks performed (age, state, BMI, pregnancy status, medical conditions) and distinguishes itself from sibling tools by focusing on eligibility assessment rather than authentication, checkout, or medication lookup functions.

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

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

The description provides clear context for when to use this tool: for pre-screening patient eligibility before telehealth prescription services. It doesn't explicitly state when NOT to use it or name specific alternatives among siblings, but the context is sufficiently clear for an agent to understand this is an initial screening step in a patient workflow.

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 read-only and open-world hints, which the description aligns with by describing a retrieval operation. The description adds valuable behavioral context beyond annotations: it explains the two-phase structure (pre_checkout and post_checkout), the deduping logic for multiple medications, and the product-aware questionnaire variations. No contradictions with annotations exist.

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

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

The description is appropriately sized and front-loaded, starting with the core purpose. Each sentence adds value: medication-specific variations, multi-medication handling, two-phase structure, and provider context. It could be slightly more concise but remains well-structured with minimal waste.

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

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

Given the complexity (medication-aware logic, multi-phase output) and the presence of both annotations and an output schema, the description is highly complete. It explains key behavioral aspects like deduping and phase structure, which the output schema would detail further, making it sufficient for agent understanding without redundancy.

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

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

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description adds some semantic context by explaining the purpose of 'additional_medications' (for ordering multiple products) and implying 'medication' influences question content, but doesn't provide significant additional parameter details 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's purpose with specific verbs ('Get the full medical intake questionnaire') and resources ('patient needs to complete before a provider can evaluate them for a prescription'). It distinguishes itself from sibling tools like 'intake_status' or 'intake_submit' by focusing on questionnaire retrieval rather than status checking or submission.

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

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

The description provides clear context on when to use this tool: to obtain intake questions for specific medications, with guidance on handling multiple medications via 'additional_medications'. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficiently detailed for informed usage.

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

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

The annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds valuable behavioral context beyond annotations by specifying authentication requirements ('Requires authentication'), the purpose of polling, and the possible return states ('under review, approved, or denied'). It doesn't contradict annotations and provides useful operational details.

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 efficiently structured in three sentences: purpose, return values, and usage/authentication. Every sentence adds essential information without redundancy, making it front-loaded and easy to parse.

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

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

Given the tool's moderate complexity, high schema coverage, readOnlyHint annotation, and the presence of an output schema (which handles return value documentation), the description is complete. It covers purpose, usage context, authentication needs, and behavioral aspects without 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 description coverage is 100%, with both parameters well-documented in the schema (intake_id from intake_submit, bearer_token for authentication). The description doesn't add significant parameter details beyond what the schema provides, but it reinforces the authentication context. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the verb ('Check') and resource ('status of a previously submitted intake questionnaire'), specifying the exact action and target. It distinguishes from sibling tools like 'intake_submit' (submission) and 'intake_questions' (question retrieval) by focusing on status polling after submission.

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

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

The description explicitly states when to use this tool ('to poll for provider review completion before proceeding to order placement'), providing clear context and timing. It also distinguishes from alternatives by specifying it's for checking status after submission, not for other intake-related actions like submission or question retrieval.

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

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

The description adds valuable behavioral context beyond annotations: it specifies that the intake is reviewed by a licensed US healthcare provider who makes prescribing decisions, mentions authentication requirements, and describes the return values (intake ID and estimated review time). Annotations indicate destructiveHint=true (consistent with 'Submit'), but the description enriches this with real-world implications like provider review.

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 front-loaded with the core purpose in the first sentence, followed by prerequisites, return values, and key behavioral details. Each sentence adds essential information without redundancy, making it efficient and well-structured for an AI agent.

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

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

Given the tool's complexity (destructive operation with authentication), the description is complete: it covers purpose, prerequisites, return values, authentication, and provider review context. With annotations covering safety hints and an output schema presumably detailing return values, the description fills gaps effectively without over-explaining structured data.

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

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

Schema description coverage is 100%, so the schema already documents all parameters (e.g., patient_email, intake_answers). The description adds minimal param-specific semantics by referencing 'intake_answers' from 'intake_questions', but does not provide additional details like format or constraints beyond the schema. Baseline 3 is appropriate as the schema handles most param documentation.

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 specific action ('Submit a completed medical intake questionnaire') and resource ('for provider review'), distinguishing it from sibling tools like 'intake_questions' (which likely retrieves questions) and 'intake_status' (which likely checks status). It explicitly mentions what the tool does beyond just the name/title.

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

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

The description provides clear context for when to use this tool ('All fields from intake_questions must be completed'), implying it should be used after gathering intake data. However, it does not explicitly state when not to use it or name alternatives among siblings, such as comparing to 'intake_status' for checking submission status.

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

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

The annotations already provide readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation that may return incomplete data. The description adds valuable behavioral context beyond annotations by explaining that 'Some compounded medications have state-specific restrictions based on pharmacy licensing' and describing the return format ('Returns availability status and reason if unavailable').

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 perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, the second adds important behavioral context about compounded medications and return values. No wasted words, front-loaded with the main functionality.

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

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

Given that this tool has annotations covering safety (readOnlyHint), data completeness (openWorldHint), 100% schema coverage, and an output schema exists, the description provides exactly what's needed. It explains the purpose, adds context about state restrictions for compounded medications, and describes the return format without needing to detail parameters or output structure.

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

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

With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description doesn't add significant parameter semantics beyond what's in the schema - it mentions 'specific medication' and 'patient's state' which align with the schema's medication and state parameters, but provides no additional details about format, constraints, or usage.

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 specific action ('Check if a specific medication is available for shipping') and resource ('to the patient's state'), distinguishing it from sibling tools like medications_list or medications_pricing. It specifies the scope of availability checking with state-specific restrictions for compounded medications.

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

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

The description provides clear context for when to use this tool ('Check if a specific medication is available for shipping to the patient's state'), including the specific use case of state-specific restrictions for compounded medications. However, it doesn't explicitly mention when NOT to use it or name alternative tools for related functions like pricing or details.

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

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

Annotations indicate readOnlyHint=true and openWorldHint=true, which the description aligns with by describing a listing operation. The description adds valuable context beyond annotations by specifying that each category includes a description and count of available medications, which helps the agent understand the output structure. However, it does not mention rate limiting (implied by the client_ip parameter) or other behavioral traits like pagination, keeping it from a perfect score.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose, scope, and output details. It is front-loaded with the main action and resource, followed by examples and additional context, with no wasted words or redundancy.

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

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

Given the tool's low complexity (one optional parameter), rich annotations (readOnlyHint, openWorldHint), and the presence of an output schema, the description is complete enough. It explains what the tool does, provides examples of categories, and describes the output format (description and count), which complements the structured data without unnecessary repetition.

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

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

Schema description coverage is 100%, with the single parameter 'client_ip' fully documented in the schema as for rate limiting. The description does not add any information about parameters, as it focuses on the tool's purpose and output. This meets the baseline of 3, since the schema adequately covers the parameters without needing additional 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 the verb 'List' and the resource 'medication categories available through the telehealth platform', distinguishing it from sibling tools like medications_list (which likely lists individual medications) and medications_details (which likely provides details on specific medications). It specifies the scope as 'all' categories with examples, making the purpose specific and well-defined.

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

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

The description implies usage when needing to browse or understand available medication categories, but it does not explicitly state when to use this tool versus alternatives like medications_list or medications_details. It provides clear context about the telehealth platform and categories, but lacks explicit exclusions or named alternatives, which would be needed for a perfect score.

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

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

Annotations provide readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation that may return incomplete data. The description adds valuable behavioral context beyond annotations by specifying what information is included (dosage strengths, forms, pricing, contraindications, side effects) and that it supports queries by both name and category. No contradiction with annotations exists.

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

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

The description is appropriately sized and front-loaded with the core purpose. Every sentence adds value: the first sentence defines scope, the second explains query methods, and the third provides usage guidance. It could be slightly more concise by combining some elements, but overall it's well-structured.

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

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

Given the tool has annotations (readOnlyHint, openWorldHint), 100% schema description coverage, and an output schema exists, the description provides excellent contextual completeness. It clearly explains what information will be returned, how to query it, and when to use it, making it complete enough for an AI agent to understand and invoke 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%, so the schema already documents all three parameters well. The description adds some value by providing examples of medication names and categories, but doesn't add significant semantic meaning beyond what's already in the schema descriptions. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Get detailed information about a specific medication' and lists specific data elements (dosage strengths, forms, pricing, contraindications, side effects). It distinguishes from sibling tools like 'medications_list' (which likely lists medications without details) and 'medications_pricing' (which likely focuses only on 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?

The description explicitly states when to use this tool: 'Use this to look up exact plan durations and pricing.' It also provides guidance on query methods (by medication name or category) and includes examples of both. This gives clear context for when this tool is appropriate versus 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 declare readOnlyHint=true and openWorldHint=true, which the description aligns with by describing a listing operation. The description adds valuable context beyond annotations: it specifies that medications require evaluation by licensed providers before prescribing and are compounded by US-licensed pharmacies, which are important behavioral constraints not captured in 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 appropriately sized and front-loaded with the core purpose in the first sentence. Subsequent sentences add necessary context about medication types, return data, and regulatory requirements. While slightly dense, every sentence provides essential information that earns its place.

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

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

Given the tool's moderate complexity, rich annotations (readOnlyHint, openWorldHint), and the presence of an output schema, the description provides excellent contextual completeness. It covers what medications are included, what data is returned, important regulatory constraints (pharmacy licensing, provider evaluation), and distinguishes this from other medication-related tools.

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

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

With 100% schema description coverage, the input schema already fully documents the single parameter (client_ip for rate limiting). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.

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

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

The description clearly states the verb 'List' and resource 'all available prescription medications' with specific examples (GLP-1 drugs, peptide therapies, compounded wellness treatments). It distinguishes from siblings like medications_details (detailed view) and medications_pricing (pricing-focused) by emphasizing comprehensive listing with multiple data points (names, categories, forms, starting prices).

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

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

The description provides clear context about when to use this tool - for browsing available medications with comprehensive information. It doesn't explicitly state when not to use it or name specific alternatives, but the context implies this is for initial discovery rather than detailed queries (which would use medications_details or medications_pricing).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation that may return unexpected data. The description adds valuable behavioral context beyond annotations by specifying what data is returned (price breakdown components), mentioning rate limiting relevance (though not explicitly stating limits), and noting plan duration variability by medication. No contradiction with annotations exists.

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 efficiently structured in three sentences: first states the core purpose and return values, second provides crucial usage guidance about dependencies, third lists supported medications. Every sentence adds value with zero redundant information, and key information is front-loaded appropriately.

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 both annotations (readOnlyHint, openWorldHint) and an output schema (which handles return value documentation), the description provides excellent contextual completeness. It covers purpose, usage guidelines, return content overview, and medication scope while avoiding redundancy with structured fields. For a read-only pricing lookup tool, this is comprehensive.

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

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

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description adds minimal semantic value beyond the schema: it mentions that 'plan durations vary by medication' and lists example medications, but doesn't provide additional parameter usage context or constraints beyond what's in the schema descriptions. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose with specific verbs ('Get detailed pricing') and resources ('medication, form, and plan duration'), distinguishing it from sibling tools like medications_list or medications_details. It explicitly mentions what the tool returns ('price breakdown including medication cost, provider consultation fee, shipping, and any applicable discounts'), making the purpose unambiguous.

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

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

The description provides explicit guidance on when to use this tool versus alternatives: it instructs to 'use medications_details first to see available plan_months values' before invoking this tool. This creates a clear workflow dependency and distinguishes it from other medication-related tools like medications_availability or medications_categories.

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 this is a destructive, non-idempotent write operation. The description adds valuable context beyond annotations: it discloses the review process by a healthcare provider, compounding at a pharmacy, shipping details, payment processing via Stripe ACP, and authentication requirements. No contradictions with annotations exist.

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 efficiently structured with no wasted sentences. It front-loads the core purpose, then details prerequisites, required parameters, process flow, return values, and authentication—each sentence adds essential information without redundancy.

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

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

Given the tool's complexity (destructive mutation with multi-step workflow), the description provides comprehensive context: prerequisites, required inputs, review process, shipping, payment, authentication, and return values. With annotations covering safety aspects and an output schema handling return values, the description fills all necessary 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 description coverage is 100%, so the schema fully documents all parameters. The description lists required parameters (medication name, form, plan duration, shipping address) but doesn't add significant semantic details beyond what's in the schema. It mentions 'intake_id' indirectly via prerequisites but doesn't elaborate on parameter meanings.

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 specific action ('Create a new prescription medication order') and resource ('order'), distinguishing it from sibling tools like order_status or order_documents. It provides concrete details about what is being created, making the purpose unambiguous.

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

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

The description explicitly states prerequisites ('patient must have completed intake questionnaire and consent before ordering') and provides clear context on when to use this tool versus alternatives like intake_submit or consent_submit. It also mentions the review process, helping the agent understand the appropriate timing.

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

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

Annotations provide readOnlyHint=true, and the description adds valuable context: it discloses authentication requirements ('Requires authentication') and details what the tool returns (required documents like photo ID, selfie, with upload status and accepted file formats). This goes beyond annotations, though it doesn't mention rate limits or error handling.

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 front-loaded with the core purpose, followed by return details and authentication requirement. Every sentence adds value without redundancy, making it efficient and well-structured.

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

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

Given the tool's moderate complexity, annotations cover safety (read-only), and an output schema exists (so return values are documented elsewhere), the description is complete enough. It covers purpose, authentication, and return context, addressing key aspects without needing to duplicate structured data.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (order_id and bearer_token). The description doesn't add specific meaning beyond what's in the schema, such as explaining parameter interactions or constraints. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the verb ('Get') and resource ('list of documents a patient needs to upload for their order'), specifying it's for required documents with upload status and file formats. It distinguishes from siblings like 'order_status' (general order info) or 'order_upload' (uploading documents).

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?

It explicitly states 'Requires authentication' and implies usage when checking document requirements for a specific order, but doesn't specify when to use this vs. alternatives like 'order_status' or 'consent_status'. The context is clear but lacks explicit sibling differentiation.

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

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

Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds valuable context beyond this by specifying the return data (status, tracking info, delivery estimate) and explicitly stating authentication requirements, which isn't covered by annotations. It doesn't contradict annotations and enhances behavioral understanding.

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

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

The description is front-loaded with the core purpose, followed by return details and authentication requirement. Every sentence earns its place by providing essential information without redundancy, making it efficient and well-structured for quick understanding.

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

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

Given the tool's complexity (simple read operation), high schema coverage, annotations, and the presence of an output schema, the description is complete. It covers purpose, return data, and authentication, addressing key contextual needs without needing to explain return values due to the output schema.

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

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

Schema description coverage is 100%, with clear documentation for both parameters. The description doesn't add meaning beyond the schema, as it doesn't explain parameter usage or constraints. However, the baseline is 3 since the schema adequately covers parameter semantics, and no additional value is needed.

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

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

The description clearly states the verb ('Get') and resource ('current status of a medication order'), distinguishing it from siblings like 'order_create' or 'order_documents'. It specifies the exact domain (medication orders) and what information is retrieved, making the purpose unambiguous.

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

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

The description implies usage by stating 'Requires authentication', which suggests when authentication is needed, but it doesn't explicitly guide when to use this tool versus alternatives like 'checkout_status' or 'intake_status'. No exclusions or clear alternatives are mentioned, leaving some ambiguity in context.

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

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

The description adds valuable behavioral context beyond annotations: it specifies file format constraints ('PDF, JPEG, PNG'), size limits ('Maximum size: 10MB'), and authentication requirements ('Requires authentication'), which are not covered by the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=true). No contradiction with annotations exists.

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 front-loaded with the core purpose, followed by key constraints in a logical order (file types, size, auth). Each sentence adds essential information without redundancy, making it highly efficient and well-structured.

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

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

Given the tool's complexity (upload with authentication and file constraints), the description covers critical behavioral aspects (formats, size, auth) that annotations and schema do not fully address. With an output schema present, return values need not be explained, making this description complete for agent use.

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

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

With 100% schema description coverage, the schema already documents all parameters thoroughly. The description adds some semantics by mentioning 'photo ID and selfie' (relating to document_type) and 'base64-encoded files' (relating to file_base64), but this mostly reinforces schema details rather than providing significant additional meaning.

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 specific action ('upload a verification document'), the target resource ('for a medication order'), and the document types ('photo ID and selfie'), distinguishing it from sibling tools like order_documents (which likely lists documents) and order_create (which creates orders).

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

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

The description provides clear context for when to use this tool ('upload a verification document for a medication order'), but does not explicitly state when not to use it or name alternatives among sibling tools (e.g., order_documents might be for viewing documents).

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

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

Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds value by specifying the authentication requirement ('Requires authentication'), which isn't covered by annotations, and lists the specific data components returned, giving context about what information is included in the care plan.

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 front-loaded with the core purpose, followed by a bullet-like list of included components and an authentication note. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.

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

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

Given the tool's complexity (read-only with authentication), annotations cover safety, schema covers parameters, and an output schema exists (per context signals), the description is complete enough. It provides purpose, data scope, and authentication context without needing to explain return values or low-level details.

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

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

Schema description coverage is 100%, with clear parameter documentation. The description doesn't add any parameter-specific details beyond what the schema provides, such as format or constraints for patient_id. Baseline 3 is appropriate since the schema handles parameter documentation adequately.

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

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

The description clearly states the action ('Get') and resource ('patient's current care plan'), and lists specific components included (medication, dosage, schedule, dates, notes, summary). It distinguishes this from sibling tools like 'medications_list' or 'portal_log_weight' by focusing on the comprehensive care plan rather than specific aspects.

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

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

The description implies usage for retrieving a patient's care plan but doesn't explicitly state when to use this tool versus alternatives like 'medications_details' or 'portal_message'. It mentions 'Requires authentication', which provides some context, but lacks guidance on prerequisites or exclusions.

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

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

The description adds valuable behavioral context beyond annotations: it explains that 'severe' severity triggers auto-flagging for immediate provider review and returns urgent guidance, and explicitly states authentication requirements. While annotations already indicate destructiveHint=true (mutation), the description provides specific behavioral consequences of the 'severe' parameter value.

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

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

The description is perfectly concise with three sentences that each serve distinct purposes: stating the core function, explaining a critical behavioral consequence, and noting authentication requirements. No wasted words, and the most important information (the severe-case handling) appears early.

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 annotations (covering mutation safety), 100% schema coverage, and an output schema (so return values are documented elsewhere), the description provides excellent contextual completeness. It adds the crucial behavioral nuance about severe cases and authentication that wouldn't be captured in structured fields alone.

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

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

With 100% schema description coverage, the schema already documents all parameters thoroughly. The description doesn't add significant semantic information about parameters beyond what's in the schema, though it does imply the importance of the 'severity' parameter through its behavioral disclosure about 'severe' values.

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

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

The description clearly states the specific action ('Log side effects a patient is experiencing') and identifies the resource (patient side effects). It distinguishes from siblings like portal_log_weight (different logging type) and portal_message (communication vs. medical logging).

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

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

The description provides clear context for when to use this tool (when a patient is experiencing side effects that need logging). It doesn't explicitly state when NOT to use it or name specific alternatives, though the sibling list shows related tools like portal_message for communication or provider_questions for inquiries.

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

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

The description adds valuable context beyond annotations by explicitly stating 'Requires authentication,' which clarifies the auth need not covered by annotations. Annotations indicate destructiveHint=true and readOnlyHint=false, aligning with the 'Log' action (a write operation), and the description doesn't contradict this. However, it lacks details on rate limits or error handling.

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 front-loaded with the core purpose and efficiently lists requirements in a single sentence, with no wasted words. However, it could be slightly more structured by separating usage notes from parameter info.

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

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

Given the tool's moderate complexity (destructive write operation), the description is mostly complete: it covers purpose, auth needs, and key parameters. With annotations providing safety info and an output schema likely detailing return values, the main gap is lack of usage guidelines, but overall it's adequate for 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?

With 100% schema description coverage, the schema fully documents all parameters (patient_id, weight_lbs, date, bearer_token). The description mentions the required parameters and ISO 8601 format for date, but this adds minimal value beyond the schema, which already specifies these details, meeting the baseline for high coverage.

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

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

The description clearly states the specific action ('Log a patient's weight') and resource ('for tracking progress on their treatment plan'), distinguishing it from sibling tools like portal_log_side_effects by focusing on weight logging rather than side effects or other portal functions.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as whether it's for initial logging versus updates, or how it relates to other portal tools like portal_care_plan. It mentions authentication but not specific contexts or exclusions.

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

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

The description adds valuable behavioral context beyond annotations: it discloses authentication requirements ('Requires authentication'), describes urgent message flagging based on keywords, and specifies return values (confirmation and estimated response time). Annotations indicate destructiveHint=true and non-idempotent, which the description doesn't contradict but complements with practical details.

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 front-loaded with the core purpose, followed by key behavioral details in three concise sentences. Every sentence adds value: the first states the action and return, the second explains urgent handling, and the third notes authentication. There is no wasted text, making it highly efficient.

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

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

Given the presence of an output schema (which covers return values), rich annotations, and full schema coverage, the description is complete. It adds necessary context like authentication and urgent message handling without duplicating structured data, making it well-rounded for this communication tool.

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

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

With 100% schema description coverage, the schema fully documents all three parameters. The description does not add meaning beyond the schema, such as explaining parameter interactions or constraints. It meets the baseline of 3 by not compensating unnecessarily, as the schema already provides complete parameter information.

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

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

The description clearly states the specific action ('Send a message to the patient's healthcare provider') and distinguishes it from sibling tools like portal_log_side_effects or portal_support by focusing on provider communication. It specifies the resource (healthcare provider) and verb (send) with precision.

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

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

The description provides clear context for when to use this tool (sending messages to healthcare providers) and mentions urgent message handling, but it does not explicitly state when not to use it or name alternatives among sibling tools like portal_support or provider_respond. The guidance is helpful but lacks explicit exclusions or comparisons.

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 destructiveHint=true, readOnlyHint=false, and idempotentHint=false, covering safety and idempotency. The description adds value by specifying the review timeframe (24-48 hours) and authentication requirement, which aren't covered by annotations. It doesn't contradict annotations, as 'creates a refill order' aligns with destructiveHint=false (non-read-only) and destructiveHint=true (destructive), but could be clearer on the destructive aspect.

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

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

The description is concise with three sentences that efficiently convey purpose, process, and requirement. It's front-loaded with the main action and avoids unnecessary details. However, it could be slightly more structured by explicitly separating behavioral traits, but overall it's well-sized and clear.

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

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

Given the tool's complexity (a destructive operation with authentication), annotations cover safety and idempotency, and an output schema exists, reducing the need for return value explanation. The description adds key context like review time and auth needs, making it fairly complete. It could improve by mentioning potential errors or side effects, but it's adequate for the context provided.

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

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

Schema description coverage is 100%, with parameters 'patient_id' and 'bearer_token' well-documented in the schema. The description doesn't add any extra meaning about parameters beyond what's in the schema, such as format details or usage examples. Given the high coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to heavily.

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

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

The description clearly states the action ('Request a medication refill') and resource ('for the patient's current prescription'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'order_create' or 'medications_list', which could handle related functions, so it doesn't reach the highest score.

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

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

The description implies usage for medication refills and mentions a 24-48 hour review period, providing some context. However, it doesn't specify when to use this tool versus alternatives like 'order_create' or 'medications_availability', nor does it outline exclusions or prerequisites beyond authentication, leaving room for ambiguity.

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

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

The description adds valuable behavioral context beyond what annotations provide. While annotations indicate this is a destructive, non-idempotent write operation, the description clarifies that it 'Creates a support ticket' (confirming the mutation), specifies the return values ('ticket ID and estimated response time'), and explicitly states 'Requires authentication' - which is crucial operational context not captured in the annotations.

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

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

The description is perfectly concise with three tightly packed sentences that each earn their place: states the purpose, describes the action and return values, and specifies the authentication requirement. It's front-loaded with the core functionality and wastes no 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 that this is a mutation tool with destructiveHint annotation, the description provides excellent contextual completeness. It explains the action (creates support ticket), specifies return values (ticket ID and response time), mentions authentication requirements, and the existence of an output schema means return format details are covered elsewhere. This is complete for a tool of this complexity.

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

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

With 100% schema description coverage, the input schema already fully documents all 4 parameters. The description doesn't add any additional parameter semantics beyond what's in the schema. It mentions the general purpose ('question or issue') but doesn't provide extra guidance about parameter usage, format, or constraints.

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

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

The description clearly states the tool's purpose with specific verbs ('Contact customer support', 'Creates a support ticket') and resources ('support ticket', 'ticket ID', 'estimated response time'). It distinguishes itself from sibling tools like portal_message or portal_care_plan by focusing specifically on formal support ticket creation rather than general messaging or care management.

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

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

The description provides clear context for when to use this tool ('with a question or issue') and mentions the authentication requirement. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools (like portal_message for non-support communication).

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

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

Annotations declare readOnlyHint=true, indicating a safe read operation. The description adds valuable behavioral context beyond annotations: it specifies that it returns questions only if order status is 'needs_info' or a message if none pending, and mentions authentication requirements. This enhances transparency about conditional returns and auth needs, though it lacks details on rate limits or error handling.

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 front-loaded and efficient: three sentences that cover purpose, conditional behavior, and authentication without redundancy. Each sentence adds value, such as clarifying the 'needs_info' status condition, making it appropriately sized and well-structured.

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

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

Given the tool's moderate complexity, annotations (readOnlyHint), and the presence of an output schema, the description is complete enough. It covers purpose, usage context, behavioral conditions, and auth requirements, aligning well with structured fields and not needing to explain return values due to the output schema.

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

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

Schema description coverage is 100%, with both parameters (order_id, bearer_token) well-documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or usage tips. Baseline 3 is appropriate as the schema handles the heavy lifting.

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

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

The description clearly states the verb 'Get' and resource 'follow-up questions from the healthcare provider for a specific order,' distinguishing it from sibling tools like 'intake_questions' (patient intake) and 'provider_respond' (responding to questions). It specifies the context of provider decision-making, making the purpose specific and differentiated.

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

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

The description provides clear context for usage: 'for a specific order' when 'the provider may request additional information before making a prescribing decision.' It implies usage when order status is 'needs_info' but does not explicitly state when not to use it or name alternatives, such as 'order_status' for checking status or 'provider_respond' for responding to questions.

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

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

Annotations already indicate this is a non-read-only, idempotent, destructive operation. The description adds valuable context beyond annotations: it specifies that responses go to the provider for review, returns confirmation and updated order status, and requires authentication. This clarifies the workflow impact and authentication needs, though it doesn't mention rate limits or specific destructive effects.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by outcome and requirements. All three sentences earn their place by adding distinct information (action, outcome, authentication). It could be slightly more concise by combining sentences, but it's efficiently structured with zero waste.

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

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

Given that annotations cover safety traits (destructive, idempotent), schema coverage is 100%, and an output schema exists (so return values are documented elsewhere), the description provides adequate context. It covers the purpose, outcome, and authentication need, leaving detailed parameter and output documentation to structured fields. A minor gap is lack of explicit sibling differentiation.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., format of 'answers' or 'order_id'). Baseline score of 3 is appropriate since the schema carries the full burden of parameter documentation.

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 specific action ('Submit answers'), target resource ('provider follow-up questions for a specific order'), and outcome ('sent to the provider for review'). It distinguishes this tool from sibling tools like 'provider_questions' (which likely retrieves questions) and 'intake_submit' (which handles patient intake).

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

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

The description implies usage context ('for a specific order' and 'follow-up questions'), but doesn't explicitly state when to use this tool versus alternatives like 'intake_submit' or 'consent_submit'. It mentions authentication as a requirement, but no explicit guidance on prerequisites or exclusions is provided.

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