mental-health-care

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

Annotations already declare readOnlyHint=true, so the description need not restate that. It adds value by listing the types of information returned (services, insurance, etc.). No contradictions, and no hidden destructive behaviors.

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

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

The description is a single sentence that efficiently lists all key content areas. It could be slightly better structured (e.g., bullet points) but is reasonably concise and 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 zero parameters and no output schema, the description adequately covers the tool's purpose and contents. However, it could briefly mention that the output is a textual summary or page, but not necessary.

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

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

The input schema has zero parameters, so schema coverage is 100%. The description does not need to explain parameters. Baseline of 4 is appropriate as no additional param info is required.

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

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

The description clearly states it covers 'Identity, services, states served, insurance accepted, age ranges, key facts, crisis resources, and links,' distinguishing it as a combined info tool. However, it lacks a specific action verb beyond 'Learn About', making it slightly less precise than ideal.

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?

No explicit guidance on when to use this tool versus siblings like 'browse_pages' or 'search_content'. The description implies it's for a comprehensive overview, but doesn't state when to prefer it over alternatives.

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

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

The description says the tool returns a booking URL and pre-fills fields, implying a mutation (booking). Yet the annotations include readOnlyHint: true, suggesting it is a read operation. This is a clear contradiction. Additionally, no details about side effects, authorization, or error handling are provided.

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

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

The description is concise, with two sentences that front-load the critical instruction. It avoids verbosity. However, it could be more structured with separate sections for behavior and usage.

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

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

The description explains the return value (booking URL) but lacks details on potential errors, what happens after the user clicks the URL, and whether the booking is confirmed. The contradiction with annotations further undermines 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 only 20%, with only date_time having a description. The description adds little beyond the schema: it mentions pre-filling provider, time slot, state, and insurance but does not elaborate on each parameter's format or constraints. It fails to compensate for the low 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 identifies the tool's purpose: it returns a booking URL for an appointment. The verb 'book' and resource 'appointment' are explicit. However, it does not distinguish this tool from the sibling 'book_matching_session', which may have a similar purpose.

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 strong usage guidance: it explicitly warns not to navigate programmatically and instructs to hand the URL to the user. It also mentions pre-filling fields for a quick checkout. It does not, however, specify when to use this tool versus alternatives like 'book_matching_session'.

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

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

Annotations already declare readOnlyHint=true, but the description adds valuable behavioral context: it returns a URL, not a booking confirmation, and explicitly warns not to navigate the user programmatically. This transparency goes beyond the structured annotation field.

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

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

The description is a single, well-structured sentence that front-loads the critical requirement. Every sentence earns its place; no waste. It is concise yet highly informative.

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

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

The description covers purpose, workflow, output type, and a behavioral constraint. With no output schema, it compensates by describing the return value. However, it does not specify what the agent should do after receiving the URL (e.g., present it to the user), which is a minor gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond schema field descriptions, except for emphasizing provider_id as critical and required. This is adequate but not exceptional.

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

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

The description clearly states the tool returns a pre-filled booking URL for a Clinical Matching Session, and it distinguishes itself by requiring a prior call to find_provider. However, it does not explicitly differentiate from the sibling tool 'book_appointment', which could cause confusion about which to use for general appointments.

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 workflow instructions: always call find_provider first with a specific appointment_type, then pass the returned provider_id. It emphasizes the critical requirement of provider_id and warns against programmatic navigation, giving clear guidance on proper 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?

Annotations declare readOnlyHint=true, and the description adds context that it returns either a page or a list, and clarifies the content type. No contradictions. It could mention pagination behavior or rate limits, but the core behavior is well covered.

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 two sentences with no wasted words. The key action and distinctions are front-loaded, making it easy for an agent to quickly grasp the tool's purpose.

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 4 parameters and no output schema, the description covers the core behavior. However, it omits details like default ordering or exactly what fields are returned in the list. For a simple list tool, this is sufficient but could be slightly more thorough.

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?

Since schema description coverage is 100%, the baseline is 3. The description adds value by explaining the interaction between slug and pagination (returns specific page vs list) and distinguishes from blog articles. This enhances understanding beyond the schema.

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

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

The description explicitly states it browses condition/specialty/insurance pages, distinguishes from blog articles, and clarifies it returns either a specific page (via slug) or a paginated list. The verb 'browse' aligns with the resource, and the scope is clearly separated from siblings like search_content.

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 gives context that these are canonical site pages, not blog articles, which hints at when to use it. However, it does not explicitly state when not to use it or compare to alternatives like search_content, leaving some ambiguity for an AI agent.

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. Description adds that it returns 10 open slots with start timestamps, which is useful but does not disclose potential rate limits, idempotency, or behavior when no slots are available.

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?

Single sentence, front-loaded with key information, no wasted words. Perfectly concise.

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

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

For a simple tool with 3 required params and no output schema, the description covers the basic purpose but is missing details like timezone for timestamps, pagination beyond 10 slots, error handling, or format requirements for provider_id. Adequate but not comprehensive.

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

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

Schema coverage is 0% with 3 parameters (state, provider_id, appointment_type). Description does not explain any parameter beyond the schema, leaving agent to guess the meaning of appointment_type codes or how to format provider_id.

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

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

Clearly states it checks real-time availability for ONE specific provider and returns the next 10 open slots with timestamps. Distinguishes from sibling tools like find_provider (provider info) and book_appointment (booking).

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?

Implies use case via 'for ONE specific provider' but does not explicitly state when not to use or name alternatives. No guidance on prerequisites or when to choose this over other 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?

