Lifestyle medicine health intelligence via x402 micropayments. 637+ peer-reviewed references.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.7/5 across 9 of 9 tools scored. Lowest: 3.1/5.
Most tools have distinct purposes, but there is overlap between lifestyle_query and query_nutrition_topic, and between check_interactions and drug_safety, though descriptions help differentiate by scope.
Mixed naming conventions: some verbs (check, get, interpret, query) and some nouns (drug_safety, marker_reference). The 'glp_' prefix is consistent but not used elsewhere.
9 tools is well-scoped for the health intelligence domain, covering drug interactions, protocols, lab interpretation, and general queries without being excessive.
Covers major areas comprehensively (interactions, protocols, labs, queries), though the two query tools could be merged, and a tool for patient-specific recommendations might be missing.
check_interactionsACheck a list of medications for food-drug interactions, nutrient depletions, and timing-critical dosing requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| medications | Yes | ||
| foods_or_supplements | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds value by specifying the three dimensions covered (food-drug, nutrient depletion, timing-critical dosing), which are specific behaviors beyond the annotation. It doesn't describe output format or edge cases, but the added specificity exceeds baseline.
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 immediately states the tool's purpose. It contains no redundant words and front-loads the core functionality without 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?
The tool has two parameters and no output schema. The description covers the main purpose and mentions the required parameter implicitly, but omits the optional 'foods_or_supplements' parameter and provides no hint about return values or result format. Given the moderate complexity and existing annotations, the description is adequate but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'medications' implicitly but never explains the 'foods_or_supplements' parameter, nor does it specify expected string formats (e.g., generic names, brand names). The description adds minimal meaning for the required parameter and none for the optional one.
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 'Check' with a clear resource ('list of medications') and enumerates three precise check types (food-drug interactions, nutrient depletions, timing-critical dosing). This clearly differentiates it from sibling tools like drug_safety or lifestyle_query, which cover adjacent but distinct domains.
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 a clear usage context: when the user wants to assess interactions between medications and food/nutrients/timing. It does not explicitly mention alternatives or when not to use the tool, but the context is strong enough that an agent can infer when to invoke it. Lack of explicit exclusions keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
drug_safetyAReturn the food-drug safety profile for a single medication.
| Name | Required | Description | Default |
|---|---|---|---|
| medication | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, lowering the burden on the description. The description adds the constraint of 'single medication' and specifies the food-drug domain, but it does not disclose return format or potential limitations. This matches the pattern from the TDQS 4.3 calibration example.
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 sentence with no unnecessary words. It is front-loaded with the action and resource, making it immediately understandable.
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 has only one parameter and no output schema. The description gives the core function but does not clarify what the 'food-drug safety profile' contains, how to handle unknown medications, or how it differs from check_interactions. It is adequate for a simple tool but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only implies that the 'medication' parameter should be a single medication name, but gives no format, accepted identifiers (generic vs brand), or examples. This adds minimal value over the parameter name itself.
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 (Return), a precise resource (food-drug safety profile), and a scope (single medication). This clearly distinguishes it from sibling tools like check_interactions, which likely handle multiple drugs, and get_protocol, which covers protocols.
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 a single medication' gives clear context for when to use this tool, implying it is not for multi-drug or general interaction queries. However, it does not explicitly mention exclusions or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_protocolBGenerate an evidence-based whole-food plant-based protocol for one of 47 chronic conditions. Returns therapeutic foods, daily meal structure, foods to minimize, monitoring markers, and clinical citations.
| Name | Required | Description | Default |
|---|---|---|---|
| condition | Yes | ||
| user_context | No | ||
| duration_weeks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read operation, and the description's 'Generate' is consistent. The description adds value by listing the output components (therapeutic foods, meal structure, etc.), but it does not disclose how parameters like duration_weeks or user_context affect 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 a single sentence that effectively communicates the action and expected deliverables. It is front-loaded with the verb and resource, contains no redundancy, and every clause adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a good high-level overview of the return contents (therapeutic foods, meal structure, foods to minimize, monitoring markers, citations), but with no output schema and a nested user_context object, it lacks details on output shape and how the optional parameters affect results. More context would be needed for full agent decision-making.
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?
Since schema description coverage is 0%, the description should compensate for unclear parameters. It only references '47 chronic conditions' (matching the condition enum) but does not explain what user_context is for or how duration_weeks influences the protocol. Most parameters remain semantically empty beyond their basic schema types.
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 generates a whole-food plant-based protocol for one of 47 chronic conditions and lists what it returns. It uses a specific verb and resource, and the 'whole-food plant-based' scope distinguishes it from sibling protocol tools, though no alternative is explicitly named.
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 usage context is implied: an agent would infer to use this when creating a plant-based protocol for a condition. However, there is no explicit when-to-use or when-not-to-use guidance, and no reference to alternatives like glp_protocol or query_nutrition_topic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
glp_phase_guideBReturn the protocol overview for a specific GLP-1 therapy phase (starting, titrating, maintenance, tapering, post_drug).
| Name | Required | Description | Default |
|---|---|---|---|
| glp1_phase | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation (returning a protocol overview is a read operation), so there is no contradiction. However, it adds no extra behavioral context beyond the purpose, such as output format, included content, or limitations. The annotation covers the safety aspect, but the description doesn't enrich beyond that.
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 clear sentence that is front-loaded with the action and resource. It is appropriately concise with no wasted words or repetition of schema details beyond the phase list.
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 simplicity of the tool (one enum parameter, no output schema), the description provides a minimal viable overview. However, it fails to contextualize what a 'protocol overview' contains, and it doesn't differentiate from similarly named sibling tools. The description is complete for basic understanding but lacks depth for an agent to fully anticipate the response or choose it confidently amid alternatives.
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 has zero parameter descriptions, so the description helps by naming the phases and clarifying they are GLP-1 therapy phases. However, it essentially repeats the enum values without explaining what each phase entails or how the parameter should be used. This is adequate for a self-explanatory enum but not rich 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 the tool returns a protocol overview for a specific GLP-1 therapy phase, using a specific verb and resource. It lists the exact phases, which helps clarify scope. However, it does not distinguish this tool from similar sibling tools like get_protocol or glp_protocol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_protocol or glp_protocol. No prerequisites, exclusions, or situational recommendations are provided, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
glp_protocolAGenerate a GLP-aware nutrition protocol composed on top of any active chronic condition. Returns protein floor (1.2-1.6 g/kg), fiber ramp schedule, GI tolerance interventions, resistance training prescription, hydration target, and phase-specific guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| condition | No | ||
| glp1_phase | Yes | ||
| user_context | No | ||
| glp1_medication | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe read-only nature is covered. The description adds valuable behavioral context by enumerating the exact outputs (protein floor ranges, fiber ramp, hydration target) and clarifying it composes on top of chronic conditions. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and then lists specific output components. Every phrase adds value, with no padding or repetition. It is concise yet informative.
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 carries the burden of explaining expected returns, and it does so by listing specific deliverables (protein floor, fiber ramp schedule, etc.). However, it is vague about how condition and user_context influence results, and it does not mention potential limitations or caveats. Overall, it provides enough context for basic 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?
Schema description coverage is 0%, so the description must compensate for parameter meanings. It hints at 'phase' and 'chronic condition' but does not explain the enums for glp1_phase or glp1_medication, nor the nested user_context object. The description focuses on outputs rather than inputs, leaving parameters largely unexplained.
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 generates a GLP-aware nutrition protocol, listing specific output components (protein floor, fiber ramp, GI interventions, etc.). This distinguishes it from siblings like get_protocol (generic) and glp_phase_guide (phase-focused) by emphasizing a comprehensive, condition-aware protocol.
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 GLP-1 users with active chronic conditions and mentions phase-specific guidance, giving clear context. However, it does not explicitly state when to use this tool over alternatives like glp_phase_guide or query_nutrition_topic, 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.
interpret_labsAInterpret a panel of lab values against ACLM-optimized reference ranges. Returns risk classification per marker, lifestyle interventions, and medication deprescription signals.
| Name | Required | Description | Default |
|---|---|---|---|
| lab_values | Yes | Key-value pairs of biomarker names and values. Common keys: hba1c, fasting_glucose, fasting_insulin, ldl, hdl, triglycerides, apob, lp_a, hscrp, vitamin_d, b12, ferritin, tsh, free_t4, free_t3. | |
| health_goals | No | ||
| current_medications | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, so the agent knows it is a safe read operation. The description adds valuable behavioral context beyond annotations by specifying that it returns risk classifications, lifestyle interventions, and medication deprescription signals, and that it uses ACLM-optimized ranges. However, it does not mention how it handles unknown lab keys or units, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary verb and resource, and contains no filler or redundancy. Every clause contributes meaningful information about the tool's function and outputs.
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?
Despite no output schema, the description adequately summarizes return categories (risk classification, lifestyle interventions, deprescription signals). It covers the main inputs and their purpose implicitly. Missing details like biomarker coverage limits or handling of unavailable goals/medications, but for a read-only interpretation tool with simple parameters, it 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 only 33%, with health_goals and current_medications having no descriptions. The tool description gives some indirect meaning by mentioning 'lifestyle interventions' (ties to health_goals) and 'medication deprescription signals' (ties to current_medications), but it does not explain how these parameters affect the output or their optionality. It partially compensates for the low schema coverage but leaves gaps.
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: 'Interpret a panel of lab values against ACLM-optimized reference ranges' and lists specific outputs ('risk classification per marker, lifestyle interventions, and medication deprescription signals'). This distinguishes it from sibling tools like marker_reference (which likely handles single markers) and drug_safety/check_interactions (which focus on medications/drugs).
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 interpreting a panel of lab values, but provides no explicit guidance on when to use this tool versus siblings such as marker_reference or lifestyle_query. There are no stated exclusions or alternative tool recommendations, so the usage context is only implied, not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lifestyle_queryAAsk any lifestyle medicine question. Returns evidence-based answer with citations from a 200-chunk knowledge base spanning ACLM 6-pillars, B.O.N.S.A.I. nutrition, drug-food interactions, lab interpretation, GLP guidance, wearables, and CGM signal interpretation.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| pillar | No | any | |
| max_results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and closed-world, and the description adds that answers are evidence-based with citations and that the knowledge base is a 200-chunk dataset. This gives useful behavioral context beyond what the annotations provide, with 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 a single, dense sentence that front-loads the purpose and lists the covered topics. It is concise and structured, though the long enumeration makes it slightly heavy, so it doesn't earn a 5.
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?
There is no output schema, but the description discloses the return type (evidence-based answer with citations) and the knowledge base scope. It doesn't mention the effect of the pillar parameter on results, but for a query tool with good annotations, 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 description coverage is 0%, and the description does not mention any parameters. It doesn't explain the pillar filter or max_results, so it fails to compensate for the lack of schema descriptions. The enum values are self-explanatory, but the description adds no value for parameter usage.
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 answers lifestyle medicine questions and specifies the knowledge base topics, distinguishing it from specialized siblings like interpret_labs and drug_safety by its broad scope. However, it doesn't explicitly name alternatives, so it stops short of a perfect score.
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 general lifestyle medicine queries by listing the broad range of topics, but it doesn't provide explicit guidance on when to use this tool instead of the specialized siblings. There are no exclusion criteria or alternative recommendations, so it only meets the 'implied usage' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
marker_referenceALook up the ACLM-optimized reference range and lifestyle intervention plan for a single biomarker (e.g., apob, lp_a, hscrp, hba1c, fasting_insulin, vitamin_d).
| Name | Required | Description | Default |
|---|---|---|---|
| marker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds beyond that by specifying the return content (reference range and lifestyle intervention plan) and the ACLM-optimized nature. No contradiction with annotations; the behavior is consistent with a read-only lookup.
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, front-loaded sentence that is concise and informative, with no filler. Every word contributes to understanding the tool's purpose and examples.
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 lookup tool with one parameter, the description conveys purpose, examples, and return content. It doesn't detail output format or error handling, but with good annotations and no output schema, it's sufficiently complete for typical use.
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 only defines 'marker' as a string with no description. The description compensates by providing six concrete examples (apob, lp_a, hscrp, hba1c, fasting_insulin, vitamin_d) and clarifying that it's a single biomarker, significantly adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'look up' with a clear resource: 'ACLM-optimized reference range and lifestyle intervention plan for a single biomarker.' It distinguishes itself from sibling tools like interpret_labs and lifestyle_query by focusing narrowly on single-biomarker reference lookup, with concrete examples.
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 clearly implies when to use the tool: for a single biomarker reference range and lifestyle plan. It doesn't explicitly mention alternatives or exclusions, but the single-biomarker scope provides clear context, aligning with a 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_nutrition_topicBAsk a nutrition or food-as-medicine question. Returns evidence-based answer from the 200-chunk lifestyle medicine knowledge base.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds useful context about the source ('200-chunk lifestyle medicine knowledge base') and that answers are 'evidence-based', which is more than the annotations provide. However, it does not disclose limitations such as the scope of the knowledge base or the nature of the returned answer beyond being evidence-based.
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 that immediately convey the tool's function and source. It is front-loaded with the action ('Ask') and contains no extraneous information, making it highly concise and well-structured.
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 relatively simple, with two parameters and a clear read-only purpose. However, the description does not explain the return format or the role of max_results, and there is no output schema. Given the missing parameter semantics, the description is not fully complete for an agent to use the tool optimally without additional inference.
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 0%, so the description bears full responsibility for explaining parameters. It only references 'query' implicitly through 'Ask a question' but does not explain the structure or expected format of the query, nor does it mention max_results at all. This fails to compensate for the lack of schema 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 clearly states the tool's purpose: 'Ask a nutrition or food-as-medicine question' and specifies the resource ('200-chunk lifestyle medicine knowledge base'). It uses a specific verb and resource, making the intent unambiguous. It does not explicitly differentiate from sibling tools like lifestyle_query, but the domain is clearly nutrition-focused.
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 nutrition/food-as-medicine questions, but provides no explicit guidance on when to use this tool versus alternatives like lifestyle_query. There are no exclusions or when-not-to-use instructions, so the usage context is implied rather than explicitly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
