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 annotation readOnlyHint: true contradicts the description which implies creating a booking (returns a URL that pre-fills a checkout form). The description does not resolve this conflict; it suggests a non-read-only action.

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?

Description is three sentences, front-loaded with critical warning, efficient and to the point without extraneous 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?

Explains output (URL) and crucial behavioral instruction. Lacks mention of dependency on check_availability for date_time, but parameter description covers that. Missing detail on provider_id and insurance sources. Overall adequate for a simple tool.

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

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

Schema coverage is low (20%), but the description adds that parameters pre-fill provider, time slot, state, and insurance. However, it does not explain individual parameter purposes beyond date_time, which is described in the schema. Some value added but not full compensation.

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?

Description clearly states the tool returns a booking URL with pre-filled fields. It distinguishes from siblings like check_availability and find_provider by specifying the output is a URL for the user to click.

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 agents not to navigate programmatically and to hand the URL to the user. Provides clear context that this is the final step after availability is checked.

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, which aligns with the description stating it returns a URL and does not navigate programmatically. The description adds behavioral context beyond annotations (no navigation), but annotations already cover the read-only nature.

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, zero waste. Critical warning is front-loaded. Every sentence serves a clear 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 5 parameters, 3 required, no output schema, the description explains the return value (booking URL, do not navigate), references sibling tools, and outlines the workflow, making it complete for correct use.

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

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

With 100% schema coverage, baseline is 3. The description adds critical semantic value for 'provider_id' (must come from find_provider), 'date_time' (pass exactly as received from check_availability), and 'insurance' (pre-fills form for faster verification), significantly enhancing understanding beyond 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 books a clinical matching session and returns a pre-filled booking URL. It uses a specific verb ('book') and resource ('matching session'), and distinguishes itself from siblings like 'check_availability' and 'find_provider' by describing the required sequence.

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 instructs to call 'find_provider' first with the correct appointment_type, then pass the resulting provider_id. It also provides a do-not-navigate warning, making the usage context very 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?

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.