Chia Health MCP

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 this: it specifies polling frequency ('every 10-15 seconds'), automatic token upgrade on payment detection, and the unlocking of portal tools. This enhances transparency 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 key actions, uses three concise sentences with zero waste, and efficiently covers purpose, usage, and outcomes. Every sentence contributes 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 (payment status checking with token upgrade), rich annotations (readOnlyHint), and the presence of an output schema, the description is complete. It explains the workflow, prerequisites, and effects, compensating for any gaps without needing to detail return values.

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

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

Schema description coverage is 100%, with the parameter 'bearer_token' fully documented in the schema. The description adds minimal semantics by referencing 'guest token from auth_verify_otp,' which is already in the schema description. Thus, it meets the baseline of 3 without significant 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 tool's purpose with specific verbs ('check if the patient has completed payment' and 'upgrade the token to full scope') and distinguishes it from siblings by focusing on payment status verification and token scope elevation, which is unique among the listed tools.

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

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

The description provides explicit usage guidance: 'Call this after sharing the checkout payment link with the patient' and 'Poll every 10-15 seconds.' It also implies an alternative by referencing 'auth_verify_otp' for token acquisition, though it doesn't explicitly name other payment-related tools like 'checkout_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 indicate destructiveHint=true (implying state change), but the description adds valuable context: it specifies the 5-minute expiration window for codes and clarifies that email is not needed as input. This goes beyond annotations by explaining timing constraints and input dependencies.

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

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

Two sentences with zero waste: the first states purpose and usage conditions, the second specifies prerequisites. Information is front-loaded and every sentence adds essential value without redundancy.

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

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

Given the tool's moderate complexity (single parameter, destructive operation), the description provides complete context: purpose, timing constraints, prerequisites, and differentiation from siblings. With annotations covering safety hints and an output schema presumably handling return values, 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?

