Skip to main content
Glama
yeyuan98

BioMCP

by yeyuan98
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

drug_get

Read-only

Retrieve detailed drug information by name, including regulatory, safety, targets, indications, and adverse-event sections, to support drug research and safety lookup.

Instructions

Get detailed drug information by name

Input Schema

NameRequiredDescriptionDefault
nameYesDrug name (e.g., "imatinib", "aspirin")
limitNo
sectionsNoSections to include (adverse_events = FDA FAERS adverse reactions ranked by report count; limit applies to reaction rows; indications = OpenTargets indications ranked by max clinical phase descending, then trial-report count, then disease name; who_regulatory = WHO Prequalification listing only, ~650 global-health priority products — prequalified:false means not PQ-listed, not banned or unapproved anywhere; limit applies to product rows)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.6.0-alpha.10
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed3 schema fields changedv1.6.0-alpha.7
    • addedInput schema / properties / name / minLength
      Added value: +1
    • changedInput schema / properties / sections / description
      Previous value: -"Sections to include (adverse_events = FDA FAERS adverse reactions ranked by report count; limit applies to reaction rows)"New value: +"Sections to include (adverse_events = FDA FAERS adverse reactions ranked by report count; limit applies to reaction rows; indications = OpenTargets indications ranked by max clinical phase descending, then trial-report count, then disease name; who_regulatory = WHO Prequalification listing only, ~650 global-health priority products — prequalified:false means not PQ-listed, not banned or unapproved anywhere; limit applies to product rows)"
    • changedInput schema / properties / sections / items / enum
      Previous value: -[
-  "core",
-  "us_regulatory",
-  "eu_regulatory",
-  "who_regulatory",
-  "safety",
-  "targets",
-  "indications",
-  "adverse_events",
-  "all"
-]New value: +[
+  "core",
+  "us_regulatory",
+  "who_regulatory",
+  "safety",
+  "targets",
+  "indications",
+  "adverse_events",
+  "all"
+]
  3. Changed2 schema fields changedv1.1.1
    • changedInput schema / properties / sections / description
      Previous value: -"Sections to include"New value: +"Sections to include (adverse_events = FDA FAERS adverse reactions ranked by report count; limit applies to reaction rows)"
    • changedInput schema / properties / sections / items / enum
      Previous value: -[
-  "core",
-  "us_regulatory",
-  "eu_regulatory",
-  "who_regulatory",
-  "safety",
-  "targets",
-  "indications",
-  "all"
-]New value: +[
+  "core",
+  "us_regulatory",
+  "eu_regulatory",
+  "who_regulatory",
+  "safety",
+  "targets",
+  "indications",
+  "adverse_events",
+  "all"
+]
  4. First observedv0.1.8

TDQS

C2.8/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds little beyond "detailed" — no mention of what sections or return shape to expect, and no pagination or open-world nuance of its own.

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?

A single tight sentence with no filler, front-loading the verb and resource. It is efficient but arguably over-terse for the tool's complexity.

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

Completeness3/5

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

For a get-by-name tool with no output schema, the description is thin and never mentions the selectable sections or return content, forcing the agent to read the schema. The schema's detailed sections field partly fills this, keeping it at minimal viable rather than inadequate.

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

Parameters2/5

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

Schema coverage is 67%: the schema richly documents name and sections, but limit is undocumented. The description adds no parameter meaning whatsoever, so it fails to compensate for the coverage gap and just leans on the schema.

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?

States a specific verb ("Get") and resource ("detailed drug information") with the input mode "by name," letting an agent distinguish it from drug_search at a high level. It does not explicitly name or contrast with any sibling, keeping it below the top mark.

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

Usage Guidelines2/5

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

The description offers no guidance on when to use this versus drug_search or drug_trials, nor any prerequisite or exclusion. "By name" implies an identifier lookup but leaves the choice of tool to inference.

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