mental-health-care

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

Annotations declare readOnlyHint=true, and the description adds context about what information is covered (identity, services, insurance, etc.), which is useful. However, it does not disclose return format, length, or any other behavioral nuances beyond being an informational catalog.

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 with a dense, well-organized list of content categories. Every word earns its place, and the 'Combined site-info + services catalog' phrase adds clarity without padding.

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 no-parameter, read-only informational tool, the description adequately enumerates the coverage areas. It is clear enough for an agent to decide when to use it, and no output schema is needed given the simple nature.

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?

There are zero parameters, so the baseline of 4 applies. The description appropriately does not attempt to add parameter semantics since none exist.

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 lists the resource scope (identity, services, states, insurance, ages, crisis resources, links) and labels it as a combined site-info + services catalog. It lacks an explicit verb like 'get' or 'retrieve', but the title 'Learn About Emora Health' and the content list make the purpose unmistakable.

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 general Emora Health information through its content list, but it does not explicitly state when to use this tool versus sibling tools like get_crisis_resources or search_content. No exclusions or alternative recommendations are provided.

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

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

The description discloses that the tool returns a URL and should not be used for direct navigation, and that it pre-fills provider, time slot, state, and insurance. This complements the readOnlyHint annotation by explaining that the tool is a URL generator, not a state-changing operation.

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, front-loaded with a CRITICAL warning, and every word adds value. Very 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?

The description covers the return value (booking URL) and the critical handling instruction, but it does not mention any error conditions or offer guidance on choosing between this and related tools like book_matching_session. Given no output schema, it is sufficiently complete for an agent to act on.

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 covers only 20% of parameters with descriptions, and the description mentions provider, time slot, state, and insurance as pre-filled fields, but it does not explain appointment_type or provide details on how to obtain provider_id. Some compensation is provided, but not enough for full clarity.

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 booking URL and pre-fills the appointment details, making the purpose unambiguous. However, it does not explicitly distinguish this from sibling tool book_matching_session, so it falls short of a 5.

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 critical instruction 'DO NOT navigate the user programmatically. Hand the URL to the user and let them click through' provides clear usage guidance on how to handle the tool's output, but it does not mention when to use this tool instead of 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?

The description adds meaningful behavioral context beyond the readOnlyHint annotation: it returns a pre-filled URL, must not navigate the user programmatically, and depends on a provider_id from find_provider. This does not contradict readOnlyHint=true because the tool only constructs a URL rather than mutating data.

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 tight sentences with the most critical warning front-loaded. Every clause earns its place and the text is scannable despite the strong emphasis.

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 tool with no output schema, the description adequately states the output (pre-filled URL), the prerequisite call to find_provider, and the key programmatic navigation constraint. It could mention post-return handling more explicitly, but the schema fills most remaining gaps.

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

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

Schema coverage is 100%, so all parameters are already well-documented. The description reinforces the provider_id requirement and its source but does not materially add semantics for state, date_time, insurance, or client_age 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 identifies the specific action: returning a pre-filled booking URL for a Clinical Matching Session using a provider_id obtained from find_provider. It names the resource and output, but does not explicitly differentiate from the sibling book_appointment tool.

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 the prerequisite workflow: call find_provider first with appointment_type='446840' and pass the returned provider_id. It also gives the critical constraint not to navigate the user programmatically, though it does not discuss broader alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds behavioral context: it can return a single page (when slug provided) or a paginated list (when omitted), which is not in the annotations. This clarifies the dual-mode behavior effectively.

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, front-loaded with the tool's core purpose. It conveys purpose, return behavior, and scope distinction without unnecessary detail, earning its place with zero 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?

For a simple read-only browse/list tool, the description covers the essential aspects: purpose, relationship to blog articles, and return modes. Schema covers parameters, annotations cover safety, and no output schema exists. The context is complete for selecting and invoking this 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 description coverage is 100%, with each parameter well-documented in the input schema. The description's mention of 'slug' and 'paginated list' reinforces the schema's existing 'Omit to list all pages' note but adds little new meaning. Therefore, baseline 3 is appropriate.

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

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