Schema description coverage is 100%, so the schema already fully documents the session_id parameter. The description reinforces that session_id comes from auth_start, but adds no new semantic details beyond what the schema provides, 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 action ('Resend the verification code') and target ('to the patient's email'), specifying the exact resource. It distinguishes this tool from siblings like auth_start (initiates) and auth_verify_otp (verifies) by focusing on code resending.

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 ('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'), clearly differentiating it from alternatives that might require email input.

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 an email with a specific subject line, returns a session_id (not a token), and that the session_id is used with 'auth_verify_otp'. Annotations indicate destructiveHint=true (which aligns with 'Start a session' as a state-changing operation), but the description provides practical details about email delivery and the verification workflow.

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. Every sentence adds value: the first explains the action, the second details the verification mechanism, the third clarifies the return value and next steps, the fourth provides email search guidance, and the fifth states authentication and timing. No wasted words.

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

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

Given the complexity (authentication workflow), rich annotations (destructiveHint=true), and the presence of an output schema, the description is complete. It explains the tool's role in the broader authentication process, email specifics, and usage timing without needing to detail return values (handled by 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%, so the schema already documents all parameters (email, phone, first_name, last_name). The description mentions 'contact information' which aligns with the parameters but doesn't add specific meaning beyond what the schema provides. The baseline score of 3 is appropriate when 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 specific action ('Start a patient session'), the resource ('patient'), and the mechanism ('by providing their contact information' and 'Sends a 6-digit verification code'). It distinguishes from sibling tools like 'auth_verify_otp' by explaining this is the first step that returns a session_id, not a token.

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 ('Call this when the patient is ready to proceed with their medical intake — after browsing medications and checking eligibility') and mentions an alternative approach ('If you have access to the patient's email (e.g. Gmail MCP), search for this subject'). It also clarifies prerequisites ('No authentication required').

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 (likely due to token issuance), but the description adds valuable context beyond this: it explains the token's scope ('guest-scope bearer token for intake, consent, order, and checkout tools') and the upgrade path to full scope via auth_check_payment. However, it doesn't mention rate limits or error behaviors, leaving some gaps.

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: the first states the purpose and outcome, the second specifies prerequisites, and the third outlines the next step. Each sentence adds critical information with zero waste, making it 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 (authentication flow), rich annotations (destructiveHint=true), and the presence of an output schema (implied by 'Returns a guest-scope bearer token'), the description is complete. It covers purpose, prerequisites, token scope, and next steps, leaving no significant gaps for the agent.

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 both parameters (code as '6-digit verification code from the email' and session_id as 'Session ID from auth_start'). The description adds no additional parameter semantics beyond what's in the schema, 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 ('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 mentions the outcome: 'Returns a guest-scope bearer token for intake, consent, order, and checkout tools.'

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

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

The description provides explicit guidance on when to use this tool: after auth_start ('Requires the session_id from auth_start') and before other tools that need the token. It also specifies when not to use it ('no email needed') and names an alternative for post-payment scenarios ('call auth_check_payment to upgrade the token').

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 that the tool 'Releases any held inventory and cancels the associated Stripe PaymentIntent if not yet captured,' which clarifies side effects not covered by annotations (destructiveHint=true only indicates mutation). It also states 'Requires authentication,' though this is partially covered by the bearer_token parameter in the schema. 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 in the first sentence, followed by specific behavioral details and authentication requirement. 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 (destructive operation with side effects), the description is complete enough: it explains the action, behavioral consequences (inventory release, Stripe cancellation), and authentication need. With annotations covering safety hints (destructive, idempotent) and an output schema present, the description does not need to detail return values or repeat structured data, providing sufficient context 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?

The schema description coverage is 100%, so the schema already documents both parameters (checkout_id and bearer_token). The description does not add meaning beyond what the schema provides, such as explaining parameter interactions or usage nuances. Baseline 3 is appropriate as 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 specific action ('Cancel an in-progress checkout session') and resource ('checkout session'), distinguishing it from sibling tools like checkout_create, checkout_complete, and checkout_status by focusing on cancellation rather than creation, completion, 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'), but does not explicitly mention when not to use it or name specific alternatives. It implies usage for active checkouts that need cancellation, though lacks explicit exclusions or comparisons to siblings like checkout_update.

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 the authentication requirement ('Requires authentication'), which annotations don't cover. Annotations already indicate it's destructive (destructiveHint: true) and idempotent (idempotentHint: true), but the description doesn't contradict these. However, it doesn't mention rate limits, error handling, or side effects beyond payment completion.

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 purpose, second provides usage conditions and alternatives, third notes authentication. Every sentence adds critical information with zero waste, 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 complexity (payment completion with specific protocol requirements), the description is complete: it covers purpose, usage guidelines, authentication needs, and alternatives. With annotations covering safety/idempotency and an output schema presumably detailing the result, no essential context is missing for agent decision-making.

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 any parameter-specific details beyond what's in the schema (e.g., it doesn't explain SPT format or checkout_id sourcing). Baseline 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 specific action ('Complete payment') using a specific technology ('Stripe ACP with Shared Payment Token'), distinguishing it from sibling tools like checkout_create (which creates) and checkout_status (which checks status). It explicitly mentions the resource ('payment') and method ('using Stripe ACP'), 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 when-to-use guidance ('Only use this if your platform supports Stripe Agentic Commerce Protocol and can provision an SPT') and clear alternatives ('If your platform does NOT support ACP, use the payment_url from checkout_create instead, then poll checkout_status'). It also mentions prerequisites ('Requires authentication'), making usage context comprehensive.

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

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

Annotations indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=true, covering safety and idempotency. The description adds valuable context beyond annotations: it explains the two payment paths (Stripe ACP vs. payment link), mentions authentication requirement (though partially covered by bearer_token parameter), and hints at workflow dependencies (calling checkout_complete or checkout_status after). It does not contradict annotations, as 'Initiate' aligns with non-readOnly and destructive hints, and idempotency is consistent with session creation.

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: the first sentence states the purpose and output, followed by clear bullet points for payment paths, and ends with authentication requirement. Every sentence adds value—no redundancy or fluff—making it efficient and easy to parse 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 (payment workflows, authentication), rich annotations (idempotent, destructive), and the presence of an output schema (implied by 'Returns checkout details'), the description is complete. It covers purpose, usage guidelines, behavioral context, and workflow integration without needing to detail return values or repeat schema information, 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 order_id and bearer_token fully documented in the schema. The description does not add specific details about parameter usage beyond implying order_id is needed for checkout creation and mentioning authentication context. Since the schema carries the burden, the baseline score of 3 is appropriate, as the description provides no extra parameter semantics.

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'), target resource ('for a medication order'), and output ('Returns checkout details including line items, total, and payment options'). It distinguishes 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?

The description provides explicit guidance on when to use this tool ('Initiate a checkout session') and when to use alternatives, detailing two payment paths: 'Stripe ACP (preferred)' with checkout_complete for instant payment, and 'Payment link (fallback)' with checkout_status to poll for completion. It also specifies prerequisites ('Requires authentication') and distinguishes from non-checkout siblings like order_create 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?

The annotations declare readOnlyHint=true, which the description aligns with by describing a status-checking operation. The description adds valuable behavioral context beyond annotations: it explains that the tool 'triggers order fulfillment' upon payment detection, discloses authentication requirements ('Requires authentication'), and specifies polling behavior ('Poll every 5-10 seconds'). However, 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 usage context, behavioral details, and authentication note. Every sentence adds value: the first states the action, the second provides usage timing and sibling reference, the third explains side effects and polling, and the fourth notes authentication. There's no wasted text, and it's structured logically for an 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 (polling-based status check with side effects), the description is complete: it covers purpose, usage guidelines, behavioral traits (fulfillment triggering, polling, auth), and context. With annotations covering read-only safety and an output schema presumably handling return values, no critical gaps remain. It effectively compensates for what structured fields don't convey.

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 (checkout_id and bearer_token) thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining the relationship between checkout_id and payment_url from checkout_create. With high schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the specific action ('Check the payment status of a checkout session') and distinguishes it from siblings like checkout_create (which creates sessions) and checkout_complete (which might finalize them). It explicitly identifies the resource (checkout session) and verb (check status), 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 ('to poll for completion after sending the patient a payment link from checkout_create') and how to use it ('Poll every 5-10 seconds while waiting'). It also distinguishes it from alternatives by referencing checkout_create for the initial step, though it doesn't explicitly exclude other siblings like checkout_update or checkout_cancel.

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: it specifies the authentication requirement ('Requires authentication'), which isn't covered by the annotations. The annotations already indicate this is a destructive, non-readonly, idempotent operation, and the description doesn't contradict these. However, 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 perfectly concise: two sentences that front-load the core purpose and follow with essential constraints. Every word serves a purpose with no redundancy or fluff.

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

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

Given the tool's complexity (mutation with authentication), rich annotations, and existence of an output schema, the description is mostly complete. It covers purpose, constraints, and authentication needs. The main gap is lack of explicit guidance about when NOT to use it versus sibling 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 schema already documents all parameters thoroughly. The description mentions the types of updates possible ('shipping method, promo codes, or customer details'), which aligns with but doesn't significantly expand upon the schema's 'updates' description. 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 action ('Update'), target resource ('existing checkout session'), and specific modifications possible ('modify shipping method, apply promo codes, or update customer details'). It distinguishes from sibling tools like checkout_create (creation) and checkout_complete (finalization).

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 ('before payment is completed'), which implicitly distinguishes it from checkout_complete (after payment). However, it doesn't explicitly state when NOT to use it or mention alternatives like checkout_cancel for abandoning sessions.

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 the readOnlyHint annotation. It specifies that the tool 'Returns consent IDs, titles, summaries, and order of presentation' and lists the required consent types (telehealth, compounded medication, etc.). It also states 'Requires authentication,' which is useful context not covered by annotations. No contradictions with annotations.

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

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

The description is front-loaded with the core purpose, followed by return details, required consent types, workflow instructions, and authentication requirement. Every sentence adds essential information with zero waste, 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 moderate complexity, rich annotations (readOnlyHint), and the presence of an output schema, the description is complete. It covers purpose, usage context, return format, required consents, workflow integration, and authentication needs, providing all necessary context for an AI agent to use it effectively.

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

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

With 100% schema description coverage, the input schema already fully documents both parameters (intake_id and bearer_token). The description does not add any parameter-specific details beyond what the schema provides, so it meets the baseline expectation 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 tool's purpose: 'Get the list of all consent documents a patient must accept before ordering medication.' It specifies the verb ('Get'), resource ('consent documents'), and context ('before ordering medication'), distinguishing it from siblings like consent_text (fetch individual consent) and consent_submit (submit 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 explicitly states when to use this tool: 'before ordering medication' and provides clear alternatives: 'Each consent must be fetched individually via consent_text and confirmed by the patient before proceeding.' This gives specific guidance on the workflow and when to switch to sibling tools.

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

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

Annotations declare readOnlyHint=true, which the description aligns with by describing a check/status operation. The description adds valuable behavioral context beyond annotations: it explains this is a 'gate' that affects order_create (implying workflow dependencies), mentions authentication requirements (though partly covered in input schema), and clarifies the consequence of incomplete consents. No contradiction with annotations.

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

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

The description is efficiently structured in three sentences: first states the core purpose, second explains the return value and impact on ordering, third notes authentication. Every sentence adds critical information with zero waste, making it easy to parse and front-loaded with key details.

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

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

Given the tool's moderate complexity (checking consent status), rich annotations (readOnlyHint), high schema coverage, and presence of an output schema (which handles return values), the description is complete. It covers purpose, usage context, behavioral implications, and prerequisites, leaving no significant gaps for the agent to understand and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (intake_id and bearer_token). The description does not add specific meaning or usage details for parameters beyond what the schema provides, such as explaining how intake_id is obtained or bearer_token usage. 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 specific action ('Check whether all required consents are complete') and resource ('for a patient intake'), distinguishing it from sibling tools like consent_list (which lists consents) or consent_submit (which submits consents). It explicitly defines what the tool does beyond just reading data.

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

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

The description provides explicit guidance on when to use this tool: as a 'gate' before order_create, which will reject if consents are incomplete. It also mentions an alternative (order_create) and includes a prerequisite ('Requires authentication'), giving clear context for 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 description adds valuable behavioral context beyond annotations: it specifies retention period ('All consent records are retained for 10 years per HIPAA requirements'), mentions authentication requirements ('Requires authentication'), and describes audit trail purposes. While annotations cover idempotency and destructive nature, the description provides important regulatory and operational context that helps the agent understand implications.

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

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

Extremely well-structured and front-loaded: the first sentence states the core purpose, followed by prerequisites, required parameters, return values, and important constraints. Every sentence adds essential information with zero waste. The description is comprehensive yet efficiently organized.

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

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

Given the complexity of a consent submission tool with HIPAA implications, the description provides excellent context: it explains prerequisites, parameter purposes, return values, retention policies, and authentication requirements. With both annotations and an output schema present, the description focuses on the operational context rather than repeating structured data, making it complete for agent decision-making.

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 is 3. The description adds some semantic context by explaining the purpose of certain parameters (e.g., 'session/conversation ID for audit trail'), but doesn't provide significant additional meaning beyond what's already well-documented in the schema descriptions. The parameter explanations in the description mostly restate schema 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 ('Record a patient's consent confirmation'), identifies the resource ('for a specific consent document'), and distinguishes from sibling tools like consent_text (which provides the text) and consent_list/consent_status (which list or check status). The verb+resource combination is precise and 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?

Explicitly states when to use: 'The agent must have already presented the full consent text (from consent_text) to the patient and received explicit confirmation.' This provides clear prerequisites and references the sibling tool consent_text as a required precursor, giving complete guidance on proper usage context.

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

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

The annotations declare readOnlyHint=true, which the description aligns with by describing a fetch operation. The description adds valuable behavioral context beyond annotations: it specifies that the output must be presented verbatim, lists the content structure included, enumerates available consent types, and mentions authentication requirements. 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 with zero wasted sentences. It front-loads the core purpose, then details output format, content, available types, usage constraints, and authentication requirement—each sentence adds essential information for tool selection and invocation.

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 (retrieving structured consent documents), the description provides complete context: it explains the output format, lists content components, specifies available consent types, outlines presentation requirements, and mentions authentication. With annotations covering safety and an output schema presumably detailing the return structure, 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?

Schema description coverage is 100%, providing full documentation for both parameters. The description doesn't add parameter-specific details beyond what's in the schema, but it contextually implies that consent_id should come from consent_list. With high schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the specific action ('Fetch the full text'), resource ('consent document'), and scope ('for patient review'). It distinguishes from sibling tools like consent_list (which lists consents) and consent_submit (which submits consent confirmations) by specifying this tool retrieves the actual document content for presentation.

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 ('before the agent can call consent_submit') and when not to use it (do not use for summarization or paraphrasing). It also specifies the required prerequisite ('Requires authentication') and ties usage to the patient review 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 operations, which the description aligns with by describing a check/assessment function. The description adds valuable behavioral context beyond annotations: it specifies the return format (eligibility status, medication list, disqualifying reasons) and details the specific business logic rules (age 18+, state restrictions, BMI 20+, pregnancy exclusions, condition disqualifiers).

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 two sentences: the first states purpose and criteria, the second specifies return values. Every element serves a clear purpose with zero wasted words, and key information is front-loaded.

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

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

Given the tool's complexity (7 parameters with business logic), rich annotations (readOnlyHint, openWorldHint), and existence of an output schema, the description provides excellent contextual completeness. It explains the business rules, specifies what gets returned, and works effectively with the structured data rather than duplicating it.

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 7 parameters thoroughly. The description adds some semantic context by explaining how parameters relate to eligibility criteria (e.g., age must be 18+, state must be where providers are licensed), but doesn't provide significant additional parameter meaning beyond what the schema descriptions already state.

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 ('Pre-screen a patient's basic eligibility') and resource ('telehealth prescription services'), with detailed criteria listed. It distinguishes this tool from siblings by focusing on eligibility assessment rather than authentication, checkout, medication lookup, or other 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 implies usage context ('Pre-screen a patient's basic eligibility') but doesn't explicitly state when to use this vs alternatives like 'medications_availability' or 'provider_questions'. It provides clear criteria for eligibility but no explicit guidance on tool selection among siblings.

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

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

Annotations indicate read-only and open-world hints, which the description aligns with by describing a retrieval operation. It adds valuable context beyond annotations: the server returns deduped sections, includes two phases (pre_checkout and post_checkout), and notes that a licensed US healthcare provider makes prescribing decisions. However, it doesn't detail rate limits or error handling, which are partially covered by the 'client_ip' parameter description.

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 medication awareness, parameter usage, and phases. It's appropriately sized for the complexity, but could be slightly more concise by integrating some details (e.g., the provider note) more tightly. Every sentence adds value, with no redundant information.

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

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

Given the tool's complexity (product-aware questionnaire with multiple phases), rich annotations (readOnlyHint, openWorldHint), 100% schema coverage, and presence of an output schema, the description is complete. It covers purpose, usage, parameter semantics, behavioral context (deduping, phases, provider role), and aligns well with structured data, leaving no significant gaps 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 baseline is 3. The description adds meaningful semantics: it explains that 'medication' determines question sets (e.g., GLP-1 vs. NAD+), clarifies 'additional_medications' is for ordering multiple products to deduplicate questions, and implies 'client_ip' is for rate limiting (though this is also in the schema). This enhances understanding beyond the schema's technical definitions.

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

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

The description clearly states the tool retrieves a medical intake questionnaire for patients before provider evaluation, specifying it's product-aware with examples (GLP-1/weight-loss vs. NAD+/longevity peptides). It distinguishes from siblings like 'intake_submit' or 'provider_questions' by focusing on questionnaire retrieval rather than submission or provider interaction.

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?

Explicit guidance is provided: use this tool to get the questionnaire before provider evaluation, pass 'additional_medications' for multiple medications to deduplicate questions, and note that both pre_checkout and post_checkout phases must be completed. It implicitly contrasts with tools like 'intake_submit' (for submitting answers) or 'eligibility_check' (for other checks).

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

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

Annotations already declare readOnlyHint=true, so the agent knows it's a safe read operation. The description adds valuable context beyond annotations: it discloses authentication requirements ('Requires authentication') and clarifies that it returns specific statuses from a healthcare provider. It doesn't mention rate limits or error behaviors, but adds meaningful operational context.

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, usage context, and authentication requirement. Every sentence adds value with no redundancy or fluff. 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 moderate complexity (read-only status check), rich annotations (readOnlyHint), 100% schema coverage, and the presence of an output schema (which handles return value documentation), the description is complete. It covers purpose, usage timing, authentication, and distinguishes from related tools adequately.

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 (intake_id and bearer_token). The description doesn't add any parameter-specific details beyond what's in the schema. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.

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 verb ('Check') and resource ('status of a previously submitted intake questionnaire'), and distinguishes it from siblings like 'intake_submit' (which submits) and 'order_status' (which checks order status). It explicitly mentions the three possible return states (under review, approved, denied).

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: 'to poll for provider review completion before proceeding to order placement.' It distinguishes from order placement tools and implies timing (after submission, before ordering). No explicit exclusions, but the context is clear.

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

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

The description adds valuable behavioral context beyond annotations: it discloses that 'The intake is reviewed by a licensed US healthcare provider who makes all prescribing decisions,' which is not covered by annotations. Annotations indicate destructiveHint=true (mutation) and readOnlyHint=false, which align with the description's 'Submit' action. However, it doesn't mention rate limits or error handling, 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 front-loaded with the core purpose in the first sentence, followed by prerequisites, returns, and context in subsequent sentences. Each sentence adds value without redundancy, making it efficient and well-structured for an AI 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 (destructive mutation with authentication), the description is complete: it covers purpose, prerequisites, returns, and provider context. With annotations covering safety aspects and an output schema likely detailing the return values, no additional information is needed for effective tool selection and invocation.

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 thoroughly. The description adds minimal parameter semantics by referencing 'intake_answers' from 'intake_questions,' but doesn't provide additional syntax or format details beyond what the schema specifies. 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 verb ('Submit') and resource ('completed medical intake questionnaire'), and distinguishes it from sibling tools like 'intake_questions' (which likely retrieves questions) and 'intake_status' (which likely checks status). It specifies the outcome ('for provider review') and what it returns ('intake ID and estimated provider review time').

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 guidelines: it states when to use ('All fields from intake_questions must be completed'), implying this tool should be used after completing the intake_questions tool. It also specifies prerequisites ('Requires authentication') and distinguishes from alternatives by focusing on submission rather than retrieval or status checking among sibling tools.

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

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

Annotations indicate readOnlyHint=true and openWorldHint=true, which the description does not contradict. The description adds valuable behavioral context beyond annotations by explaining that some medications have state-specific restrictions based on pharmacy licensing and that it returns availability status with reasons if unavailable, which helps the agent understand the tool's logic and output.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by additional context and output details in subsequent sentences. 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, rich annotations, and the presence of an output schema, the description is complete enough. It covers the purpose, key constraints (state-specific restrictions), and output behavior, which, combined with structured data, provides sufficient context for effective 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%, so the schema already documents all parameters well. The description does not add significant meaning beyond the schema, as it only implies the use of 'medication' and 'state' parameters without detailing their semantics further. The baseline score of 3 is appropriate given the 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 ('check if available for shipping') and resource ('specific medication'), distinguishing it from sibling tools like medications_list or medications_details by focusing on state-specific availability rather than general listing or detailed information.

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 does not explicitly mention when not to use it or name alternative tools for related tasks.

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 safe read operations with potentially dynamic data. The description adds valuable context beyond annotations by specifying what information is included in each category (description and count of available medications), which helps the agent understand the return structure. 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 in two sentences: the first states the purpose with concrete examples, and the second specifies the return format. Every element serves a clear purpose with zero wasted words, making it 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 simple read-only nature, rich annotations (readOnlyHint, openWorldHint), 100% schema coverage, and existence of an output schema, the description provides complete contextual information. It clearly explains what the tool returns (categories with descriptions and medication counts), which complements the structured data effectively.

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

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

Schema description coverage is 100% with one parameter (client_ip) fully documented in the schema. The description doesn't mention any parameters, which is acceptable given the high schema coverage. However, it doesn't add any parameter-specific context beyond what the schema provides.

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

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

The description clearly states the verb ('List') and resource ('all medication categories available through the telehealth platform'), and distinguishes this from sibling tools like medications_list and medications_details by focusing specifically on categories rather than individual medications. It provides concrete examples of categories to illustrate scope.

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

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

The description implies usage context by mentioning 'telehealth platform' and listing categories, but doesn't explicitly state when to use this tool versus alternatives like medications_list or medications_details. No guidance on prerequisites or exclusions is provided, leaving usage context somewhat implicit.

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 the annotations. While annotations indicate read-only and open-world operations, the description specifies the comprehensive scope of information returned (dosage strengths, forms, pricing, contraindications, side effects) and the query flexibility (by name or category). It doesn't mention rate limits or authentication requirements, but the annotations already cover the safety profile adequately.

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. The first sentence establishes what the tool does, followed by specific details and usage guidance. While comprehensive, every sentence adds value and there's no redundant information. It could be slightly more concise but remains 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 and the presence of both comprehensive annotations (readOnlyHint, openWorldHint) and an output schema, the description provides excellent contextual completeness. It clearly explains what information will be returned, how to query it, and when to use it. The output schema will handle return value documentation, so the description focuses appropriately on purpose and usage.

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

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

With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description adds marginal value by providing examples of medication names and categories, but doesn't explain parameter interactions or constraints beyond what's in the schema. The baseline score of 3 is appropriate when 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 tool's purpose with specific details: 'Get detailed information about a specific medication' followed by an exhaustive list of what information is included (dosage strengths, forms, pricing, contraindications, side effects). It distinguishes itself from sibling tools like medications_list, medications_categories, and medications_pricing by providing comprehensive details rather than lists or limited pricing info.

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' and provides clear query methods ('Supports queries by medication name or by category'). It implicitly distinguishes from siblings by focusing on detailed information rather than availability checks or basic lists, though it doesn't explicitly name 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 are compounded by US-licensed pharmacies and require provider evaluation, 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, starting with the core purpose and then adding details about medication types, return fields, and contextual notes. It avoids redundancy, though it could be slightly more concise by integrating some details more tightly.

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 (listing medications with multiple attributes), rich annotations (readOnlyHint, openWorldHint), and the presence of an output schema, the description is complete. It covers purpose, scope, return fields, and important contextual constraints (compounding, provider evaluation), making it sufficient for agent understanding without needing to explain return values.

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

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

Schema description coverage is 100% with one parameter (client_ip) fully documented in the schema. The description does not mention or explain this parameter, but since the schema already covers it completely, the baseline score of 3 is appropriate as no additional parameter semantics are 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 'List' and resource 'prescription medications' with specific examples like GLP-1 weight loss drugs and peptide therapies. It distinguishes from sibling tools like medications_details (details) and medications_pricing (pricing) by focusing on comprehensive listing with categories, forms, and 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 implies usage for retrieving a broad list of medications with categories and pricing, but does not explicitly state when to use this tool versus alternatives like medications_categories or medications_availability. It provides context about compounded medications and provider evaluation, but lacks explicit when-not or alternative guidance.

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

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

The description adds valuable behavioral context beyond what annotations provide. While annotations indicate read-only and open-world operations, the description discloses that it returns a 'detailed pricing' breakdown with specific components (medication cost, provider consultation fee, shipping, discounts), mentions plan duration variability by medication, and notes that it supports a list of specific medications plus 'all other available medications.' 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: the first sentence states the core purpose and return value, the second provides critical usage guidance, and the third specifies scope. Every sentence earns its place with no wasted words, making it efficient for an AI agent 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 (pricing calculation with multiple components), rich annotations (readOnlyHint, openWorldHint), 100% schema coverage, and the presence of an output schema, the description is complete enough. It covers purpose, usage guidelines, behavioral context, and scope without needing to explain return values (handled by output schema) or repeat schema 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?

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description adds minimal parameter semantics beyond the schema—it mentions that 'plan durations vary by medication' and references medications_details for plan_months values, but doesn't provide additional syntax or format details. 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_details (which provides plan_months values) and medications_list (which lists medications). It explicitly mentions the return content ('price breakdown including medication cost, provider consultation fee, shipping, and any applicable discounts').

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. It also specifies the scope of medications supported ('Supports semaglutide, tirzepatide, sermorelin, NAD+, glutathione and all other available medications'), helping differentiate from other medication-related tools.

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

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

Annotations already indicate this is a destructive, non-idempotent write operation. The description adds valuable context beyond annotations: payment processing via Stripe ACP, authentication requirement, review process by healthcare provider, compounding at a 503A pharmacy, and shipping details. No contradiction with annotations.

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

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

Well-structured with clear sentences that each add value: purpose, prerequisites, required parameters, review process, fulfillment details, return values, and authentication. Could be slightly more concise but efficiently covers 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 this is a complex, destructive operation with rich annotations and an output schema, the description provides excellent context: prerequisites, workflow details (review, compounding, shipping), payment method, authentication requirement, and return values. Complete enough for an agent to understand the tool's role and implications.

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 thoroughly. The description mentions medication name, form, plan duration, and shipping address but doesn't add significant semantic value beyond what's 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 creates a new prescription medication order, specifying the resource (prescription medication order) and action (create). It distinguishes from siblings like order_status or order_documents by focusing on creation rather than status checking or document retrieval.

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 prerequisites (patient must have completed intake questionnaire and consent before ordering) and provides clear context about the review process by a licensed US healthcare provider. It also distinguishes from sibling tools by specifying this is for order creation rather than status checking or document management.

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 behavioral context beyond this: it specifies that authentication is required (though this is also implied by the bearer_token parameter), describes what information is returned (upload status, accepted file formats), and gives examples of document types (photo ID, selfie). This goes beyond the basic read-only annotation to provide practical implementation 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 perfectly front-loaded with the core purpose in the first clause, followed by return details and authentication requirement. Every sentence earns its place with no wasted words, making it highly efficient while remaining comprehensive.

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) and an output schema, the description provides exactly what's needed: it explains the tool's purpose, what information it returns, and authentication requirements. The output schema will handle return value details, so the description appropriately focuses on contextual understanding rather than technical specifications.

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-specific information beyond what's in the schema descriptions. The baseline score of 3 is appropriate when the schema carries the full 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 specific action ('Get the list of documents'), target resource ('a patient needs to upload for their order'), and scope ('required documents with upload status and accepted file formats'). It distinguishes from sibling tools like 'order_status' or 'order_upload' by focusing specifically on document requirements rather than general order status or file upload functionality.

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 their order') and mentions authentication requirements. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools, such as when to use 'order_status' instead for general order information.

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, which the description aligns with by describing a read operation. The description adds valuable context beyond annotations: it specifies authentication requirements and details the return data (status, tracking, delivery estimate), enhancing behavioral understanding 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 front-loaded with the core purpose, followed by return details and authentication note in two efficient sentences. Every sentence adds value without redundancy, 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, rich annotations (readOnlyHint), 100% schema coverage, and the presence of an output schema (implied by return details), the description is complete enough. It covers purpose, return values, and authentication, leaving no significant gaps for the agent.

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 both parameters. The description does not add meaning beyond the schema, such as explaining parameter interactions or usage nuances, 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 specific action ('Get the current status') and resource ('medication order'), and distinguishes it from siblings like 'order_create' or 'order_documents' by focusing on status retrieval rather than creation or document handling.

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 (to check order status) and mentions authentication requirements, but does not explicitly state when not to use it or name alternatives like 'checkout_status' for non-medication orders, leaving some 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?

Annotations provide readOnlyHint=false, idempotentHint=true, and destructiveHint=true, indicating a non-read-only, idempotent, destructive operation. The description adds valuable context beyond annotations: it specifies authentication requirements ('Requires authentication'), file format constraints ('Supported formats: PDF, JPEG, PNG'), and size limits ('Maximum size: 10MB'), which are not covered by annotations. 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 in the first sentence, followed by essential details in a logical flow: file requirements, formats, size limits, and authentication. Every sentence adds value without redundancy, making it highly efficient and well-structured for quick comprehension.

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

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

Given the tool's complexity (upload with authentication and file constraints), the description provides complete context: it covers purpose, file handling, and authentication. With annotations detailing safety traits (destructive, idempotent) and an output schema present (which handles return values), no additional information is needed for the agent to use the tool effectively.

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

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

Schema description coverage is 100%, meaning all parameters are documented in the schema. The description adds minimal parameter semantics beyond the schema, only mentioning 'photo ID and selfie' as examples for document_type and 'base64-encoded files' for file_base64, which are already implied in the schema. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance 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 specific action ('upload a verification document'), the target resource ('for a medication order'), and distinguishes it from siblings like 'order_documents' (which likely lists documents) and 'order_create' (which creates orders). The verb+resource combination is precise and 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 context ('verification document for a medication order') but doesn't explicitly state when to use this tool versus alternatives like 'order_documents' or other document-related tools. No exclusions or prerequisites are mentioned beyond authentication, leaving some ambiguity about the specific scenarios for invoking this tool.

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 specifies authentication requirements ('Requires authentication') and details the return content (medication, dosage, schedule, etc.). This goes beyond annotations by clarifying data scope and security needs, though it doesn't mention rate limits or error behaviors.

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

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

The description is front-loaded with the core purpose, followed by a detailed list of included data and an authentication note. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.

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

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

Given the tool's complexity (read operation with authentication), rich annotations (readOnlyHint), high schema coverage (100%), and presence of an output schema, the description is complete. It covers purpose, data scope, and authentication, leaving return values to the output schema, which is sufficient 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%, so the schema fully documents parameters (patient_id, bearer_token). The description does not add meaning beyond the schema, such as explaining parameter interactions or format specifics. Baseline 3 is appropriate as the schema carries the 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 verb ('Get') and resource ('patient's current care plan') with specific content details (medication, dosage, schedule, dates, notes, summary). It distinguishes from sibling tools by focusing on care plan retrieval rather than authentication, checkout, consent, intake, medications, orders, portal logging/messaging, or provider interactions.

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 'Requires authentication,' providing clear context for when to use (authenticated patient sessions). However, it does not specify when not to use or name alternatives among siblings (e.g., vs. medications_details or portal_message), leaving some ambiguity in tool selection.

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

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

