Clarity by Health AI
Server Details
Ingredient, supplement & food safety for agents: verdicts, recall checks, interactions, safer swaps
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- thehealthai/clarity-mcp
- GitHub Stars
- 0
- Server Listing
- Clarity MCP
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 9 of 9 tools scored. Lowest: 3.5/5.
Each tool has a clearly distinct purpose: ingredient lookup, interaction checking, recalls, stack audit, alternatives, barcode scanning, product scoring, strain lookup, and claim validation. No overlap or ambiguity.
All tool names follow a verb_noun pattern (e.g., check_ingredient, find_alternatives, scan_barcode), with consistent use of underscores and active verbs.
9 tools is well-scoped for the domain of product safety and ingredient analysis, covering key functionalities without being excessive or insufficient.
The tool set covers all major use cases: single ingredient checks, interactions, recalls, stack audits, alternatives, barcode scanning, product scoring, strain lookup, and claim validation, leaving no obvious gaps.
Available Tools
9 toolscheck_ingredientAInspect
Look up a cosmetic/food/supplement ingredient in Clarity's condition-aware database. Returns verdict, evidence tier (Gold/Silver/Bronze), and citation for a given condition lens. Pass lenses (array) instead of lens to check several conditions in ONE call (profile-shaped checking, e.g. a user who is pregnant AND has MCAS) — results then carry a per-lens breakdown under lenses{}. Every result includes human_url, a live Clarity page to hand the user as the source link.
| Name | Required | Description | Default |
|---|---|---|---|
| lens | No | Single condition lens | all |
| name | Yes | Ingredient name, e.g. 'niacinamide' or 'aged cheddar cheese' | |
| lenses | No | Multiple condition lenses in one call (max 5); wins over `lens` when provided |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the return values (verdict, evidence tier, citation, human_url) and the behavior for multiple lenses. It covers the key behavioral aspects for a lookup tool, though it omits details like rate limits or authentication requirements.
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 well-structured, front-loading the main purpose, then explaining the two usage modes (single lens vs multiple lenses), and ending with the human_url note. It is concise and avoids 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?
Given no output schema and three parameters, the description covers the essential information: what the tool does, how to use single vs multiple lenses, and what the result contains. It is thorough enough for an agent to invoke 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?
With 100% schema coverage, baseline is 3. The description adds value by explaining that `lenses` overrides `lens`, describing the per-lens breakdown, and highlighting the human_url. It also provides example usage, enriching the schema definitions.
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 looks up an ingredient in a condition-aware database and returns verdict, evidence tier, citation, and human_url. It distinguishes itself from sibling tools by focusing on ingredient checking with condition lenses.
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 explicit guidance on using `lens` vs `lenses` for single or multiple conditions, and mentions the per-lens breakdown. However, it does not explicitly state when to use this tool over alternatives like `check_interaction`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_interactionAInspect
Check Clarity's curated ingredient-to-ingredient interaction database. Give one ingredient to list everything it interacts with (e.g. 'iron'), or two ingredients to check a specific pair (e.g. 'calcium' + 'iron'). Returns interaction_type, severity (Beneficial/Moderate/High), mechanism, clinical_note, source, and whether it affects lactation/infant/absorption. Queries both directions of the pair. Absence of a result is NOT proof of safety — the set is curated and growing. Descriptive with sources, not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| ingredient_a | Yes | The ingredient to check, e.g. 'iron' or 'calcium' | |
| ingredient_b | No | Optional second ingredient to check a specific pair. Omit to list all interactions for ingredient_a. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return fields (interaction_type, severity, etc.), queries both directions, and clarifies it's descriptive and not medical advice. This provides good transparency for a read-only tool.
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 (4 sentences) and front-loaded: first sentence states purpose, second gives usage patterns, third lists output, fourth adds caveats. Every sentence serves a purpose with no waste.
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 no output schema, the description adequately explains return fields and includes important limitations (curated set, not exhaustive, not medical advice). For a 2-param tool without nested objects, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions. The description adds value by providing examples ('iron', 'calcium' + 'iron') and explaining the conditional behavior (list vs pair check), enhancing the schema's clarity.
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 checks Clarity's curated ingredient-to-ingredient interaction database, with specific verb 'check' and resource 'interaction database'. It distinguishes from siblings like check_ingredient by focusing on interactions between ingredients.
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 explicit usage patterns: one ingredient lists all interactions, two ingredients check a specific pair. It also notes a crucial caveat (absence not proof of safety) but does not explicitly contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_recallAInspect
Check whether a consumer product or brand has an FDA/consumer recall on file — supplements, food, cosmetics (NOT medical devices). Query by brand (primary), optionally narrow by product_name. Returns recall_flag, whether any active Class I (most serious) recall exists, and each matching record with classification, reason, date, status, and a source_url to verify. Recall data has no barcode, so matches are brand/name text matches — confirm via source_url. For medical-DEVICE recalls, use the radar MCP (com.healthai/radar).
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Brand or manufacturer name, e.g. 'Nature Made' or 'Similac' | |
| product_name | No | Optional product name to narrow within the brand, e.g. 'infant formula' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully covers behavioral aspects: discloses text-matching limitations (no barcode), advises confirmation via source_url, and lists returned fields including recall_flag and active Class I recall status.
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?
Well-structured and front-loaded with purpose. Slightly verbose in listing return fields, but no redundant sentences. Could be tightened while retaining clarity.
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 no output schema, description sufficiently explains return fields (recall_flag, active Class I, classification, reason, date, status, source_url) and addresses limitations, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters (100% coverage). Description adds meaning: identifies 'brand' as primary, 'product_name' as optional narrowing, and notes text-matching behavior, enhancing the schema description.
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: 'Check whether a consumer product or brand has an FDA/consumer recall on file', specifies applicable categories (supplements, food, cosmetics), and explicitly excludes medical devices, distinguishing it from the radar MCP sibling.
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 guidance: query by brand (primary), optionally narrow by product_name. Mentions alternative for medical devices. Could be more explicit about when to use versus other sibling tools like check_ingredient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_stackAInspect
Audit a supplement/ingredient STACK in one call: per-item condition-lens verdicts (evidence-graded, cited where citations exist) PLUS every curated ingredient-to-ingredient interaction found WITHIN the stack (type, severity, mechanism, source). Use when a user takes multiple supplements together. Supports multi-lens via lenses. Absence of an interaction is NOT proof of safety — the curated set is growing. Every result includes human_url for the user.
| Name | Required | Description | Default |
|---|---|---|---|
| lens | No | Single condition lens | all |
| lenses | No | Multiple condition lenses in one call (max 5); wins over `lens` when provided | |
| ingredients | Yes | 2-12 ingredient/supplement names, e.g. ['iron','calcium','quercetin'] |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it returns evidence-graded verdicts with citations where they exist, and that interactions are curated. It also warns about the incompleteness of safety evidence. It could be more explicit about being read-only, but as an audit tool, that is implied.
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 (4 sentences) and front-loaded with the main purpose. The last sentence about 'human_url' is useful but could be integrated. Overall, efficient and focused.
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 complexity of auditing a stack with multiple lenses and interactions, the description covers the key outputs and caveats. No output schema exists, so the agent relies on this text. It could detail the result format further, but for a 3-parameter tool, it is fairly 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 schema already describes all parameters. The description adds context about multi-lens support via the 'lenses' parameter and gives an example for 'ingredients', but this is incremental. 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 uses a specific verb 'Audit' with the resource 'supplement/ingredient STACK' and clearly lists the outputs: per-item condition-lens verdicts and curated interactions. It distinguishes itself from sibling tools like 'check_ingredient' (single ingredient) and 'check_interaction' (likely a pair).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use when a user takes multiple supplements together.' It also warns that absence of interaction is not proof of safety. However, it does not explicitly mention when not to use it or provide direct alternatives, though sibling names imply those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_alternativesAInspect
Find 2-3 safer swaps for a flagged product: same-category products that rate good/excellent on Clarity's general food/skincare quality score AND contain no ingredient flagged for the given condition lens. Seed by barcode (preferred — e.g. right after scan_barcode flags something) or product_name. Each alternative carries its score, ingredient-recognition coverage, and human_url. The score is a GENERAL quality score, not a condition verdict — verify a chosen alternative with scan_barcode or check_stack. Food and skincare only (supplement swaps are declined honestly for now).
| Name | Required | Description | Default |
|---|---|---|---|
| lens | No | Condition lens for the ingredient screen | all |
| count | No | How many alternatives to return (1-5) | |
| barcode | No | UPC/EAN of the product to swap away from (6-14 digits) | |
| product_name | No | Product name to seed from when no barcode is available |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: returns alternatives with score, coverage, human_url; clarifies the score is a general quality score not a condition verdict; and honestly states supplement swaps are declined. No contradictions.
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 well-structured, front-loading the core purpose and then detailing usage and caveats. It is efficient with no wasted words, though slightly longer than minimal.
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 no output schema, the description adequately explains what each alternative carries (score, coverage, human_url). It also sets expectations about the quality score's role and the tool's domain (food/skincare only). The context from sibling tools is addressed.
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% (all params described), so baseline 3. The description adds extra context: preferred use of barcode over product_name, and explains the purpose of the count parameter (how many alternatives). This adds meaningful value beyond 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 states the verb 'Find' and resource 'safer swaps for a flagged product' with specific constraints: same-category, good/excellent quality score, and no flagged ingredient for the condition lens. It also distinguishes from siblings by mentioning preferred seeding after scan_barcode.
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 explicit guidance: seed by barcode (preferred, e.g., right after scan_barcode) or product_name, and limits to food/skincare. Implies use after scanning a flagged product, and suggests verifying with scan_barcode or check_stack. Lacks explicit when-not-to-use but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_barcodeAInspect
Look up a product by barcode (Open Food Facts / Open Beauty Facts), match its ingredients against Clarity's database, return which ingredients are flagged for the given condition lens, AND flag any active FDA recall for the product (recall_flag + recalls[], sourced from FDA — verify via source_url).
| Name | Required | Description | Default |
|---|---|---|---|
| lens | No | Condition lens | all |
| barcode | Yes | UPC/EAN barcode, 6-14 digits |
Tool Definition Quality
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 data sources (Open Food Facts, Open Beauty Facts, FDA), actions (lookup, match, flag), and that recall info comes from FDA with source_url. It does not mention limitations or side effects but is generally transparent.
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 long sentence that packs a lot of information. It uses capitalization for emphasis (AND, FDA). While clear, it could be split for better readability without losing meaning.
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 no output schema, the description explains key outputs (flagged ingredients, recall_flag, recalls[], source_url). It covers the tool's complexity and differentiates from siblings. The integration of multiple data sources is clearly described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaning beyond the schema by explaining how the 'lens' parameter filters ingredient flags and how 'barcode' is used for the lookups. It ties parameters to the integrated workflow.
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: lookup product by barcode from Open Food Facts/Open Beauty Facts, match ingredients, flag for a given condition lens, and flag FDA recalls. It also differentiates from siblings like check_ingredient and check_recall by combining multiple functions.
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 a barcode is available for comprehensive product analysis. It does not explicitly state when not to use, but the sibling tool names provide context for alternatives (e.g., check_recall for recalls only).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_productAInspect
Get Clarity's product quality score by barcode. Returns category-specific scores (food: nutrition/additive/processing/organic; skincare: irritation/allergen/endocrine/condition; supplement: transparency/safety/label_quality/complexity — dose transparency penalizes proprietary blends, safety flags high-risk botanicals) — these are DISTINCT and never merged — plus per-lens fit with match coverage. Always includes data_quality/coverage so a score is never given without its confidence.
| Name | Required | Description | Default |
|---|---|---|---|
| lens | No | Condition lens for per-lens fit | |
| barcode | Yes | UPC/EAN barcode, 6-14 digits | |
| category | No | Product category (omit for auto) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that scores are category-specific and never merged, includes per-lens fit and data_quality/coverage, ensuring confident scores. It does not mention auth needs or rate limits but covers key behavioral traits.
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 well-structured, front-loading the main purpose, then detailing category-specific scores and important caveats. It is efficient but could be slightly more concise.
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 no output schema, the description adequately explains the return structure: category-specific scores, per-lens fit, and data_quality/coverage. It provides enough context for an agent to understand the output, though it omits score ranges.
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 baseline is 3. The description adds context about output categories and scores but does not enhance parameter meaning beyond the schema's descriptions.
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 starts with a specific verb+resource: 'Get Clarity's product quality score by barcode.' It clearly states the core function and distinguishes from sibling tools like check_ingredient or scan_barcode by focusing on scoring and category-specific quality metrics.
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 obtaining quality scores but does not explicitly state when to use this tool versus siblings like scan_barcode or check_ingredient. It lacks guidance on prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
strain_lookupAInspect
Look up a cannabis or mushroom species/strain in Clarity's database. Returns verdict, evidence tier, PMID citation, and safety flags.
| Name | Required | Description | Default |
|---|---|---|---|
| species | Yes | Species or strain name, e.g. 'Cannabis sativa' or 'Lion's Mane' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states what the tool returns, failing to mention traits like idempotency, read-only nature, required permissions, or error conditions. This is insufficient for safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the action ('Look up'), and contains no unnecessary words. Every sentence adds value.
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 lookup tool with one parameter and no output schema, the description covers the purpose and return fields adequately. However, it could mention that it is a read operation and clarify the source of data. Overall, it is mostly 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% with a clear parameter description including an example. The tool description reiterates the example but adds limited additional meaning, so 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 looks up cannabis or mushroom species/strains in a database and lists the return fields (verdict, evidence tier, PMID citation, safety flags). It distinguishes itself from siblings like check_ingredient and check_interaction by focusing on species/strain lookup.
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 provide explicit guidance on when to use this tool versus alternatives. It implies its use for species/strain lookups but does not contrast with siblings like check_ingredient or scan_barcode, leaving agents without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_claimAInspect
Fact-check a free-text health/safety claim against Clarity's human-curated, evidence-graded database. Given a statement (e.g. 'fenugreek is safe while breastfeeding') and a condition lens, returns whether Clarity's curated position supports / contradicts / does-not-cover it, plus any verified citation on file. Use this to check whether a health claim an agent already holds aligns with Clarity's curation. Descriptive — not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lens | No | Condition lens the claim is about | all |
| statement | Yes | The health/safety claim to validate, e.g. 'niacinamide is safe during pregnancy' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the return types: 'supports / contradicts / does-not-cover it, plus any verified citation'. It implies read-only and non-destructive use. Missing details on authentication or rate limits but adequate for typical use.
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 well-structured sentences. First sentence defines core action and resource; second adds usage guidance and disclaimer. No wasted words; 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?
Given the tool's moderate complexity, full schema coverage, and clear description of inputs and return behavior (though no output schema), the description is complete for an agent to effectively use the tool. It covers purpose, inputs, outputs, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'statement' and 'lens'. The description mentions 'statement' and 'condition lens' but does not add significant new meaning 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?
The description uses specific verbs 'fact-check' and 'validate' and identifies the resource as 'Clarity's human-curated, evidence-graded database'. It clearly distinguishes from sibling tools like check_ingredient or check_interaction by focusing on free-text health claims.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'check whether a health claim an agent already holds aligns with Clarity's curation'. It also adds a disclaimer that it is descriptive, not medical advice. It does not explicitly state when not to use, but context with siblings implies purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.