The description clearly states the tool browses Emora Health condition/specialty/insurance pages, a specific verb-noun pair. It explicitly differentiates from blog articles via 'canonical site pages, not blog articles', distinguishing it from sibling search_content. The return modes (specific page vs paginated list) further clarify 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 provides clear context by specifying what this tool covers and what it excludes ('not blog articles'), implying use for canonical pages while search_content handles other content. It does not explicitly name sibling alternatives or state when-not-to-use, but the boundary is clear enough for an 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 declare readOnlyHint=true, so safety is covered. The description adds behavioral details beyond annotations by specifying 'real-time' and 'returns the next 10 open slots with start timestamps,' which communicates the output format and limitation. This is richer than a mere read-only flag.

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, tightly written sentence with no filler. It front-loads the core purpose ('Real-time availability') and provides functional details (one provider, next 10 slots, timestamps). Every word 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?

For a simple availability check with 3 self-named parameters and readOnly annotation, the description covers the essential return value (next 10 open slots with start timestamps). It lacks edge-case details (e.g., no slots available, timezone interpretation) but is largely adequate for the tool's straightforward functionality.

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 for parameter meaning, but it does not explain any of the three parameters (state, appointment_type, provider_id). While the parameter names are somewhat self-explanatory, the description adds no semantics about how they are used or what the e.g. appointment_type enum values represent.

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 uses specific language: 'Real-time availability for ONE specific provider' and 'Returns the next 10 open slots with start timestamps.' It clearly differentiates from sibling tools like find_provider (which searches providers) and book_appointment (which books), making the purpose unmistakable.

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 phrase 'for ONE specific provider' strongly implies the user must already have a provider_id, giving clear context on when to use this tool. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full explicit when/when-not 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?

With readOnlyHint=true in annotations, the safety profile is already known. The description adds meaningful behavioral context: ranking mechanism, the role of concerns, approach/language/rating/availability layering, and the hard limit of 3 results. This exceeds the baseline but does not cover all possible 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?

Two sentences pack the essential information without fluff. The first sentence front-loads the purpose; the second details the algorithm and conditional modes. Every clause 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?

The tool has 9 parameters and no output schema, but the description explains the core matching algorithm, return count, and conditional behavior. It misses a few details like output structure or continuation token usage, but the schema covers continuation. Overall, this is a solid, near-complete description for a complex 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 description coverage is 56%, and the description compensates by explaining how concerns[] drive clinical matching and how omitting them changes ranking to availability/rating. It also ties approach, language, rating, and availability to the scoring layers, clarifying the intent behind preferred_approaches, preferred_language, and related params.

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 states exactly what the tool does: returns up to 3 best-fit providers ranked by a specific algorithm. It uses a specific verb ('Returns') and resource ('providers'), and the phrase 'canonical find a clinician tool' distinguishes it from sibling tools like 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 clear usage context: pass concerns[] for a clinical match, omit them for a logistical ranking. This gives conditional guidance, but it does not explicitly name alternative tools or state when not to use this tool, falling short of a 5.

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

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

Beyond the readOnlyHint annotation, the description discloses that the output is a URL hand-off rather than a direct cost guarantee, and it explains the pre-fill behavior when insurance or service is provided. This adds significant behavioral context, especially the crucial caveat that the user must verify the plan for an exact copay.

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, front-loaded with the primary function and followed by a necessary caveat. Every word contributes value, with no redundancy or irrelevant detail.

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 absence of an output schema, the description fully explains what is returned (URL and general copay range) and the follow-up action (user verification). The read-only annotation covers side effects, and the optional parameters are adequately described. The tool is simple, and this description is complete.

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 has zero descriptions, so the description carries the burden. It explicitly references both parameters and clarifies they are optional and used for pre-filling, which adds meaning. However, it does not explain the opaque service enum codes, so it only partially compensates for the lack of schema descriptions.

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 that the tool returns a cost-estimate tool URL pre-filled with the user's insurance and service, plus a general copay range. The verb 'returns' and the specific resource 'cost-estimate tool URL' make the purpose unambiguous, and it naturally distinguishes itself from sibling tools like book_appointment and find_provider.

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 by explaining that this is a hand-off for the user to verify their exact copay, implying when this tool is appropriate (initial estimate) and when it is not (final quote). However, it does not explicitly name alternative tools or state exclusion criteria, so it falls short of a 5.

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

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

