Skip to main content
Glama

List Classes

list_classes
Read-onlyIdempotent

List pharmacologic drug-class reference entries from DailyMed, optionally filtered by class_code or class type (EPC = established pharmacologic class, MoA = mechanism of action, PE = physiologic effect, CS = chemical structure). Returns class codes and display names. ~1,210 classes total, 100 per page.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page (100 per page, ~13 pages). Ignored when class_code is given.
typeNoEPC | MoA | PE | CS
class_codeNoRestrict to a specific class code. NLM RxClass format, e.g. "N0000175809" — not a UMLS CUI.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultsNoList of drug classes
totalResultsNoTotal number of classes

TDQS

A4.8/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint, etc.), the description adds useful context: returns class codes and display names, total ~1,210 classes, 100 per page, and notes page behavior with class_code.

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?

Three sentences, tightly written with no filler. Front-loaded with main action, then details. Every sentence adds value.

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?

Given 3 fully described parameters, rich annotations, and an output schema, the description is complete: it explains purpose, filters, data volume, pagination, and return format.

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?

Schema covers all three parameters at 100%. The description adds further meaning: explains type values (EPC, MoA, PE, CS), pagination (100 per page, 1-based), and class_code format (NLM RxClass, not UMLS CUI).

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 'List pharmacologic drug-class reference entries from DailyMed' with optional filters, distinguishing it from sibling tools like get_drug or search_drugs.

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?

The description explains optional filters by class_code or type, but does not explicitly state when not to use or mention alternatives, though it is implied by the context of sibling tools.

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.