Skip to main content
Glama

Supplement interactions (drugs and supplements)

get_supplement_interactions
Read-onlyIdempotent

Drug interactions come only from FDA drug labels and supplement-supplement ones only from Aviado's verified pairs; an empty result is not evidence that there is no interaction. Labels are thorough for some supplements and sparse or missing for most; read coverage.drug, and never treat an empty or short list as proof of safety. To check one medication pass drug (generic name; salt forms merged, so 'warfarin' matches 'warfarin sodium'; brand names are not matched). Also returns supplement-supplement interactions from Aviado's verified pairs only (synergies, antagonisms, absorption conflicts, timing), except on a drug check unless include_supplement_interactions is true. Interactions recorded for what the supplement contains are included and labelled: fish oil returns EPA, DHA and omega-3 interactions (interaction_sources, recorded_for). Drug entries are one per drug, most severe first, paged with drug_limit/drug_offset (drug_page.total, next_offset); label_artifact_suspected marks an entry whose drug name contains the supplement only as a salt (e.g. esomeprazole magnesium) and whose text does not mention it. Data-source failures return an error, never an empty list. The supplement may be a name or an Aviado canonical_id (from search_supplements or a candidates list). Check status first: needs_confirmation / no_match means the input did not resolve, data is null and next_step says how to retry.

Input Schema

NameRequiredDescriptionDefault
drugNoOnly return drug interactions for this drug: its generic name (e.g. 'warfarin', 'sertraline'), matched exactly with salt forms merged ('warfarin' matches 'warfarin sodium'); brand names are not matched. Supplement-supplement interactions are then omitted unless include_supplement_interactions is true
drug_limitNoMax drug interactions to return (default 20, max 200)
supplementYesSupplement name
drug_offsetNoDrug interactions to skip, for paging (use drug_page.next_offset)
include_drug_interactionsNoInclude FDA drug-supplement interactions
include_supplement_interactionsNoInclude supplement-supplement interactions (default: true without drug, false when drug is given)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / drug
      Added value: +{
      +  "description": "Only return drug interactions for this drug: its generic name (e.g. 'warfarin', 'sertraline'), matched exactly with salt forms merged ('warfarin' matches 'warfarin sodium'); brand names are not matched. Supplement-supplement interactions are then omitted unless include_supplement_interactions is true",
      +  "maxLength": 512,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / drug_limit
      Added value: +{
      +  "default": 20,
      +  "description": "Max drug interactions to return (default 20, max 200)",
      +  "maximum": 200,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / drug_offset
      Added value: +{
      +  "default": 0,
      +  "description": "Drug interactions to skip, for paging (use drug_page.next_offset)",
      +  "maximum": 9007199254740991,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / include_supplement_interactions
      Added value: +{
      +  "description": "Include supplement-supplement interactions (default: true without drug, false when drug is given)",
      +  "type": "boolean"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / supplement / maxLength
      Added value: +512
    • addedInput schema / properties / supplement / minLength
      Added value: +1
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, and non-destructive behavior, but the description adds substantive traits: empty results are not proof of safety, coverage.drug must be read, data-source failures return errors rather than empty lists, label_artifact_suspected flags salt-form artifacts, and status codes indicate unresolved input. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with caveats and appropriately sized for a complex tool, but it is a single dense paragraph that repeats the empty-result-is-not-safety warning and could be tighter. Most other sentences carry operational detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies return-value semantics such as interaction_sources, recorded_for, drug_page.total/next_offset, label_artifact_suspected, status, and next_step. Given annotations cover safety and the schema covers parameters, an agent has enough to call and interpret the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description additionally clarifies that supplement can be a name or an Aviado canonical_id and explains paging via drug_limit/drug_offset and drug_page fields. It still omits include_drug_interactions and mostly repeats drug matching rules already in the schema, so it is above baseline but not exhaustive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource and the two interaction classes, including provenance: FDA drug labels for drug interactions and Aviado verified pairs for supplement-supplement interactions. It does not explicitly contrast itself with the sibling check_interaction or state when that sibling should be used instead, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete usage conditions: pass drug to check one medication, use include_supplement_interactions to retain supplement-supplement pairs, and check status first for unresolved input. It does not state when not to use this tool or name check_interaction as an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources