Skip to main content
Glama
Sign In
PubCrawl

PubCrawl

by nickjlamb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

compare_labels

Read-only

Compare US FDA prescribing information with UK/EU SmPC side by side, mapping equivalent sections and returning paired verbatim content with clear notes when a label or section is missing or truncated.

Instructions

Compare US FDA Prescribing Information vs UK/EU SmPC for a drug side-by-side. Maps equivalent sections (e.g., US Indications ↔ UK 4.1) and returns paired verbatim content. A missing side is always explained: us_label/uk_label say whether the label was retrieved, each comparison notes why a section is null, and sections longer than max_chars are flagged truncated with next_offset (read on with get_uspi / get_smpc).

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": {
      "drug": "<drug>"
    },
    "name": "compare_labels"
  }
}

Input Schema

NameRequiredDescriptionDefault
drugYesDrug name to compare across US and UK labelling
uk_drugNoName to use for the UK lookup when it differs from `drug` — brands often do (Farxiga/Forxiga, Prilosec/Losec). Defaults to `drug`.
us_drugNoName to use for the US lookup when it differs from `drug` (e.g. a US-only brand). Defaults to `drug`.
sectionsNoSpecific topics to compare (e.g., ['indications', 'adverse reactions']). Compares all mapped sections if omitted.
max_charsNoMaximum characters per side per section (default 4000). Longer sections are cut and flagged truncated with total_chars and next_offset; read on with get_uspi / get_smpc.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.8.0
    • addedInput schema / properties / max_chars
      Added value: +{
+  "description": "Maximum characters per side per section (default 4000). Longer sections are cut and flagged truncated with total_chars and next_offset; read on with get_uspi / get_smpc.",
+  "maximum": 50000,
+  "minimum": 500,
+  "type": "integer"
+}
  2. Changed2 schema fields changedv2.6.2
    • addedInput schema / properties / uk_drug
      Added value: +{
+  "description": "Name to use for the UK lookup when it differs from `drug` — brands often do (Farxiga/Forxiga, Prilosec/Losec). Defaults to `drug`.",
+  "type": "string"
+}
    • addedInput schema / properties / us_drug
      Added value: +{
+  "description": "Name to use for the US lookup when it differs from `drug` (e.g. a US-only brand). Defaults to `drug`.",
+  "type": "string"
+}
  3. First observedv2.5.1

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/non-destructive, and the description goes well beyond them: it discloses that missing sides are always explained via us_label/uk_label, that null sections carry a reason, and that long sections are cut and flagged with total_chars/next_offset. That is real output behavior an agent needs in order to interpret partial results.

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, front-loaded with purpose, then the mapping model, then failure/truncation semantics. No filler or restatement of the title.

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?

There is no output schema, so the description carries the return-value burden and does so: paired verbatim content, retrieval flags per side, per-section null reasons, and truncation/continuation fields. An agent could interpret every result shape from this text.

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?

Schema coverage is 100%, so every parameter including uk_drug/us_drug aliasing and max_chars bounds is already documented in the schema. The description reiterates the max_chars default and truncation consequence but adds no new parameter meaning, so the baseline of 3 applies.

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?

States a specific verb and two named resources: 'Compare US FDA Prescribing Information vs UK/EU SmPC for a drug side-by-side', and adds the section-mapping model (US Indications ↔ UK 4.1). This clearly separates it from get_uspi and get_smpc, which each return only one jurisdiction.

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 makes the use case clear (side-by-side comparison) and routes the agent to get_uspi / get_smpc for continuation past truncation. It does not state an explicit exclusion such as 'use get_uspi alone when you only need the US label', so routing is implied rather than spelled out.

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