Find public biomarker education, available blood tests, panels, and budget-aware starting points.
Average 4.3/5 across 16 of 16 tools scored. Lowest: 3.7/5.
Several tools overlap in purpose: browse_biomarkers, get_biomarker, get_biomarkers, and search_biomarkers all expose biomarker lookup with only subtle distinctions, while fetch duplicates general access. An agent could easily select the wrong retrieval variant.
Most tools follow a consistent snake_case verb_noun pattern such as get_*, list_*, search_*, and browse_*. However, bare fetch and search, plus the longer compare_blood_testing_services, break the otherwise predictable convention.
16 tools is on the heavy side for a public read-only information server, and the count is inflated by overlapping biomarker and search accessors. The domain could likely be served with a smaller, more consolidated surface.
The set covers public browsing, exact retrieval, search, catalog pricing, lab package details, comparisons, recommendations, and guided builder entry. Minor gaps exist around panel listing and public document discovery, but core workflows have no dead ends.
browse_biomarkersBrowse What We TestAReturns the public What We Test collection with stable cursor pagination and optional category or sex-applicability filters. The response excludes diagnosis and private lab results.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum biomarkers to return (default 20, max 50). | |
| cursor | No | Opaque pagination cursor from a prior response. | |
| gender | No | Optional applicability filter; defaults to all. | |
| category | No | Optional public category slug. |
| Name | Required | Description |
|---|---|---|
| biomarkers | Yes | |
| pagination | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds meaningful behavioral context beyond annotations: pagination is stable, results are public-only, and diagnosis/private lab results are excluded. This gives an agent important expectations about data scope and response behavior.
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 delivers the core behavior, pagination trait, filters, and exclusions without any redundancy. Every clause earns its place and no boilerplate 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 read-only browse operation with a rich output schema, 100% parameter coverage, and safety annotations, the description is complete. It covers the collection's scope, pagination stability, filter options, and data exclusions, so an agent has enough context 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%, so the schema already documents all four parameters including defaults, constraints, and enum values. The description adds only a light mapping of 'category' and 'sex-applicability filters' to parameters, which is useful but not a major addition over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific verb ('Returns') and resource ('public What We Test collection'), and adds key differentiators: stable cursor pagination, optional filters, and the exclusion of diagnosis/private lab results. This distinguishes it from sibling tools like get_biomarkers or search_biomarkers even without naming them.
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: this is for browsing the public collection with pagination and filters, and it is not for private or diagnostic data. It does not explicitly name alternatives or state when-not-to-use, but the 'public collection' and 'excludes... private lab results' framing makes the intended use reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_blood_testing_servicesCompare blood testing servicesAReturns a factual side-by-side comparison of Vitals Vault and a supported blood-testing service using public master-table facts and methodology. It excludes medical advice and unsupported superiority claims.
| Name | Required | Description | Default |
|---|---|---|---|
| competitor | No | Optional competitor slug from the public comparison registry. |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| rows | Yes | |
| methodology | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the description only needs to add scope. It does so by specifying that output is fact-only, based on public master-table facts, and excludes unsupported superiority claims, which prevents an agent from expecting subjective or recommendation-style output.
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?
Exactly two sentences, with the core function in the first and a boundary condition in the second. No wasted words.
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 one-optional-parameter, read-only comparison tool with an output schema and full annotation coverage, the description provides a complete mental model: what it returns, its factual basis, and its limitations. 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?
The only parameter, competitor, is fully described in the schema with an enum of supported slugs, so schema coverage is 100%. The description references 'supported blood-testing service' but does not add semantics beyond the schema; 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?
States a specific verb ('Returns'), a clear object ('side-by-side comparison of Vitals Vault and a supported blood-testing service'), and the evidential basis ('public master-table facts and methodology'). This clearly distinguishes it from sibling read tools that retrieve biomarkers or lab packages.
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 factual comparisons rather than recommendations or medical advice, and its 'excludes medical advice' line hints at a limitation. However, it does not explicitly compare against siblings such as recommend_panel or search_lab_catalog, nor state when not to use it beyond avoiding medical-advice requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchFetch a Vitals Vault resultAFetches one public biomarker, panel, document, or comparison result by stable connector identifier. The response contains public data only and does not access private records.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Stable public identifier such as biomarker:apolipoprotein-b or doc:developers. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint. The description adds a meaningful extra guarantee: the response contains public data only and does not access private records. This is valuable privacy-related behavioral context beyond the annotations. 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 short, information-dense sentences. The first states what the tool does and its scope; the second clarifies access limitations. No filler or redundancy, and the key details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, 100% schema coverage, a full set of annotations, and an output schema present, the description covers the essential call-time knowledge. It does not need to explain return values or parameter syntax further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the id parameter with examples, so the baseline is 3. The description adds a small amount of value by reinforcing that the identifier is a stable connector identifier and by linking it to the operation's purpose.
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 ('Fetches') and names a defined set of resources (biomarker, panel, document, comparison result) plus the key selection mechanism (stable connector identifier). This clearly separates it from search/list siblings, even if it does not explicitly name specialized getter 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?
The description implies the primary usage — retrieving a single public result when you already have a stable connector identifier — but it does not explicitly say when to prefer a specialized sibling such as get_biomarker or get_lab_package, nor does it list exclusions. The context is clear but routing guidance is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_biomarkerGet biomarker detailsAReturns public educational units and existing content for one exact biomarker slug. Standard and optimal range arrays remain present for compatibility but may be empty without a reviewed public range source. This is not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Biomarker slug such as apolipoprotein-b. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| slug | Yes | |
| unit | No | |
| units | No | |
| causes | No | |
| ranges | Yes | |
| summary | No | |
| category | No | |
| symptoms | No | |
| loincCode | No | |
| loincName | No | |
| publicUrl | Yes | |
| hasContent | No | |
| keyInsights | No | |
| categorySlug | No | |
| significance | No | |
| whatLowMeans | No | |
| whatHighMeans | No | |
| existingContent | Yes | |
| metaDescription | No | |
| applicableGender | No | |
| includedInPanels | No | |
| lastMedicalReview | No | |
| medicalReviewStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, so the description adds useful behavior beyond them: it returns public educational units, existing content only, and warns that range arrays may be empty without a reviewed source. The medical disclaimer is also a meaningful extra behavioral note.
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 concise sentences with no repetition. The primary behavior is front-loaded, followed by the compatibility caveat and the disclaimer, each earning 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 single-parameter read-only tool with an output schema and strong annotations, the description covers the essential call intent, edge-case behavior around empty ranges, and the public-content scope. Nothing critical 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?
Schema coverage is 100% and the slug parameter already has a clear example and length constraints. The description reinforces that the slug must be exact but does not add substantive semantic information 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?
Description states a specific verb and resource: returns educational units and existing content for one exact biomarker slug. The phrase 'exact biomarker slug' clearly differentiates it from plural or search-based 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 implies this is for a single exact slug lookup, and the caveat about public range sources is useful. However, it never explicitly says when to prefer this over search_biomarkers or browse_biomarkers, or what to do if the slug is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_biomarker_categoryGet a biomarker categoryAReturns the biomarkers in one exact public category slug. Unknown slugs produce a stable not-found result, and the educational response excludes diagnosis and private data.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact public category slug, such as heart-cardiovascular or energy-metabolism. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| slug | Yes | |
| priority | No | |
| shortName | No | |
| biomarkers | Yes | |
| description | No | |
| biomarkerCount | No | |
| fullDescription | No |
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 valuable behavioral context beyond annotations: unknown slugs produce a stable not-found result, and the educational response excludes diagnosis and private data. No contradiction with annotations exists.
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. The first sentence states the core purpose and scope, and the second covers important edge-case behavior and content restrictions. 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 single-parameter, read-only lookup with an output schema and strong annotations, the description covers the key operational behaviors: exact slug matching, unknown-slug handling, and response-level privacy exclusions. It falls just short of full completeness by not providing any guidance on when to prefer this tool over sibling lookup/search 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 input schema fully documents the slug parameter with meaning, length constraints, and example values, so the description does not need to add much. The description reinforces that the slug must be an exact public category slug and mentions unknown-slug behavior, which is helpful but does not significantly extend the schema's semantic coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns biomarkers for one exact public category slug, using a specific verb and resource. It is easily distinguished from sibling tools like list_biomarker_categories (which returns categories) and get_biomarker/get_biomarkers (which deal with individual or multiple biomarkers).
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 does not say when to use this tool versus alternatives such as list_biomarker_categories or search_biomarkers. The phrasing 'exact public category slug' implies the caller should already know the slug, but no explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_biomarkersCompare exact biomarkersAResolves known public biomarker slugs in request order for factual comparison and reports missing slugs without substitution. Private lab results are outside this tool’s data boundary.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | One to 20 exact public biomarker slugs. |
| Name | Required | Description |
|---|---|---|
| biomarkers | Yes | |
| foundCount | Yes | |
| missingSlugs | Yes | |
| requestedCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description discloses request-order preservation, missing-slug reporting without substitution, and the data boundary on private lab results. These are meaningful behavioral details that affect how an agent interprets results.
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 redundancy; the core resolution and comparison behavior is front-loaded, and the boundary condition is stated efficiently.
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 single well-documented parameter, output schema, and safety annotations, the description provides sufficient behavioral and boundary context. The only minor gap is not naming sibling alternatives, but the exact-slug wording is enough to route an agent 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 already documents the slugs parameter well with 100% coverage. The description adds value by specifying that slugs are resolved in request order and that missing slugs are reported rather than substituted, which clarifies expected behavior beyond 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?
Description clearly identifies a specific action: resolving exact public biomarker slugs for factual comparison. It differentiates from search/browse tools by emphasizing exact slugs, request order, and reporting missing slugs without substitution.
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?
Description provides clear context for when to use this tool: known public biomarker slugs needing exact comparison. It also gives a when-not boundary by excluding private lab results, though it doesn't explicitly name alternative sibling tools like search_biomarkers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lab_catalog_itemGet an orderable catalog itemARevalidates one exact public catalog handle for current price and orderability under the website checkout policy. It never fuzzy-substitutes and returns a safe not-found result for ineligible items.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | Exact public catalog handle. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| price | Yes | |
| handle | Yes | |
| category | Yes | |
| itemType | Yes | |
| discovery | Yes | |
| orderable | Yes | |
| publicUrl | Yes | |
| description | Yes | |
| specimenType | Yes | |
| biomarkerCount | Yes | |
| turnaroundDays | Yes | |
| fastingRequired | Yes | |
| availabilityNote | Yes | |
| humanCheckoutUrl | Yes | |
| selectionSummary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond those hints: it revalidates current price/orderability, never performs fuzzy substitution, and returns a 'safe not-found result for ineligible items.' This clarifies error/eligibility behavior that annotations do not 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 core action and scope ('Revalidates one exact public catalog handle'), then adds the important behavioral qualifiers about fuzzy substitution and not-found handling. Every sentence contributes useful 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?
This is a simple single-parameter, read-only lookup tool with an output schema and strong annotations. The description covers the key semantics: exact handle, current price/orderability, checkout-policy context, no fuzzy matching, and safe not-found behavior. Nothing essential for calling it correctly 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?
The schema already documents the only parameter as 'Exact public catalog handle,' so schema description coverage is 100%. The description reinforces the exactness with 'one exact public catalog handle' and 'never fuzzy-substitutes,' but it does not add substantial new parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it 'revalidates one exact public catalog handle' and checks 'current price and orderability.' It also clearly distinguishes itself from fuzzy lookup tools by saying it 'never fuzzy-substitutes,' which separates it from siblings like search_lab_catalog.
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 usage context: use this tool when you have one exact public catalog handle and need a fresh price/orderability check under checkout policy. It does not explicitly name sibling alternatives or provide a 'when not to use' list, but the exact-handle and no-fuzzy-substitution language effectively excludes fuzzy-search use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lab_packageGet a Vitals Vault panelAResolves the exact Essential, Advanced, or Max legacy package slug to its current public panel price, biomarker count, features, and human URL. The tool never creates an order.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Package slug: essential, advanced, or max. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| slug | Yes | |
| title | Yes | |
| aLaCarte | Yes | |
| features | Yes | |
| priceUsd | Yes | |
| description | Yes | |
| checkoutPath | Yes | |
| biomarkerCount | Yes | |
| biomarkerCountLabel | Yes | |
| biomarkerCountIsMinimum | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds a valuable behavioral guarantee — 'The tool never creates an order' — ruling out a plausible side effect. There is no contradiction with 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?
Two sentences with no wasted words. The first sentence states the resolution behavior and the output contract; the second sentence removes any concern about side effects. The most important safety information is front-loaded at the end of a very short definition.
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 and safety-related annotations covering side effects, the description provides everything needed for a single-parameter lookup: the accepted slugs, what it returns, and the guarantee that no order is created. Nothing important 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?
The input schema is fully self-descriptive: the single slug parameter has an enum of the three allowed values and its own description. The description adds only the nuance that these are legacy package slugs, which is useful but does not significantly raise parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("Resolves") and names a concrete resource: a legacy package slug from the Essential/Advanced/Max set. It also lists the exact outputs — current public panel price, biomarker count, features, and human URL — which clearly distinguishes it from sibling listing and catalog tools even though it does not name them.
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 usage context clear: when you have an exact legacy package slug and need its current public panel details. It does not explicitly name alternatives or conditions to avoid this tool, so it misses the top score, but the intended use is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_page_as_markdownRead a public Vitals Vault pageAReturns a markdown representation of an allowlisted public Vitals Vault page under the protected-route policy. Checkout, account, result, and other private pages are unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Site path beginning with / such as /developers or /biomarkers. |
| Name | Required | Description |
|---|---|---|
| path | Yes | |
| markdown | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, and destructiveHint safety. The description adds meaningful context beyond annotations by clarifying the allowlisted-public scope and protected-route policy, as well as listing unavailable page types. This helps the agent set expectations about access constraints without being verbose.
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 behavior. Every clause earns its place: the resource, the markdown output, the allowlisting constraint, and the private-page exclusion. There is no redundant or filler wording.
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 a single parameter, a fully documented schema, rich annotations, and an output schema present, the description covers everything essential for correct invocation. It communicates the main usage constraint and the key limitation, so an agent can confidently decide whether and how to call 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?
The schema already fully documents the single path parameter with format and examples, giving a strong baseline. The description adds value by indicating that the path must correspond to an allowlisted public Vault page and that private pages are not valid targets, which is semantic information not present in 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 verb and resource: 'Returns a markdown representation of an allowlisted public Vitals Vault page.' It further distinguishes itself by explicitly excluding checkout, account, result, and other private pages. This makes the tool's purpose immediately clear and unique among 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 provides clear context about when to use this tool: for allowlisted public Vitals Vault pages under the protected-route policy. It also gives an explicit when-not by stating private pages like checkout, account, and result are unavailable. However, it does not name alternative sibling tools or describe when those should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_biomarker_categoriesBrowse biomarker categoriesAReturns public educational biomarker category slugs and marker counts for collection browsing. The content excludes diagnosis, private lab results, and other protected data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| categories | Yes | |
| totalCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds meaningful context by specifying that content is public and educational, and by explicitly excluding diagnosis, private lab results, and other protected data, which is important for data-sensitivity expectations.
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 short sentences with no filler. The core return value is front-loaded in the first sentence, and the access scope is clarified in the second sentence, making every word earn 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?
This is a simple, parameterless, read-only listing tool with a rich set of annotations and an output schema. The description tells the agent exactly what is returned and what is excluded, leaving no important gaps for invocation or interpretation.
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 fully documented, so parameter semantics are essentially trivially satisfied. The baseline for zero-parameter tools is 4, and the description adds nothing contradictory or misleading.
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 'public educational biomarker category slugs and marker counts' for collection browsing, specifying both the resource and the output shape. It also distinguishes itself by noting exclusion of protected data, which separates it from broader biomarker lookup 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 phrase 'for collection browsing' implies the intended use case, but the description does not explicitly say when to use this tool versus get_biomarker_category, browse_biomarkers, or search_biomarkers. No alternative tools or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_lab_packagesCompare Essential, Advanced, and MaxACompares Essential, Advanced, and Max using current public prices, biomarker counts, included reporting value, and individual-test availability. The tool never creates a cart.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| aLaCarte | Yes | |
| packages | Yes | |
| proofLoop | Yes | |
| includedPlatform | Yes |
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, and the description adds a meaningful specific guarantee: it never creates a cart. It also discloses what data sources it uses (current public prices, biomarker counts, reporting value, individual-test availability), giving the agent extra confidence beyond the structured hints.
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 short sentences, front-loads the core action, and every clause adds information. It avoids restating annotation fields verbatim, and the safety note is a worthwhile addition.
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 read-only comparison tool with an output schema and strong annotations, the description covers the important use context and safety posture. It is slightly incomplete only in not distinguishing its scope from the similarly named compare_blood_testing_services sibling.
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 is 4; there is no schema gap to compensate. The description appropriately clarifies what the fixed comparison will include, which is sufficient for a no-input 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?
The description clearly identifies a specific action ('Compares'), the exact package set (Essential, Advanced, and Max), and the comparison dimensions (prices, biomarker counts, reporting value, availability). It does not explicitly contrast itself with the similar sibling compare_blood_testing_services, which prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to select this tool over siblings such as compare_blood_testing_services or get_lab_package. The only usage-related statement is a negative safety note ('never creates a cart'), which does not help choose between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_panelRecommend a Vitals Vault panelAReturns a controlled educational Essential, Advanced, Max, or exact-budget Build Your Own Panel starting point. A custom_only request with maxBudgetUsd excludes standard panels. Every selection is revalidated against the complete eligible catalog. Inputs exclude free-text symptoms, identity, private results, and PHI; the tool never diagnoses, stores a health record, or creates a cart.
| Name | Required | Description | Default |
|---|---|---|---|
| sex | No | Optional controlled biological-sex context for public catalog applicability; not_specified represents an omitted value. | |
| goal | Yes | What the person is trying to accomplish. | |
| budget | No | Legacy package price bucket. Exact hard ceilings are represented by maxBudgetUsd. | |
| ageBand | No | Reserved broad age-band context that is not currently used to select tests. Birth dates and exact ages are outside the input contract; the value is not persisted or logged. | |
| concern | Yes | Controlled high-level concern; urgent_symptoms returns a safety-suppressed response. | |
| maxBudgetUsd | No | Exact hard ceiling in US dollars. Required when packagePreference is custom_only; the returned total never exceeds it. | |
| biomarkerSlugs | No | Optional exact public slugs for find_specific_test or retest goals. | |
| packagePreference | No | allow_packages compares the standard panels; custom_only excludes Essential, Advanced, and Max and builds only from checkout-eligible BYOP items. |
| Name | Required | Description |
|---|---|---|
| reason | No | |
| rationale | No | |
| disposition | Yes | |
| inputPolicy | No | |
| medicalBoundary | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, and the description adds meaningful behavioral context: it is educational, never diagnoses, does not store a health record, does not create a cart, excludes PHI/free-text symptoms, and revalidates selections against the catalog. There is no contradiction with 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?
Four sentences, each earning its place: what is returned, the custom_only exception, the revalidation guarantee, and the safety boundary. The most important behavioral information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complete input schema (100% parameter coverage), an output schema present, and annotations covering readOnly/idempotent behavior, the description adds the one missing layer: safety constraints, catalog revalidation, and the educational non-clinical stance. Nothing needed to invoke the tool correctly 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%, so the baseline is 3. The description earns one extra point by clarifying the cross-parameter relationship between custom_only and maxBudgetUsd ('A custom_only request with maxBudgetUsd excludes standard panels') and by bounding the semantic scope of concern/inputs with the PHI and free-text exclusion.
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 action ('Returns') and a concrete resource ('a controlled educational Essential, Advanced, Max, or exact-budget Build Your Own Panel starting point'), which is far more informative than the title and clearly separates this from catalog-listing siblings. Phrases like 'educational' and 'never diagnoses' reinforce that this is a recommendation function, not a clinical or ordering 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 when to call it by positioning it as a recommender and by explaining the custom_only/maxBudgetUsd behavior. However, it never names an alternative such as start_guided_panel_builder or search_lab_catalog, so an agent gets no explicit when-to-use versus when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch Vitals VaultAProvides broad connector discovery across public Vitals Vault biomarkers, panels, developer documentation, and comparisons. Results contain stable identifiers for exact public retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search text such as ApoB, OAuth, Advanced, or Function Health. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds useful behavioral context beyond annotations: it clarifies that search covers only public content and that results contain stable identifiers intended for exact public retrieval, which helps the agent understand how to use the output.
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 concise sentences with no redundant wording. It front-loads the tool's broad purpose and then adds a valuable note about stable identifiers, making every sentence purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only search tool with a rich output schema and annotations, the description is largely complete. It conveys scope, public availability, and the nature of returned identifiers. It could marginally improve by mentioning pagination or result limits, but these are not essential 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?
The input schema already describes the single 'query' parameter with examples and constraints, so the schema carries the full parameter burden. The description does not add additional parameter-level semantics, so a baseline score of 3 is appropriate given the 100% schema description coverage.
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 ('broad connector discovery') and resource scope ('public Vitals Vault biomarkers, panels, developer documentation, and comparisons'). It clearly conveys what the tool searches across, though it does not explicitly differentiate itself from sibling search tools like search_biomarkers or search_lab_catalog.
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 'broad connector discovery' implies this is the general-purpose search across multiple Vitals Vault content types, which gives some guidance on when to use it. However, it does not explicitly state when to prefer this over the more targeted sibling search tools, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_biomarkersSearch biomarkersASearches public educational biomarkers by name, alias, LOINC, or keyword and explains Vitals Vault coverage. Private lab results are outside this tool’s data boundary.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return (default 10, max 25). | |
| query | Yes | Search text such as ApoB or vitamin D. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes | |
| totalCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral context beyond annotations: the tool searches only public educational data, explains Vitals Vault coverage, and explicitly excludes private lab results.
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, front-loaded with the core action and resource, with no filler. The scope exclusion is stated efficiently and meaningfully.
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 full schema coverage, annotations, and an output schema, the description is complete. It covers what input is used, what kind of data is returned, and what is expressly out of scope.
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 parameters are already documented. The description adds value by specifying the search dimensions (name, alias, LOINC, keyword) and clarifying the data boundary, which enriches the meaning of the query parameter.
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 public educational biomarkers by name, alias, LOINC, or keyword. It also clarifies scope by noting that private lab results are outside the tool's data boundary, which helps distinguish it from other search/browse 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?
Provides clear usage context by listing accepted search inputs and explicitly excluding private lab results. It does not name sibling alternatives or give explicit when-to-use vs. when-not-to-use guidance, but the scope statement is enough to guide selection in most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_lab_catalogSearch orderable tests and panelsASearches currently orderable Vitals Vault tests and panels with customer-safe prices and stable pagination. Results come from a versioned public search document with match provenance and are revalidated against website checkout eligibility. Identity, account data, private results, and PHI are outside the input contract.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | One-based public catalog page; defaults to 1. | |
| limit | No | Maximum results per page; defaults to 20. | |
| query | No | Optional customer-facing test or panel name, such as ApoB or thyroid. | |
| gender | No | Public catalog applicability filter; defaults to all. | |
| category | No | Optional public checkout category slug. | |
| itemType | No | Catalog item filter for panels, individual tests, or both; defaults to all. |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| query | Yes | |
| source | Yes | |
| filters | Yes | |
| pagination | Yes | |
| humanCheckoutOnly | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/destructive annotations, the description discloses meaningful behavior: results come from a versioned public search document, include match provenance, are revalidated against website checkout eligibility, and use stable pagination. It also clarifies the closed-world scope and what kind of data is excluded. This adds substantial 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?
Three tightly written sentences: the first states the core action and key guarantees, the second explains the data source and revalidation behavior, and the third clarifies exclusions. There is no filler, and the most important info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent public catalog search with an output schema and fully documented optional parameters, the description covers purpose, scope, data provenance, pricing, pagination stability, and privacy boundaries. Nothing essential for an agent to decide whether and how to call this tool 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?
The input schema already documents all six parameters with descriptions, defaults, and constraints at 100% coverage. The description adds general context about stable pagination and public catalog scope but does not add parameter-specific semantics beyond what the schema provides. A baseline of 3 is appropriate 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 opens with a specific verb and resource: 'Searches currently orderable Vitals Vault tests and panels.' It also distinguishes this from sibling search tools by emphasizing 'customer-safe prices,' 'public search document,' and ordering/checkout eligibility, which clearly mark it as the public catalog 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 gives clear context for when to use the tool: for currently orderable public catalog items, not personal or account-specific data. It explicitly excludes identity, account data, private results, and PHI from the input contract. It stops short of naming an alternative sibling tool or an explicit 'use X instead' guideline, 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.
start_guided_panel_builderOpen the guided panel builderAReturns the canonical entry for the full human-controlled Vitals Vault consultation, with no health answers in the URL. It creates no session, cart, account, order, or payment.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| disposition | Yes | |
| medicalBoundary | No | |
| humanCheckoutUrl | No | |
| humanCheckoutOnly | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the bar is lower. The description adds value beyond those flags by enumerating the specific side effects that do NOT occur — no session, cart, account, order, or payment creation — and by disclosing the privacy property of the returned URL. This disambiguates what 'starting a consultation' does not do.
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, both earning their place: the first states the core function with the key privacy attribute front-loaded, the second preempts concerns about side effects. Zero 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 zero-parameter, tool with a presence of an output schema and rich annotations, the description covers the essential ground: what it returns, the privacy-relevant trait of the URL, and the complete absence of side effects. Nothing an agent needs to safely invoke it 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?
With zero parameters, schema coverage is trivially 100% and the baseline is 4. The description's note that the entry contains 'no health answers in the URL' reinforces that no query/parameter data is needed and none carries sensitive information, which is meaningful context for an agent deciding whether parameterization is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action — 'Returns the canonical entry' — for a defined resource: the human-controlled Vitals Vault consultation flow. The 'human-controlled' qualifier implicitly distinguishes it from automated siblings like recommend_panel. However, 'canonical entry' is somewhat vague jargon (it never says 'URL' or 'link'), which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied but never explicit. 'Full human-controlled' suggests this is the tool to use when a human guides the consultation, in contrast to automated flows, and 'no health answers in the URL' implies a privacy-conscious alternative to tools that embed such data. But no sibling tool is named and there is no explicit when-to-use versus when-not-to-use guidance.
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!
Supplement research, biomarker effects, drug interactions, and brand quality data
Doctor-reviewed blood-test markers, conditions & symptoms as agent tools. EN/RU/HE. Hosted.
Read-only U.S. lab-test catalog, collection-site search, and reference-range context.
Guideline-cited biomarker analysis for chronic conditions (diabetes, lupus, cancer). Synthetic.
