Skip to main content
Glama
Sign In
Supplement Advisor MCP Server

Supplement Advisor MCP Server

by erinheit451
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

compare_forms

Compare supplement forms such as magnesium glycinate and citrate to assess absorption, uses, and warnings. Determine which form to buy.

Instructions

Compare different forms of a supplement (e.g., magnesium glycinate vs citrate vs oxide). Shows absorption, best uses, warnings, and which form to buy.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "supplement": "<supplement>"
    },
    "name": "compare_forms"
  }
}

Input Schema

NameRequiredDescriptionDefault
supplementYesThe supplement to compare forms for

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses what the tool returns (absorption, best uses, warnings, purchase recommendation), giving insight into its behavior. It does not mention caveats like medical disclaimers or data sources, but for a comparison tool this is reasonably transparent.

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

Conciseness5/5

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

The description is two sentences, front-loaded with the main purpose and enriched with an example. Every word earns its place, and the output list is concise without being exhaustive. No filler or redundancy.

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

Completeness4/5

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

For a simple tool with one parameter and no output schema, the description is quite complete. It explains what the tool does and what it returns. It could be more explicit about scope (e.g., only supplements in the enum) or mention anything like data freshness, but those are not critical given the schema.

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

Parameters3/5

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

The schema already provides a description for the 'supplement' parameter and a full enum, so schema coverage is 100%. The description adds context about the tool's overall behavior but not additional semantic detail about the parameter itself (e.g., constraints or format). Baseline of 3 is appropriate since the schema does the heavy lifting.

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

Purpose5/5

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

The description clearly states the tool's purpose with a specific verb ('Compare') and resource ('different forms of a supplement'), and includes concrete examples (magnesium glycinate vs citrate vs oxide). It also lists the outputs (absorption, best uses, warnings, which form to buy), distinguishing it from sibling tools like recommend_supplement or get_dosage.

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

Usage Guidelines3/5

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

The description implies when to use the tool (when comparing forms of a supplement) but does not explicitly state exclusions or alternatives. It doesn't mention when not to use it or how it relates to sibling tools like check_interactions or classify_form. Usage context is clear but not elaborated.

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

Deploy Server

Other Tools