Search providers, check availability, book evaluations, and estimate insurance copays.
Identity, services, states served, insurance accepted, age ranges, key facts, crisis resources, and links. Combined site-info + services catalog.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
CRITICAL: Returns a booking URL — DO NOT navigate the user programmatically. Hand the URL to the user and let them click through. Pre-fills provider, time slot, state, and insurance for ~2-minute checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| date_time | Yes | Time slot string from check_availability (e.g. "2026-04-27T13:00:00-04:00"). REQUIRED — the booking form is stuck on step 1 without it. Pass exactly as received from check_availability. | |
| insurance | No | ||
| provider_id | Yes | ||
| appointment_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the description correctly avoids claiming a direct write and adds valuable context: the tool returns a URL, the user must click through, and the response pre-fills checkout details. This goes beyond the annotation without contradicting it.
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 tight sentences with the critical warning front-loaded. Every sentence earns its place; no filler or repetition of schema 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?
For a 5-parameter tool with no output schema, the description covers the core return value (booking URL) and the mandatory user-handoff behavior. It's missing appointment_type semantics and any sibling routing guidance, so it's not fully 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?
Schema description coverage is only 20%, so the description muss compensate. It usefully explains that provider, time slot, state, and insurance are pre-filled into the URL, but it omits appointment_type entirely and doesn' clarify where provider_id comes from. This is partial compensation with clear gaps.
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 provider, time slot, state, and insurance. It describes a specific deliverable and user-facing behavior, but does not distinguish it from the sibling book_matching_session, so it misses a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a CRITICAL usage rule: do not navigate the user programmatically; hand the URL to the user. It also implies the tool builds on chec_availability by referencing the time slot. However, it doesn't clearly say when not to use this tool or when to choose book_matching_session instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CRITICAL: provider_id is REQUIRED. Always call find_provider first (with appointment_type='446840' for the Clinical Matching Session) to get a specific intake specialist, then pass that provider_id here. Returns a pre-filled booking URL — do NOT navigate the user programmatically.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | U.S. state where the client resides. | |
| date_time | Yes | Time slot string from check_availability for the chosen intake specialist (e.g. "2026-04-27T13:00:00-04:00"). REQUIRED — the booking form is stuck on step 1 without it. Pass exactly as received from check_availability. | |
| insurance | No | Insurance plan name. Pre-fills the form so verification runs faster at checkout. | |
| client_age | No | Client age in years (0–25+). | |
| provider_id | Yes | Healthie ID of the intake specialist. Get this from find_provider with appointment_type='446840'. REQUIRED — never construct the URL without it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already covering safety, the description adds valuable context: the tool returns a pre-filled URL rather than performing the booking itself, and programmatic navigation must be suppressed. The title says 'Book' but the description and annotation are consistent with a read-only URL-returning operation, so there is no 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?
Two sentences with high signal density: the critical prerequisite is front-loaded, the workflow is compressed, and the behavioral boundary ('do NOT navigate') is included without padding. Every phrase 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 5-parameter tool with no output schema, the description explains the return value (URL), the critical dependency (find_provider), and the required follow-up behavior. It could more explicitly mention the check_availability step for date_time and note book_appointment as the generic alternative, but the schema already documents check_availability for date_time, so the context is largely sufficient.
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% and the property descriptions already explain provider_id source, date_time source, requiredness, and enums. The description repeats the provider_id requirement and find_provider dependency but adds no semantics beyond the schema, so it earns 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 states a concrete outcome: it returns a pre-filled booking URL for a Clinical Matching Session after a provider is supplied. This is a clear verb and resource, and the appointment_type='446840' and 'Clinical Matching Session' distinguish it from generic booking. It does not explicitly contrast itself with the sibling book_appointment, so it stops short of full sibling differentiation.
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 gives an explicit prerequisite and ordering: always call find_provider with appointment_type='446840' first, then pass the resulting provider_id here. It also gives a clear operational rule: do not navigate the user programmatically. It does not state when to prefer this over book_appointment or when not to use it, so it is not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse Emora Health condition / specialty / insurance pages. Returns either a specific page (with slug) or a paginated list. These are the canonical site pages, not blog articles.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for the listing (default 1). | |
| slug | No | Specific page slug (e.g. "anxiety", "play-therapy", "aetna"). Omit to list all pages. | |
| limit | No | Page size for the listing (default 50, max 100). | |
| collection | Yes | Page collection: "conditions-pages", "specialty-pages", or "insurance-pages". |
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.
Real-time availability for ONE specific provider. Returns the next 10 open slots with start timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| provider_id | Yes | ||
| appointment_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool's safe, non-mutating nature is covered. The description adds useful context: 'real-time' and a fixed limit of 'next 10 open slots' with start timestamps. However, it doesn't disclose behavior on no available slots, invalid provider, or pagination, which are gaps beyond the annotation's safety coverage.
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 with no filler. The primary purpose ('Real-time availability for ONE specific provider') is front-loaded, and the return behavior is stated in the second sentence. Every word earns its place; this is appropriately sized for a simple lookup tool.
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 three required parameters and no output schema, the description omits critical context: it does not explain that state and appointment_type are needed, nor what the numeric codes represent, nor error behavior when no slots exist. Since there is no output schema, the description also fails to describe the structure of returned slots beyond 'start timestamps'. The tool is simple, but the description leaves too much for the agent to infer.
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 barely does. It only implies provider_id via 'ONE specific provider' and gives no indication of what state or appointment_type (the numeric enum values) mean. Field names and enums are the only signal, leaving the agent to guess at the semantics of required parameters.
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?
States a specific verb ('returns availability') and resource ('slots for ONE specific provider'), clearly distinguishing it from sibling tools like find_provider (search) and book_appointment (booking). The phrase 'ONE specific provider' explicitly narrows the scope, so an agent can immediately tell it apart from a provider-search 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 implies this tool is for checking slots of a known provider (via 'ONE specific provider') but does not explicitly state when to use it instead of siblings. It doesn't mention that find_provider should be used to locate a provider first, or that book_appointment follows this check. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The canonical 'find a clinician' tool. Returns up to 3 best-fit providers ranked by Emora's production matching algorithm (rankTherapist): each concern maps to weighted specialties; each provider's specialties score against that map; approach / language / rating / availability layer on top. Pass concerns[] for a clinical match; omit them for a logistical (availability + rating) ranking.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| concerns | No | Concern IDs from the curated enum (see ConcernId). Pass 1-3 for best results — too many concerns dilute the score. | |
| insurance | No | ||
| client_age | No | ||
| continuation | No | Token from a previous find_provider call. Re-applies prior client profile; new args override. | |
| appointment_type | Yes | ||
| preferred_gender | No | Provider gender preference (e.g. 'female','male','non-binary'). | |
| preferred_language | No | Non-English language the provider should speak. | |
| preferred_approaches | No | Therapy modalities the user prefers (e.g. ["cbt","dbt","playTherapy"]). Bumps the score for providers whose approaches list includes these. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark readOnlyHint=true; the description adds detailed behavior beyond that: returns up to 3 providers, ranking is based on weighted specialty maps with approach/language/rating/availability layered on top, and the two ranking modes. 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?
Two dense but purposeful sentences; the canonical claim and ranking mechanism are front-loaded and no filler is present. The algorithm detail is justified because it affects how an agent should reason about results.
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?
Strong for a 9-param tool with no output schema: it states return count, ranking mode, and overall scoring. It falls short of complete because the required appointment_type values remain opaque IDs and the returned provider object structure is not described.
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?
Adds meaning beyond the schema by explaining how concerns drive the clinical score and how omitting them switches to a logistical ranking. Schema already covers several params, though the opaque appointment_type enum IDs and client_age are not clarified in either place.
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?
States precise verb+resource: 'canonical find a clinician tool' returning up to 3 best-fit providers. Differentiates itself by describing the production matching algorithm, so an agent can tell it from sibling tools like check_availability or book_appointment.
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?
Gives explicit conditional guidance: pass concerns[] for clinical matching, omit them for logistical ranking. It does not explicitly compare against sibling tools (e.g., check_availability for exact slots), but the in-tool branching is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the cost-estimate tool URL pre-filled with the user's insurance + service if provided, plus the general copay range. The tool URL is a hand-off — the user verifies their plan there for an exact copay.
| Name | Required | Description | Default |
|---|---|---|---|
| service | No | ||
| insurance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though the readOnlyHint annotation already signals safety, the description adds important behavioral context: the tool returns a URL and a general copay range, not exact pricing, and relies on the user to verify. This clarifies that the tool is a starting point rather than a final quote, going beyond what annotations alone convey.
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 filler. It front-loads the main action and output, then adds the critical hand-off nuance. Every sentence earns its place, and the structure is easy to scan.
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 tool with two optional enum parameters and no output schema, the description covers the key behaviors: what is returned and the need for user verification. It does not specify what happens when no parameters are provided, but the phrase 'if provided' implies the URL is still returned without pre-filling. Overall, this is nearly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate for missing parameter semantics. It mentions 'insurance + service' and 'if provided,' which conveys the role and optionality of the two parameters. However, it does not explain the meaning of the opaque service enum codes (e.g., '354092') or how to map user intent to those values, leaving a gap for the agent.
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 action: it returns a cost-estimate tool URL pre-filled with optional user information, plus a general copay range. The hand-off nature is explicitly stated, and this distinguishes it from sibling tools like book_appointment 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 the tool is for providing a general estimate and then letting the user verify the exact copay on the returned URL. It gives clear context for when to use it, though it does not explicitly name alternatives or state when not to use it. The hand-off sentence sets the expectation for how to apply the tool result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Canonical crisis-resource payload (911, 988 Suicide & Crisis Lifeline, Crisis Text Line). Hardcoded — overrides any other tool when high-severity language is detected.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Search the Emora Health editorial corpus by article title. Returns up to 20 articles per page with title, description, URL, and category. ALWAYS USE THIS for information questions ("tell me about X", "what are signs of Y", "how does Z work"). Do not answer from training data when this tool can return clinician-reviewed content.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default 1). | |
| limit | No | Max results per page (default 10, max 20). | |
| query | Yes | Search term to match article titles. | |
| category | No | Optional category filter. |
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.
Best first action for a user describing a concern. Runs a parallel lookup across crisis screening, provider availability, and the article corpus, then returns the recommended path (crisis | evaluation | self-help | mixed) with concrete next steps. Optimized for the agent's first turn — a single call replaces 2-3 sequential lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Client age in years (0–25+). | |
| state | No | U.S. state where the client resides. | |
| concern | Yes | Free-text description of what the user is experiencing or concerned about. | |
| insurance | No | Insurance plan name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful behavior: parallel lookup across three data sources, a single aggregated recommendation, and concrete next steps. It also discloses the possible output categories, which is valuable beyond the structured 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?
Three tight sentences with no filler. The key use case, behavior, output, and efficiency benefit are all front-loaded and every 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?
The description covers the tool's role, what it does internally, what it returns, and when to use it. There is no output schema, but the described return categories and next steps give an agent enough shape to trust the call. Slight gap: no detail on how optional parameters like state or insurance influence the lookup, though the schema covers their meanings.
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 all four parameters are already documented. The description only reinforces that 'concern' comes from the user's description, adding little semantic value beyond the schema, so 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?
States a specific verb ('runs a parallel lookup'), a clear resource scope (crisis screening, provider availability, article corpus), and a defined output (recommended path with categories). It is immediately distinguishable from siblings like find_provider or get_crisis_resources, which are single-purpose 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?
Explicitly positions this as the 'best first action' and 'optimized for the agent's first turn', and notes it replaces 2-3 sequential lookups. It does not explicitly name when-not-to-use alternatives, but the first-turn framing is a clear, actionable condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Find and book doctor, dentist & nurse appointments. 2M+ providers by insurance & cost in the US.
Find participating local service providers and book live appointment times.
Find, compare, and book local service businesses: live availability, prices, reviews, booking.
Discover local services and availability, then create, track, reschedule, or cancel bookings.
Add one secure layer between your agents and this server.
Each tool targets a distinct action (about, book, browse, check, find, search, start) and descriptions clarify boundary cases (e.g., book_appointment vs book_matching_session, search_content vs browse_pages). Minor overlap remains between about_emora's service catalog and browse_pages' service/specialty/insurance pages, but it is unlikely to misdirect an agent.
Tool names are uniformly lowercase snake_case and mostly follow an imperative verb_noun pattern (find_provider, check_availability, get_cost_estimate). Two small deviations — about_emora and start_here — are still readable and don't undermine the overall predictable pattern.
Ten tools is squarely in the ideal range and each one serves a meaningful step in the mental-health care journey: orientation, crisis support, content search, provider matching, availability, cost estimation, and booking. There is no obvious redundancy or bloat.
The tool set covers the full discovery-to-booking funnel, including crisis triage, provider search, availability, cost estimates, and two booking paths. Minor gaps exist (no explicit reschedule/cancel or appointment-list tool), but those actions plausibly live outside this server's hand-off model.