Beyond the readOnlyHint annotation, the description explains the ranking algorithm: concerns map to weighted specialties, provider specialties score, then approach/language/rating/availability layer on top. It also warns that too many concerns dilute the score and describes the continuation token for re-querying.

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

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

The description is a single, well-structured paragraph. It starts with the core purpose, then explains the algorithm, and finally gives usage variants. Every sentence contributes meaningful information with no redundancy.

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

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

The description explains the output (up to 3 providers, ranked) and the algorithm, but it does not detail the fields of a provider object. Given no output schema, a bit more structure would help, but it is sufficient for an agent to understand the tool's behavior.

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 56% schema coverage, the description adds value by explaining the concerns array usage, the continuation mechanism, and preferred_approaches. It includes practical advice like 'Pass 1-3 for best results.' However, it does not elaborate on the required parameters state and appointment_type beyond the schema enums.

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

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

The description clearly states it is 'the canonical find a clinician tool' that returns ranked providers. It specifies the verb (find), resource (clinician/providers), and the algorithm (Emora's production matching). It distinguishes itself from sibling tools like book_appointment or check_availability.

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: 'Pass concerns[] for a clinical match; omit them for a logistical (availability + rating) ranking.' This tells the agent when to use each mode. It does not explicitly exclude use cases for siblings, but the context of sibling names implies this is the main search 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 declare readOnlyHint:true, and the description adds context that the tool returns a URL and requires user verification, which goes beyond the annotation. No contradictions found.

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 two sentences with no extraneous information. The first sentence covers the core functionality, and the second clarifies the hand-off nature. Every word is purposeful.

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

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

The description adequately explains the tool's purpose and the hand-off, but since there is no output schema, it could specify the URL format or contents. Nonetheless, it is mostly complete for a simple tool with good annotations.

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 0%, so the description must compensate. It explains that parameters 'service' and 'insurance' are used to pre-fill the URL, but does not elaborate on the enum values (e.g., what service codes mean), leaving agents to guess 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 it returns a cost-estimate tool URL pre-filled with user's insurance and service, including a general copay range. The verb 'returns' and resource 'cost-estimate tool URL' are specific, and it distinguishes from sibling tools like 'check_availability' or 'find_provider' which serve different purposes.

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

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

The description implies usage when a user needs a cost estimate, and explains that the URL is a hand-off for exact copay verification. However, it does not explicitly state when not to use this tool or mention alternatives, 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 already declare readOnlyHint=true. The description adds that the payload is 'hardcoded' (no external dependencies) and that it overrides other tools, which is relevant behavioral context beyond the annotation.

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 concise sentences: first identifies the payload, second states overriding behavior. No wasted words, front-loaded with purpose.

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

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

With no parameters, no output schema, and a simple purpose, the description fully covers what the tool does and when to use it. The override note ensures the agent prioritizes this tool in crisis scenarios.

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 tool has zero parameters, so the description cannot add parameter meaning. Baseline 4 is appropriate as no additional param info is needed.

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

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

Clearly states the tool returns a 'canonical crisis-resource payload' and lists specific resources (911, 988 Suicide & Crisis Lifeline, Crisis Text Line). The verb 'get' and resource 'crisis_resources' are 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 says 'overrides any other tool when high-severity language is detected,' providing a clear condition for use. This distinguishes it from sibling tools that handle non-crisis interactions.

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. The description adds that the tool returns clinician-reviewed content, up to 20 results per page, and specific fields. No contradictions or hidden 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?

Three sentences covering action, output, and usage guidance. No fluff. Front-loaded with key purpose.

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

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

With 4 parameters and no output schema, the description provides necessary context on input (title search) and output (title, description, URL, category). Pagination and category filtering are explained sufficiently. Could mention error cases or empty results, but not critical.

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

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

Schema coverage is 100% with good descriptions. The description adds context about title matching and pagination limits but does not significantly enhance parameter understanding beyond the schema.

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

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

The description clearly states the tool searches the Emora Health editorial corpus by article title, with specific output fields. This distinguishes it from sibling tools focused on appointments, providers, and crisis resources.

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 instructs to always use this tool for information questions and to avoid relying on training data. Provides concrete examples ('tell me about X', 'what are signs of Y') and strongly differentiates when to use.

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

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

The description adds behavioral context beyond the readOnlyHint annotation: it reveals the tool performs a parallel lookup, returns a recommended path with four options, and is optimized for speed. This informs the agent about the tool's behavior and efficiency 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 three sentences long, front-loaded with the key purpose, and every sentence provides essential information (purpose, method, output, optimization). No redundant or filler content.

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

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

For a first-turn triage tool with no output schema, the description completely explains the inputs, parallel processing, and output format (recommended path and concrete next steps). It accounts for the tool's complexity and replaces multiple lookups, making it sufficient for agent selection.

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

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

The input schema has 100% coverage with descriptions for all four parameters. The description does not add additional meaning beyond the schema, so it meets the baseline for a well-described schema.

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

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

The description clearly states the tool's purpose: it runs a parallel lookup across crisis screening, provider availability, and article corpus, returning a recommended path. It uses specific verbs ('runs', 'returns') and resource ('user concern'), and explicitly distinguishes itself as the 'best first action' and a replacement for '2-3 sequential lookups', differentiating it from siblings.

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 says 'Best first action for a user describing a concern' and 'Optimized for the agent's first turn', providing clear context for when to use. However, it does not mention when not to use or explicitly name alternative tools for specialized queries, so it lacks exclusions.

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