The description adds valuable behavioral context beyond annotations: it explains that 'severe' severity triggers auto-flagging for provider review and returns urgent guidance, and mentions authentication requirements. Annotations already indicate destructiveHint=true (mutation) and non-idempotent, but the description provides specific workflow consequences not 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 perfectly concise and front-loaded: three sentences with zero waste. The first states the core purpose, the second explains critical behavioral consequences, and the third notes authentication requirements—each sentence earns its place.

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

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

Given the presence of annotations (covering mutation/destructive behavior), 100% schema coverage, and an output schema (which handles return values), the description is complete enough. It adds crucial workflow context (severity-based flagging) and authentication needs that aren't in structured fields.

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 parameters. The description doesn't add any parameter-specific details 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 specific action ('Log side effects a patient is experiencing') and resource ('patient'), distinguishing it from siblings like portal_log_weight or portal_message. It goes beyond just restating the name/title by explaining the core function.

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

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

The description provides clear context for when to use this tool (when logging patient side effects) and mentions authentication requirements. However, it doesn't explicitly state when NOT to use it or name alternatives among sibling tools, such as portal_message for general 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 indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false, which the description does not contradict. It adds valuable context by explicitly stating 'Requires authentication' (though bearer_token is in the schema) and clarifying the tool's purpose for tracking progress, enhancing behavioral understanding beyond annotations.

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

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

