Evidence-based supplement research for AI assistants. Query 4,794 clinical effect edges across 290 supplements and 502 biomarkers, 765 supplement-supplement interactions, 1,634 FDA drug interactions, and 22,570 product quality scores with AviScore ratings. 8 tools: supplement and biomarker lookup, drug and supplement interactions, brand quality rankings, condition-based supplement recommendations, fuzzy search for supplements and health conditions.
Find which biomarkers are affected by a given supplement. Returns direction (up/down), confidence, dose, and health goal mapping.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 25, max 100) | |
| supplement | Yes | Supplement name (e.g., 'fish oil', 'curcumin', 'vitamin D3') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return content (direction, confidence, dose, health goal mapping), which clarifies expected behavior. However, it does not mention behaviors like what happens if the supplement is unknown or whether results are ordered.
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, compact sentence that conveys purpose and return fields without any filler. Every word contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema. The description covers the return fields (direction, confidence, dose, health goal mapping), which is sufficient for basic use. It lacks edge-case details, but for a lookup tool this is not a critical gap.
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%: both 'supplement' and 'limit' are documented with types, defaults, and constraints. The description adds no parameter-specific semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Find which biomarkers are affected by a given supplement.' It uses a specific verb ('find') and a specific resource ('biomarkers affected by a given supplement'). It differentiates from siblings like get_supplements_for_biomarker (reverse direction) and get_supplement_interactions.
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 context: use this tool when you have a supplement and want to know which biomarkers it affects. However, it does not explicitly state when to use it over siblings, nor does it mention the reverse tool get_supplements_for_biomarker or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find mixed interventions in Aviado's current graph that affect a biomarker, labeled with the exact intervention_type value supplement, food_substance, prescription_drug, research_compound, research_nootropic, medical_compound, or unknown. graph_status is the exact internal proven/suspected eligibility label, not independent clinical validation. Coverage is partial and non-exhaustive; absence is not evidence of no effect. pathway_tags are raw graph metadata, not validated mechanisms, and dose/pathway details are suppressed for non-supplement and unknown rows. Use dose_value with dose_unit; legacy dose_mg is populated only for literal mg rows.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 25, max 100) | |
| biomarker | Yes | Biomarker name, abbreviation, or LOINC code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses critical behavioral traits: graph_status is an internal label, not clinical validation; coverage is partial and absence is not evidence; pathway_tags are raw metadata; dose/pathway details are suppressed for certain rows; and legacy dose_mg usage is clarified. This is exemplary transparency.
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 dense yet every sentence earns its place: purpose first, then provenance caveats, coverage limitations, pathway_tags caveat, and dose field usage. No fluff, front-loaded, and verbose only where necessary.
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 no output schema and no annotations, the description compensates by explaining key output field semantics and limitations. It could be more explicit about the overall return structure (e.g., a list of intervention objects), but it covers the most important caveats thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both biomarker and limit documented in the schema. The description adds context about output fields (dose_value, dose_unit, dose_mg) but does not elaborate on parameter input semantics beyond what the schema already provides. 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 opens with 'Find mixed interventions in Aviado's current graph that affect a biomarker,' a specific verb+resource statement that clearly distinguishes it from sibling supplement-focused tools. It goes further by enumerating the exact intervention_type values, reinforcing the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this when you need a biomarker's interventions across multiple types (e.g., supplement, drug, compound). However, it does not explicitly state when not to use it or mention sibling alternatives like get_supplements_for_biomarker. The 'mixed' wording implies broader coverage, but alternatives are not named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive information about a supplement: what it is, what it does, which biomarkers it affects, mechanism of action, and safety contraindications.
| Name | Required | Description | Default |
|---|---|---|---|
| supplement | Yes | Supplement name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It lists what information is returned but does not mention read-only nature, required naming conventions, error handling, or any potential side effects, leaving important behavioral traits undisclosed.
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, well-structured sentence that front-loads the action and concisely enumerates the content areas. Every phrase earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup tool with no output schema, the description covers the key aspects of the returned information. It does not explain behavior for missing supplements or exact-name requirements, but these are minor given the tool's simplicity and clear 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 coverage is 100% with 'Supplement name', and the description does not add beyond that. The baseline of 3 applies because the schema already fully documents the parameter, and the description provides no additional semantic nuance like common vs. scientific name.
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 'Get' and clearly lists the scope of information: what it is, what it does, biomarkers, mechanism, and safety contraindications. This distinguishes it from sibling tools like get_biomarkers_for_supplement or get_supplement_interactions, which target narrower aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a comprehensive overview, but it does not explicitly state when to use this tool over specialized siblings. There is no 'when-not' guidance or named alternatives, leaving the agent to infer the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find supplement-supplement interactions (765 pairs from clinical evidence) and drug-supplement interactions (1,626 FDA-validated pairs). Returns synergies, antagonisms, absorption conflicts, and timing recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| supplement | Yes | Supplement name | |
| include_drug_interactions | No | Include FDA drug-supplement interactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It meaningfully discloses what the tool returns (synergies, antagonisms, absorption conflicts, timing recommendations) and the evidence sources (clinical evidence, FDA-validated). However, it does not detail return format, pagination, or failure modes, which are gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every clause adds useful information (sources, counts, output categories). There is no repetitive or verbose content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no output schema, and no annotations, the description provides enough context: it states the scope, data sources, and high-level result categories. It falls short only in not describing exact response structure or potential limitations, but for a lookup tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already fully describes both parameters ('supplement' and 'include_drug_interactions'). The description adds no additional parameter-level detail, so it neither improves nor harms parameter understanding.
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 'Find' and clearly identifies two distinct resources: supplement-supplement interactions and drug-supplement interactions. It distinguishes itself from sibling tools like get_supplement_info and get_biomarkers_for_supplement by specifying interaction types and quantified data sources.
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 used when interaction data is needed, but it does not explicitly state when to choose it over siblings or provide exclusion criteria. There is no mention of alternatives such as get_supplement_info, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find registry-classified supplements in Aviado's current graph that affect a biomarker. Excludes food_substance, prescription_drug, research_compound, research_nootropic, medical_compound, and unknown IDs. Type labels and graph_status (proven or suspected) are internal taxonomy/eligibility metadata, not independent clinical verification. Results are partial and non-exhaustive; pathway_tags are raw graph metadata, not validated mechanisms. Use dose_value with dose_unit; legacy dose_mg is populated only for literal mg rows.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 25, max 100) | |
| biomarker | Yes | Biomarker name, abbreviation, or LOINC code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It thoroughly details limitations (partial, non-exhaustive), metadata semantics (internal taxonomy, not clinical verification), and data usage caveats (pathway_tags raw, dose_mg legacy). This goes well beyond a basic functional statement.
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 dense but every sentence provides essential context for correct use, including exclusions, metadata caveats, and data handling notes. It is structured with front-loaded purpose and subsequent caveats, making it highly informative without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is remarkably complete: it explains what the tool returns (partial supplement lists), what fields mean (type labels, graph_status, pathway_tags, dose fields), and important limitations. This is sufficient for an agent to set expectations and avoid misuse.
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 covers both parameters with full descriptions (100% coverage), so the baseline is 3. The description adds no input parameter semantics beyond the schema; its mention of dose_value/dose_unit relates to output fields, not input 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?
The description clearly states the tool's purpose: find supplements affecting a biomarker, with specific scope (registry-classified in Aviado's graph) and explicit exclusions. This distinguishes it from siblings like get_biomarkers_for_supplement (inverse) and get_interventions_for_biomarker (broader).
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 when you need supplements for a biomarker and specifies exclusions, but it does not explicitly mention alternatives or when-not-to-use conditions. No direct comparison with sibling tools is provided, leaving the agent to infer the tool's role from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find which supplements help with a health condition or goal (e.g., 'sleep', 'anxiety', 'joint pain'). Returns evidence-graded supplement recommendations with dosages.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max supplements to return, ranked by evidence (default: 25, max: 50) | |
| condition | Yes | Health condition, symptom, or goal (e.g., 'insomnia', 'anxiety', 'brain fog', 'joint pain') | |
| min_grade | No | Minimum evidence grade to include (default: D = all) | D |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that results are evidence-graded and include dosages, which are key behavioral traits. However, it does not mention ordering details, potential lack of results, or any limitations beyond what is in the parameter schemas.
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 tool's purpose and provides a concise output summary, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple retrieval query with fully self-describing parameters and a clear return type (evidence-graded recommendations with dosages). No output schema exists, but the description covers the key output semantics. It could be slightly enhanced by explaining the evidence grading scale or explicitly distinguishing from the biomarker sibling, but it is generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all parameters, including defaults and allowed values. The tool description adds minimal parameter meaning beyond examples that already appear in the condition parameter description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds supplements for a health condition or goal, with specific examples like 'sleep' and 'joint pain'. This distinguishes it from siblings such as get_supplements_for_biomarker, which target biomarkers instead.
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 establishes a clear context for use (when you have a health condition or goal) and mentions the evidence-graded output, but it does not explicitly name alternative tools or state when not to use it. It implies usage rather than providing exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the highest-quality brands for a supplement, ranked by ProofMark (Aviado's quality score: third-party testing, certifications, and quality metrics).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results (max 20) | |
| supplement | Yes | Supplement name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It explains the ranking methodology (ProofMark: third-party testing, certifications, quality metrics), which adds useful context. However, it does not disclose return format, edge cases (e.g., empty results), or any potential limitations, leaving some gaps for a tool without an output 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?
The description is a single, well-structured sentence that front-loads the tool's purpose and key ranking criterion. It contains no redundant words or filler, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with well-documented parameters, the description covers the essential purpose and ranking rationale. It does not describe the return structure, but given the tool's simplicity and the absence of an output schema, the description is largely complete. A brief mention of output format would push it to 5.
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 provides 100% coverage with descriptions for both parameters: 'supplement' as 'Supplement name' and 'limit' as 'Number of results (max 20)'. The description adds no additional meaning or syntax details beyond what the schema already documents, so it meets the baseline for schema-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?
The description clearly states the tool's function: 'Find the highest-quality brands for a supplement'. The specific verb 'Find' and resource 'brands for a supplement' distinguish it from sibling tools like get_supplement_info or get_supplements_for_condition. The ranking metric (ProofMark) is explicitly explained.
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 use this tool: when you need top-ranked brands for a specific supplement. It does not explicitly name alternatives or exclusions, but the context from sibling tool names (e.g., get_supplements_for_condition, get_biomarkers_for_supplement) helps clarify its specific niche.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a health condition by name with fuzzy matching. Use this to resolve ambiguous condition names before calling get_supplements_for_condition.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g., 'sleep', 'anxiety', 'brain fog', 'joint pain') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that the tool uses fuzzy matching and is meant for disambiguation, but it does not mention result format, error behavior, or whether the operation is read-only. This is adequate for a simple search tool, but additional behavioral details would improve transparency.
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 concise and front-loaded. The first sentence states the action, the second provides contextual usage. Every sentence adds value with no 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 tool with one parameter and no output schema, the description is mostly complete but lacks explicit information about return values. It says it searches and resolves ambiguity, but does not state what the agent will receive, which is a notable gap given there is no output schema.
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% as the query parameter has a description with examples. The tool description does not add further semantics beyond 'by name,' but given full schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search for a health condition by name with fuzzy matching.' It also distinguishes from siblings by explicitly mentioning the intended use case of resolving ambiguous condition names before calling get_supplements_for_condition, providing a specific verb and resource.
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 explicit usage guidance: 'Use this to resolve ambiguous condition names before calling get_supplements_for_condition.' This clearly tells the agent when to use this tool and names a specific sibling as the follow-up, effectively distinguishing it from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a supplement identity. Use mode='supplement_retail' only for raw retail product titles; it invokes the fail-closed retail front door. Identity mode is the default.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Explicit routing mode; retail titles require supplement_retail | identity |
| query | Yes | Supplement identity or raw retail product title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It adds value by mentioning that the retail mode is 'fail-closed' and that identity mode is the default. However, it does not disclose return format, error handling, or whether the operation is read-only. This is enough for a basic understanding but lacks comprehensive behavioral detail.
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 exceptionally concise: two sentences, front-loaded with the primary purpose. Every sentence contributes meaningful information—the core function, the mode-specific usage, and the default behavior. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description covers the main usage and mode selection. However, because there is no output schema, the description does not help the agent understand what the tool returns (e.g., a list, an ID, or an entity). It also lacks guidance on when to prefer this tool over sibling tools. While it is adequate for invocation, it leaves gaps in the agent's full understanding.
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 provides 100% coverage for both parameters, including descriptions for 'query' and 'mode'. The description complements this by explaining the purpose of the 'supplement_retail' mode and reinforcing the default. It adds contextual meaning to the 'mode' parameter beyond the schema's enum description, which is helpful for correct invocation.
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 purpose: 'Resolve a supplement identity.' It specifies a particular action ('resolve') on a resource ('supplement identity'). It also differentiates between identity mode and supplement_retail mode, which helps distinguish it from other supplement-related tools, though it does not explicitly name sibling 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 gives explicit guidance on when to use the 'supplement_retail' mode: only for raw retail product titles, and notes that it 'invokes the fail-closed retail front door.' It also states that identity mode is the default, implying typical usage. It does not mention when to use this tool over sibling tools, but the mode-specific instructions are clear and actionable.
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. Dates show when Glama detected each change.
search_supplements2 fields changedInput schema / properties / modeAdded value: +{
+ "default": "identity",
+ "description": "Explicit routing mode; retail titles require supplement_retail",
+ "enum": [
+ "identity",
+ "supplement_retail"
+ ],
+ "type": "string"
+}Input schema / properties / query / descriptionPrevious value: -"Search query (e.g., 'fish oil', 'CoQ10', 'NAC')"New value: +"Supplement identity or raw retail product title"get_biomarkers_for_supplement2 fields changedInput schema / properties / supplement / maxLengthAdded value: +512Input schema / properties / supplement / minLengthAdded value: +1get_interventions_for_biomarkerget_supplement_info2 fields changedInput schema / properties / supplement / maxLengthAdded value: +512Input schema / properties / supplement / minLengthAdded value: +1get_supplement_interactions2 fields changedInput schema / properties / supplement / maxLengthAdded value: +512Input schema / properties / supplement / minLengthAdded value: +1get_supplements_for_biomarker2 fields changedInput schema / properties / biomarker / maxLengthAdded value: +512Input schema / properties / biomarker / minLengthAdded value: +1get_supplements_for_condition2 fields changedInput schema / properties / condition / maxLengthAdded value: +512Input schema / properties / condition / minLengthAdded value: +1get_top_brands2 fields changedInput schema / properties / supplement / maxLengthAdded value: +512Input schema / properties / supplement / minLengthAdded value: +1search_conditions2 fields changedInput schema / properties / query / maxLengthAdded value: +512Input schema / properties / query / minLengthAdded value: +1search_supplements2 fields changedInput schema / properties / query / maxLengthAdded value: +512Input schema / properties / query / minLengthAdded value: +1get_biomarkers_for_supplement1 field changedInput schema / properties / limitAdded value: +{
+ "default": 25,
+ "description": "Max results (default 25, max 100)",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}get_supplements_for_biomarker1 field changedInput schema / properties / limitAdded value: +{
+ "default": 25,
+ "description": "Max results (default 25, max 100)",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}get_supplements_for_condition3 fields changedInput schema / properties / limit / maximumAdded value: +50Input schema / properties / limit / minimumAdded value: +1Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"get_top_brands3 fields changedInput schema / properties / limit / maximumAdded value: +20Input schema / properties / limit / minimumAdded value: +1Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"get_supplements_for_condition1 field changedInput schema / properties / limitAdded value: +{
+ "default": 25,
+ "description": "Max supplements to return, ranked by evidence (default: 25, max: 50)",
+ "type": "number"
+}get_supplements_for_conditionsearch_conditionsget_biomarkers_for_supplementget_supplement_infoget_supplement_interactionsget_supplements_for_biomarkerget_top_brandssearch_supplementsClaiming 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, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
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!
Add one secure layer between your agents and this server.
Most tools target distinct resource-action pairs, but get_supplements_for_biomarker and get_interventions_for_biomarker overlap in purpose (both return things affecting a biomarker), with the key difference being intervention type filtering. This could cause misselection if the agent does not read descriptions carefully.
All tools follow a consistent verb_noun pattern using snake_case (get_* and search_*). Naming is predictable and clearly groups resource types, with no mixed conventions or vague verbs.
With 9 tools, the set is well-scoped for a supplement and biomarker information server. Each tool addresses a distinct functional need without redundancy, falling comfortably in the ideal 3-15 range.
The tool surface covers the primary workflow: searching supplements/conditions, retrieving supplement details and biomarkers, finding supplements/interventions for biomarkers, checking interactions, and getting brand quality data. Minor gaps exist, such as no direct biomarker search or tool to get conditions for a supplement, but core use cases are covered.