Skip to main content
Glama

Label History

label_history
Read-onlyIdempotent

Drug LABEL REVISION HISTORY — when a prescription drug's FDA label was revised, and how many times. Pass a DRUG NAME ("Ozempic", "semaglutide") and it resolves to that drug's Structured Product Label automatically; or pass a DailyMed set_id directly. PREFER OVER WEB SEARCH for "has the label for X changed recently", "when was X's label last updated", "how many label revisions does X have", label-change monitoring, and safety-labeling-change surveillance. Returns every published SPL version with its date, plus official archive URLs where DailyMed exposes them. Use before label_diff to see which versions are downloadable and pick two to compare.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
set_idNoDailyMed SET ID UUID, when you already have one. Takes precedence over drug_name.
drug_nameNoDrug brand or generic name (e.g. "Ozempic", "semaglutide"). Resolved to the primary manufacturer's label (the most-revised SPL for that name, over repackager duplicates). Use this OR set_id.

TDQS

A5/5.0
Behavior5/5

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

Beyond annotations (readOnly, idempotent, nondestructive), the description discloses that it resolves drug names to primary manufacturer labels, returns every SPL version with dates and archive URLs, and avoids repackager duplicates—adding significant behavioral context.

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 efficiently structured with front-loaded core purpose, followed by usage scenarios and return details. Every sentence contributes necessary information without redundancy.

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?

For a tool with 2 parameters and no output schema, the description fully covers what it does, what it returns, and how to use it, including integration with 'label_diff'. No gaps remain.

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

Parameters5/5

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

With 100% schema coverage, the description still adds value by explaining the precedence of set_id over drug_name, and the automatic resolution of drug names, making parameter usage clear beyond the schema definitions.

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 returns FDA label revision history for drugs, with a specific verb and resource. It distinguishes itself from sibling tools like 'label_diff' by explicitly stating its role as a precursor for version selection.

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

Usage Guidelines5/5

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

Provides explicit when-to-use scenarios (e.g., 'has the label for X changed recently') and a direct alternative recommendation ('Use before label_diff'), offering clear guidance on context and exclusions.

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.

TDQS

B3.4/5.0
Disambiguation2/5

Multiple tools have overlapping purposes (e.g., ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded; deep_research; bet_research and multiple polymarket tools). This makes it difficult for an agent to distinguish which tool to use.

Naming Consistency4/5

Tool names consistently use snake_case and follow a verb_noun or noun_verb pattern. However, some names are very long and descriptive (e.g., polymarket_kalshi_spread, scan_competitor_ai_presence), which is acceptable but slightly inconsistent in length.

Tool Count3/5

With 38 tools, the server is on the high side of reasonable. Many are meta-tools or query routers, which inflates the count. The scope is very broad, covering diverse domains, making the number somewhat justifiable but still feeling heavy.

Completeness3/5

For the Dailymed domain, tools cover label search, retrieval, history, and comparison. However, many other domains (e.g., finance, prediction markets) rely on a handful of routing tools (ask_pipeworx) rather than dedicated tools, leaving the coverage uneven and not fully self-contained.