The description is front-loaded with the core purpose, followed by parameter requirements and authentication note. It uses two concise sentences with zero wasted words, making it easy to scan and understand 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 has annotations (destructive, non-idempotent), a complete input schema, and an output schema (implied by context signals), the description is mostly complete. It covers purpose, parameters, and authentication, but could improve by mentioning the destructive nature or when to use versus siblings for better contextual guidance.

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 mentions patient_id, weight in pounds, and date (ISO 8601), but does not add significant meaning beyond what the schema provides, such as validation rules or usage examples. 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 specific action ('Log a patient's weight'), the resource ('patient'), and the purpose ('for tracking progress on their treatment plan'). It distinguishes itself 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 implies usage in a patient treatment context but does not explicitly state when to use this tool versus alternatives like 'portal_care_plan' or 'portal_message'. It mentions authentication as a requirement but lacks guidance on prerequisites or exclusions, leaving usage context somewhat vague.

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 that urgent messages with specific keywords are flagged for priority response, returns confirmation and estimated response time, and requires authentication. Annotations already indicate destructiveHint=true (mutation) and non-idempotent, but the description enriches this with practical details 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 front-loaded with the core purpose, followed by key behavioral details in a logical flow. Every sentence adds value (outcome, urgency handling, auth requirement) with zero waste, 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 (mutation with authentication and urgency handling), the description provides complete context: purpose, usage, behavioral traits, and output details. With annotations covering safety aspects and an output schema presumably handling return values, 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 fully documents all three parameters. The description does not add any parameter-specific details beyond what the schema provides (e.g., it doesn't explain patient_id format or message length limits), meeting the baseline of 3 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 ('Send a message to the patient's healthcare provider') and resource ('message'), distinguishing it from sibling tools like portal_log_side_effects or portal_support. It provides a complete verb+resource+outcome statement that is 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 clear context for when to use this tool (sending messages to healthcare providers) and mentions authentication requirements. However, it does not explicitly state when NOT to use it or name alternatives among sibling tools (e.g., portal_support might be for non-provider communication), leaving some 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?

Annotations indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false, which the description aligns with by describing a creation action ('Creates a refill order') and authentication needs ('Requires authentication'). It adds valuable context beyond annotations: the review timeline ('reviewed by a provider within 24-48 hours'), which is not covered by 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 front-loaded with the core purpose in the first sentence, followed by additional context in subsequent sentences. Each sentence earns its place by providing essential information (action, outcome, timeline, authentication) without redundancy or unnecessary details, 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 tool's complexity (a destructive operation with authentication), annotations cover safety aspects, and an output schema exists, reducing the need for return value explanation. The description adds key context like the review timeline, but could briefly mention prerequisites (e.g., patient must have an active prescription) for fuller completeness.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (patient_id and bearer_token). The description does not add meaning beyond the schema, such as explaining parameter interactions or usage nuances. Baseline 3 is appropriate as 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 specific action ('Request a medication refill') and the target resource ('for the patient's current prescription'), distinguishing it from sibling tools like 'order_create' or 'medications_list' which handle different operations. It precisely communicates what the tool does without being vague or tautological.

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 requesting medication refills, with an implied alternative being to check 'medications_list' or 'medications_availability' first. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as distinguishing from 'order_create' for new prescriptions.

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 that authentication is required (not covered by annotations), describes the creation of a support ticket, and specifies the return values (ticket ID and estimated response time). While annotations already indicate destructiveHint=true, the description clarifies this means ticket creation rather than data deletion.

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 earn their place: states the purpose, describes the action and return values, and specifies authentication requirement. 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 the tool's moderate complexity, the presence of annotations covering safety aspects, and the existence of an output schema (implied by context signals), the description provides complete context. It covers purpose, behavior, authentication needs, and return values 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?

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 for adequate 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 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 by focusing on support ticket creation rather than authentication, checkout, consent, 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 clear context for when to use this tool ('with a question or issue') and mentions authentication requirements. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools (e.g., 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?

The description adds valuable behavioral context beyond the readOnlyHint annotation: it specifies that authentication is required, describes the return behavior (questions if status is 'needs_info', else a no-questions message), and implies it's for provider-initiated follow-ups. This enhances the agent's understanding of operational nuances.

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 context and behavioral details in three concise sentences. Each sentence earns its place by adding critical 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 moderate complexity, the presence of annotations (readOnlyHint), a detailed input schema, and an output schema (implied by context signals), the description is complete. It covers purpose, usage context, authentication needs, and return behavior, leaving no significant gaps for the agent.

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 both parameters (order_id and bearer_token) adequately. The description does not add further meaning or examples for the parameters, so it meets the baseline for high schema 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 specific action ('Get follow-up questions') and resource ('for a specific order'), distinguishing it from sibling tools like 'intake_questions' or 'provider_respond' by focusing on provider-initiated queries for orders needing information. It precisely defines the tool's scope and function.

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

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

The description provides clear context for when to use this tool: when a provider requests additional information for an order, and it mentions the order status 'needs_info' as a trigger. However, it does not explicitly state when not to use it or name alternatives like 'order_status' for checking status without questions, leaving some guidance implicit.

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 responses are 'sent to the provider for review' (implying an asynchronous workflow) and mentions authentication requirements. Annotations cover idempotency and destructiveness, but the description clarifies the review process and return values ('confirmation and updated order status'), enhancing transparency 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 purpose in the first sentence, followed by additional context in subsequent sentences. Each sentence adds value: submission action, recipient, return values, and authentication requirement. There is no redundant or verbose language, 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 (mutative, with authentication and nested objects), the description is complete. It covers purpose, usage context, behavioral aspects (provider review, returns), and authentication. With annotations providing safety hints and an output schema presumably detailing return values, no critical gaps remain. The description effectively complements the 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 does not add meaning beyond the schema, such as explaining the structure of 'answers' or the format of 'order_id'. It mentions authentication generally but doesn't clarify parameter-specific details, so the baseline score of 3 is appropriate as the schema carries the full 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 specific action ('Submit answers to provider follow-up questions') and resource ('for a specific order'), distinguishing it from sibling tools like 'provider_questions' (which likely retrieves questions) and 'intake_submit' (which handles patient intake). It explicitly mentions the recipient ('sent to the provider for review') and outcome ('updated order status'), 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 clear context for usage: 'for a specific order' and 'answers to provider follow-up questions'. It implicitly suggests this tool is used after questions are received (e.g., from 'provider_questions'), but does not explicitly state when not to use it or name alternatives like 'intake_submit' for patient-side submissions. The authentication requirement is noted, but no further exclusions are specified.

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