Cuvo Health published site content and live discovery-call booking tools for AI agents.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 9 of 9 tools scored. Lowest: 3.7/5.
Each tool maps to a distinct resource or action: content retrieval (get_article, get_comparison, get_overview, get_pricing), list indices (list_articles, list_comparisons), and scheduling actions (get_availability, book_discovery_call, request_callback). The only near-overlap, book_discovery_call versus request_callback, is clearly separated by their descriptions and required inputs.
All tool names follow a verb_noun snake_case pattern: get_* for singular resources, list_* for collection indices, and book_*/request_* for conversion actions. The naming style is consistent and the verb family matches the tool's role.
Nine tools is a well-scoped size for this server: individual content pages, content lists, and call-booking actions each earn their place. There is no redundancy or sprawl.
The tool surface covers the full website and lead-gen workflow: users can discover content, retrieve full pages, check availability, book a discovery call, or request a callback. The content tools feed directly into their paired retrieval tools, and the scheduling tools cover the expected alternatives.
book_discovery_callBook a discovery callAInspectBook a real 30-minute Cuvo discovery call for the user. Requires their explicit confirmation of a specific slot from get_availability plus their real full name and email; the calendar invite goes to that email. Do not book without the user's consent.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | User's full name | |
| Yes | User's email (receives the invite) | ||
| phone | No | Optional phone number | |
| timezone | Yes | IANA timezone used when fetching availability | |
| slot_start_iso | Yes | startIso of the chosen slot, exactly as returned by get_availability |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description communicates that this is a real booking, that a calendar invite goes to the user's email, and that the user must explicitly consent. These are meaningful side effects beyond the annotations' readOnly=false and idempotent=false flags. 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 sentences, no filler. The first sentence states the action and target, the second details all necessary preconditions and a clear 'do not' warning. Every clause adds decision-relevant 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?
The description covers prerequisites, side effects, and consent, which are the important details for a booking action. The only gap is unintuitiveness about what happens on success or failure (confirmation, invite link, error behavior) since no output schema exists, but this is not critical for correctly calling the 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 100%, so the schema fully explains all 5 parameters. The description repeats that the slot must come from get_availability and the email receives the invite, but those points are already in the schema. The description adds a minor emphasis on using the user's real name/email, which does not materially raise the score above the baseline.
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 opens with a specific verb and resource: 'Book a real 30-minute Cuvo discovery call.' It immediately identifies the subject (the user) and ties the slot to the get_availability sibling, which makes the tool distinct from read-focused 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 gives conditional prerequisites: explicit confirmation of a specific slot from get_availability, and a real full name and email. It also tells the agent to never book without consent. It does not name an alternative such as request_callback, so the when-not/branching guidance is clear but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_articleRead one blog articleAFull text (markdown) of one published article, by slug from list_articles.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Article slug, e.g. "dea-telemedicine-flexibilities-2026" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond that: it states the response format (markdown) and that only published articles are returned, which is useful agent information.
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 that front-loads the most important information (full text, markdown, one article). Every word earns its place and no redundancy is present.
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 single-parameter read operation, the description covers the return format (markdown), the input source (slug from list_articles), and the applicable scope (published articles). With no output schema, the description adequately conveys what the agent will receive. No critical details are missing.
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 fully documents the 'slug' parameter with an example. The description additionally states the slug comes from list_articles, giving the agent a direct source for where to obtain a valid value. This adds meaning 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 states a specific action and resource: returns full-text markdown of one published article. It also distinguishes itself from list_articles by specifying this takes a slug from that list. An agent can clearly identify the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by slug from list_articles' provides clear usage context by tying this tool to the output of list_articles. It implies the proper workflow without explicitly listing alternatives or exclusions, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_availabilityCheck discovery-call availabilityANext open 30-minute discovery-call slots on the Cuvo team's calendar, in the user's timezone. Call before offering any times; returns each slot's startIso and human label.
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | No | IANA timezone of the user, e.g. "America/New_York". Defaults to America/New_York. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnly, openWorld, idempotent, and non-destructive behavior. The description adds context beyond that: it returns live calendar slots, is timezone-aware, and provides one each slot's startIso and human label. This is meaningful behavioral detail beyond what annotations provide.
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 definition is two tight sentences: the first front-loads the purpose and scope, and the second adds a clear usage directive and return-value details. Every word adds value, with no filler or repetition.
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 low-complexity tool with one optional parameter and no output schema, the description covers what it returns, when to call it, and the dynamic nature of the data. The main omission is the slot count limit or behavior when a calendar has no free slots, but these are minor 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 description coverage is 100% for the single optional timezone parameter, and the schema already explains the format and default. The tool description only mentions 'in the user's timezone' indirectly, adding no new parameter semantics, so the 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?
Description clearly states the action (get next open 30-minute discovery-call slots), the resource (the Cuvo team's calendar), and the relevant scope (in the user's timezone). It distinguishes itself from siblings like book_discovery_call by the 'Call before offering any times' instruction, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage rule: 'Call before offering any times.' This provides clear context for when to use the tool. However, it does not explicitly call out alternatives or when-not-to-use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_comparisonRead one comparison pageAFull text (markdown) of one Cuvo-vs-competitor comparison page, by slug from list_comparisons.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Comparison slug, e.g. "cuvo-vs-wheel" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior, so the safety burden is lifted. The description adds the return format ('Full text (markdown)') and confirms it returns the complete content of a single page, which is valuable behavioral context beyond the 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?
A single and concise sentence carries all necessary information: what is returned, the resource, and the source of the parameter. The most important scope ('one comparison page') is front-loaded and there is no 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?
For a single-parameter, read-only, no-output-schema tool, the description is sufficient. It tells the agent what it returns, how to identify the target (slug), and where to obtain the slug. No behavioral or routing aspects needed for a correct call are missing.
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 documents slug with an example (cuvo-vs-wheel) at 100% coverage, so a baseline 3 applies. The description adds the provenance hint 'from list_comparisons,' telling the agent where to obtain a valid slug, which expands on the bare 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 states a specific verb and resource: it retrieves the full markdown text of one Cuvo-vs-competitor comparison page. It is clearly scoped to comparison pages and one page at a time, distinguishing it from list_comparisons and other get_* siblings like get_article or get_pricing by resource type.
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 'by slug from list_comparisons' provides a clear workflow: the agent must first obtain a slug from the sibling list_comparisons tool, then call get_comparison. It does not explicitly enumerate when-not-to-use alternatives like get_article or get_overview, but the 'comparison page' resource clearly routes the agent to the appropriate sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_overviewCuvo overview and FAQAWhat Cuvo Health is, who it is for, and the canonical FAQ: the white label telehealth platform that operates the licensed clinic behind consumer brands.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds content context but not much behavioral information such as response shape or format, though for a zero-parameter read-only overview this is a minor gap.
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 packed sentence with no filler or redundant detail. It front-loads the core content and then gives the precise product context.
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, zero-parameter, read-only overview tool, the description covers what is returned, the intended audience, and the surrounding context. It does not explicitly describe the return format, but no output schema exists and the tool's nature makes that less 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?
There are zero parameters and no required inputs, so there is nothing for parameter semantics to explain. The schema coverage is 100% by default, and the baseline for a 0-parameter tool is 4.
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 resource by saying what the tool provides: an overview of what Cuvo Health is, who it is for, and the canonical FAQ. It is distinguishable from article, comparison, and pricing siblings, though it does not name them explicitly.
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 'overview and FAQ' implies use for general background questions about Cuvo Health, and annotations indicate a safe read-only call. However, it does not explicitly say when to prefer it over get_article, get_comparison, or list_articles, so selection guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pricingPublished pricingACuvo's published pricing as markdown: plan tiers with setup fees, the flat $25 per-consult fee, 0% medication markup, commercial terms, and add-ons.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful context by specifying the response is markdown and detailing exactly what pricing elements are included. 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?
A single, front-loaded sentence that names the resource, format, and scope. Every phrase adds information and there is no 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?
For a zero-parameter, read-only tool with no output schema, the description fully compensation by naming the return format (markdown) and the specific content categories an agent should expect. Nothing essential is missing.
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 there is nothing for the description to clarify. The baseline of 4 applies because parameter semantics are not needed for this tool.
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 and resource: getting Cuvo's published pricing. The content list (plan tiers, setup fees, per-consult fee, medication markup, commercial terms, add-ons) distinguishes it from sibling tools like get_availability, get_overview, or get_comparison.
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 makes the tool's purpose clear, but does not explicitly say when to use it over alternatives such as get_overview or get_comparison. Usage must be inferred from the name and the phrase 'published pricing' rather than stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_articlesList blog articlesAList every published article on the Cuvo blog (slug, title, excerpt, date, category): telehealth compliance, pharmacy, and growth guides.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral detail: only published articles are included, and the exact returned fields are enumerated. This is sufficient for a simple list 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?
A single, well-structured sentence that front-loads the action and resource, then provides useful details about returned fields and content categories. No filler or repetition.
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 parameter-free list operation with no output schema, the description provides sufficient information: what is returned, the topic scope, and the fact that it is a complete list of published articles. Nothing critical is missing for an agent to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for this dimension is 4. The description adds value by clarifying the output fields and scope, though no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('list') and resource ('every published article on the Cuvo blog'), and names the output fields and topical categories. This clearly distinguishes the tool from its siblings such as get_article and list_comparisons.
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 clear context: use this tool to fetch the full blog article catalog, not individual or comparison resources. It does not explicitly enumerate when-not-to-use alternatives, but the scope is obvious from the wording and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_comparisonsList comparison pagesAList every Cuvo-vs-competitor comparison page (slug, competitor name, one-line summary, facts-reviewed date).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds the output fields and the 'every' scope, which is useful context, but it does not disclose potential pagination, ordering, or volume behavior. This is acceptable for a simple listing 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?
A single sentence conveys all essential information: what is listed, the scope, and the output fields. There is no filler or 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?
For a parameterless listing tool with no output schema, the description is complete: it identifies the resource, scope, and returned fields. An agent can understand the tool's behavior and expected result without additional context.
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 and the schema is empty, so there is nothing to explain. The description instead covers what the call returns, which is the relevant semantic information here.
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 a specific verb ('List') and a clear resource ('every Cuvo-vs-competitor comparison page') while enumerating the exact output fields. This cleanly distinguishes it from the sibling get_comparison, which presumably returns a single page.
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 'List every' clearly implies this is the enumeration tool for all comparison pages, distinct from get_comparison for retrieving one page. It does not explicitly state when not to use it, but the scope is sufficiently unambiguous for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_callbackRequest a phone callbackAInspectAsk the Cuvo team to phone the user back, when live booking is unavailable or the user prefers a callback. Requires the user's consent, name, and phone number.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| phone | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is non-read-only, non-idempotent, and open-world. The description adds that user consent is required and frames the action as a real-world team behavior, which is useful context beyond the 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 only two sentences and front-loads the core purpose before mentioning the callback conditions. Every sentence contributes useful information and none of it simply echoes annotations or schema.
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 callback request with two string parameters and no output schema, the description provides the needed context: what happens, when to use it, and what is required. It doesn't detail potential complications like callback timing or follow-up behavior, but those aren't needed for selecting the 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 descriptions are entirely absent, so the tool description must compensate. It references the user's name and phone number, which partially clarifies the schema's `name` and `phone` fields, but it doesn't communicate format or additional constraints for the phone value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: asking the Cuvo team to phone the user back. It also gives two concrete circumstances for using it, which distinguishes it from the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: when live booking is unavailable or when the user prefers a callback. It also mentions the necessary precondition of user consent, though it doesn't explicitly mention sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