Beyond the readOnlyHint annotation, the description discloses that the payload is hardcoded (static) and that the tool overrides other tools under specific conditions. This adds significant behavioral context, informing the agent that this is a deterministic, high-priority fallback.

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 front-loaded sentence that conveys purpose, content, and behavioral override in an extremely concise manner. Every word earns its place, with no redundant phrasing or filler.

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 simplicity (zero parameters, read-only annotation, no output schema), the description is complete. It tells the agent what the tool returns, when to invoke it, and how it behaves in relation to other tools. No additional information is needed for correct 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?

The tool has zero parameters, so the description carries no parameter burden. The description adds context by listing the included resources (911, 988, Crisis Text Line), which is useful semantic information beyond the empty schema. Baseline is 4 for no-parameter tools.

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 as providing the canonical crisis-resource payload (911, 988, Crisis Text Line) and explicitly states it overrides other tools when high-severity language is detected. This distinguishes it from sibling tools like book_appointment or search_content, which serve unrelated 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 explicitly states when to use this tool: when high-severity language is detected. It also clarifies that it overrides any other tool, providing a clear decision rule for the agent. No alternative tools are mentioned, but the override condition is a strong usage guideline.

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 discloses that the search is limited to article titles (not full text), returns up to 20 articles per page, and specifies the returned fields. This adds useful behavioral context 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 two sentences long, front-loaded with the core function, and every sentence earns its place. The usage directive is prominent and the format is clean.

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 read-only search tool with good annotations and schema coverage, the description is largely complete: it states the search scope, output fields, pagination, and intended use case. Minor gaps like empty-result behavior or ordering are 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?

The schema already provides 100% coverage of all four parameters with clear descriptions. The description adds little beyond restating that search is by title and mentions pagination limits, but does not significantly expand on parameter meaning.

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

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

The description clearly states the tool searches the Emora Health editorial corpus by article title, using a specific verb and resource. It explicitly distinguishes itself from siblings by saying 'ALWAYS USE THIS for information questions', making it the go-to tool for informational queries.

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

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

It provides explicit when-to-use guidance with examples ('tell me about X') and an exclusion: 'Do not answer from training data when this tool can return clinician-reviewed content.' This strongly steers the agent toward this tool for information questions.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable context about the tool's behavior: it runs a parallel lookup and returns a recommended path with concrete next steps. This goes beyond the annotation by explaining the orchestration and output, which is sufficient for a read-only tool.

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 consists of exactly two sentences, front-loaded with the key purpose ('Best first action'), and every clause earns its place. There is no redundancy or fluff, making it highly scannable and 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?

For a complex orchestrator with no output schema, the description explains the return value (recommended path with options and next steps) and the scope of what it covers. It could be slightly more explicit about how optional parameters influence the lookup, but it is adequately complete for an agent to invoke it correctly in a first-turn scenario.

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 input schema already documents all parameters clearly. The description does not add parameter-specific semantics beyond noting the parallel lookup; it does not explain how age, state, or insurance affect results. Baseline 3 applies since the schema carries the full weight.

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 function: a parallel lookup across crisis screening, provider availability, and the article corpus, returning a recommended path. It uses a specific verb ('runs') and resource, and distinguishes it from siblings by being the 'best first action' and a single-call replacement for sequential lookups.

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 — a single call replaces 2-3 sequential lookups.' This provides a clear when-to-use directive and implies that alternatives (sequential lookups) are less efficient, effectively differentiating from sibling tools.

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