Read-only CloudMedico product information with verified source links.
Scored across 6 tools
Each get_* tool maps to one clearly named public page (FAQ, features, pricing, product overview, AI assistant connections), so boundaries are mostly obvious. The only mild overlap is search_public_knowledge, which can surface the same allow-listed pages as the dedicated getters, making the choice between searching and fetching occasionally unclear.
All six tools follow a predictable verb_noun pattern: get_<page> for direct page fetches and search_public_knowledge for the search operation. The long name get_ai_assistant_connections_overview is verbose but still conforms to the same convention.
Six tools is well-scoped for a read-only public-information server, with each tool covering a distinct page or a search fallback. Nothing feels padded or missing from a count perspective.
The set covers the main public surfaces (product overview, features, pricing, FAQ, AI connections) plus a bounded search over the allow-list, giving no hard dead ends for public inquiries. Minor gaps remain, such as no dedicated pages for contact/support, security or compliance, or API documentation, though search may partially cover these.
Returns the canonical public CloudMedico AI assistant connections page. It does not access account, tenant, clinical, patient, registration, billing, or chatbot data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already declaring safety, the description usefully adds a data-boundary disclosure: no access to account, tenant, clinical, patient, registration, billing, or chatbot data. That tells the agent this is a purely static public page, which is real behavioral context beyond the annotation, though it says nothing about pagination, caching, or freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the core purpose front-loaded and the scope caveat second. Every clause earns its place and nothing is repeated from the schema or annotations.
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?
An output schema exists so return values need no explanation, and the zero-parameter schema is fully covered. The only gap is the absence of sibling-routing guidance, which for a simple public-page fetch is a minor omission rather than a blocking one.
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 takes zero parameters, so the baseline is 4 per the rubric and no parameter explanation is required. Schema coverage is 100% with an empty object schema, so there is nothing for the description to compensate for.
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) and resource (the canonical public CloudMedico AI assistant connections page), which an agent can distinguish from get_faq, get_pricing, and search_public_knowledge. It does not, however, explicitly contrast itself with the closely related get_product_overview sibling, leaving that distinction to inference.
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 no when-to-use condition and never names an alternative sibling tool for overlapping informational needs. The negative-scope sentence hints at what the tool is not, but offers no routing guidance for choosing it over get_product_overview or search_public_knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the canonical public CloudMedico FAQ page. It does not access account, tenant, clinical, patient, registration, billing, or chatbot data.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional FAQ topic to use as context for the canonical source. |
| Name | Required | Description |
|---|---|---|
| topic | Yes | |
| sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers safety, and the description adds genuine value beyond it: the negative scope list tells the agent this tool will never surface tenant, clinical, or billing data, which is useful for deciding where to route sensitive queries. It stops short of describing caching, freshness, or the canonical-source behavior of the topic param.
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 tight sentences, front-loaded with the core purpose and followed by a high-value boundary statement. Nothing is wasted.
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?
Output schema exists so return values need not be explained, and annotations plus the negative scope list cover the safety profile. For a zero-required-param, single-optional-param read tool this is nearly complete; only sibling routing is absent.
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% and the single optional 'topic' parameter is fully documented in the schema, so the baseline of 3 applies. The description adds no meaning about how topic is matched or whether it filters versus merely contextualizes results.
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: 'Returns the canonical public CloudMedico FAQ page.' An agent can tell it apart from get_product_overview, get_pricing, and get_features, though no sibling is named 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 description implies usage by defining the public FAQ scope and listing what it does NOT touch (account, tenant, clinical, patient, registration, billing, chatbot data), but it never states when to pick this over search_public_knowledge or the other overview tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the canonical public CloudMedico feature page. It does not access account, tenant, clinical, patient, registration, billing, or chatbot data.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional CloudMedico feature category to use as context for the canonical source. |
| Name | Required | Description |
|---|---|---|
| sources | Yes | |
| category | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description goes further by declaring a data boundary — it will not touch account, tenant, clinical, patient, registration, billing, or chatbot data — which is genuinely useful scoping an agent cannot get from annotations or schema.
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 the return value and followed by the boundary constraint. No filler, nothing repeated from the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return shape need not be described; one optional param is fully documented in the schema. The description covers purpose and data scope, which is everything needed to invoke it 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?
Schema description coverage is 100% and the single optional 'category' param is documented there as context for the canonical source. The description says nothing about the parameter, so it adds no value beyond the schema; baseline 3 applies.
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 names a specific verb and resource ('Returns the canonical public CloudMedico feature page'), so an agent knows exactly what comes back. It does not, however, contrast itself with siblings like get_product_overview or search_public_knowledge, so differentiation is left to inference.
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?
Usage is only implied: a public feature lookup. The negative clause ('does not access account, tenant, clinical...') functions as a soft when-not, but no alternative tool is named and no condition selects this over get_product_overview or search_public_knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the canonical public CloudMedico pricing page. Pricing remains subject to the published page and market-specific qualifiers; the tool does not access account, tenant, clinical, patient, registration, billing, or chatbot data.
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | Optional market or country context for the published pricing information. |
| Name | Required | Description |
|---|---|---|
| market | Yes | |
| sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only declare readOnlyHint=true, so the description usefully adds scope beyond that: it discloses that pricing is subject to the published page and market qualifiers, and enumerates what data the tool does not access (account, tenant, clinical, patient, billing, etc.). These data-boundary disclosures are valuable context that the annotations do not carry.
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 the core action front-loaded, followed by scope caveats. No wasted phrasing, though the enumerated list of excluded data types is somewhat long for a simple pricing lookup.
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?
An output schema exists, so return formatting need not be explained. For a zero-required-parameter read-only lookup, the description covers the resource, the caveat about pricing volatility, and the data-access boundaries, which is sufficient for correct 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?
Schema description coverage is 100%, so the single optional 'market' parameter is already documented in the schema as 'Optional market or country context for the published pricing information.' The description's mention of 'market-specific qualifiers' loosely reinforces this but adds no syntax or format detail. 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 states a specific verb and resource: 'Returns the canonical public CloudMedico pricing page.' This clearly distinguishes it from sibling tools like get_features, get_faq, and get_product_overview by resource, though it does not explicitly name those alternatives.
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?
There is no explicit when-to-use guidance or named alternative. An agent might reasonably wonder whether pricing questions should route here or to search_public_knowledge, and the description does not resolve that. Usage is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a concise CloudMedico public-product overview and canonical public source URLs. It never returns account, tenant, clinical, patient, registration, billing, or chatbot data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| sources | Yes | |
| summary | Yes | |
| productName | Yes | |
| intendedUsers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the safety profile, so the bar is lower, yet the description adds genuinely useful scope context: an explicit negative enumeration of data domains it will never return (account, tenant, clinical, patient, registration, billing, chatbot). This prevents misuse for lookups it cannot satisfy. It does not mention caching, freshness, or rate limits.
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 positive capability (overview + canonical source URLs) is front-loaded, and the exclusion list follows. Every clause carries information the agent needs.
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?
An output schema exists, so return-value shape need not be explained. For a read-only, zero-parameter overview tool, the description covers capability, scope boundaries, and exclusions; the only missing element is explicit routing guidance relative to the four sibling tools.
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 takes zero parameters, and the schema is a closed empty object with 100% description coverage, so there is nothing for the description to disambiguate. Baseline 4 for a no-parameter tool 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 states a specific verb and resource (returns a CloudMedico public-product overview plus canonical public source URLs), which is clear enough to distinguish this broad overview tool from the narrower siblings get_faq, get_features, and get_pricing. It does not explicitly name any sibling, so it falls short of full routing clarity.
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?
Usage is implied rather than stated: the phrase 'public-product overview' and the list of excluded data domains signal this is for general public product information, not account or clinical lookups. However, it never says when to prefer this over get_features, get_pricing, get_faq, or search_public_knowledge, so an agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches a bounded allow-list of verified public CloudMedico pages and returns canonical source URLs. It never searches tenant, account, clinical, patient, registration, billing, or chatbot data.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The public CloudMedico topic to search for. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered, but the description adds meaningful context: the search is bounded to a verified allow-list and explicitly excludes sensitive data categories, which is a real privacy/data-scoping guarantee an agent should know. It does not mention rate limits, ranking, or result-count behavior, keeping it short of a 5.
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 tight sentences with zero waste: the positive capability is front-loaded, followed immediately by the exclusion boundary. 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?
With an output schema covering return values and annotations covering read-only safety, the description supplies the remaining essentials: allow-list scope, canonical URL returns, and excluded data domains. The only material gap is routing guidance against the sibling getters.
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 is one parameter with 100% schema description coverage, so the schema already documents the query field and its length bounds. The description adds no syntax, phrasing, or query-construction guidance beyond what the schema provides, which is the baseline 3 for fully covered 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 and resource: it searches a bounded allow-list of verified public CloudMedico pages and returns canonical source URLs. The scope is precise enough to distinguish it from the fixed-topic get_* siblings, though it never names them or explicitly contrasts free-text search against those fixed getters.
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 strong negative scope ('never searches tenant, account, clinical, patient, registration, billing, or chatbot data'), which tells the agent what data this tool cannot reach. However, it offers no positive guidance on when to pick this over get_faq, get_features, get_pricing, or get_product_overview, so the agent must infer that free-text search complements the fixed endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_ai_assistant_connections_overviewget_faqget_featuresget_pricingget_product_overviewsearch_public_knowledgeCited product-compliance ground truth for AI agents. Never generates; always cites.
Read-only U.S. healthcare dataset metadata, schemas, immutable downloads, and checksums.
Read-only U.S. lab-test catalog, collection-site search, and reference-range context.
Read-only approved AI tools, public stacks, guides, and evidence-aware comparisons.
Add one secure layer between your agents and this server.
