Skip to main content
Glama

Scite

by ai.scite

search_mhra

Read-onlyIdempotent

Search MHRA (Medicines and Healthcare products Regulatory Agency) safety alerts and publications.

This dataset contains full-text content from MHRA drug safety alerts, medical device alerts, field safety notices, and regulatory publications. Search covers headlines, descriptions, and page-level document content.

Use this tool when the question involves UK drug safety communications, MHRA medical device alerts, field safety notices, drug recalls, or MHRA regulatory guidance.

Parameters:

  • q: Search query (drug names, device types, safety issues, alert topics, etc.)

  • f: Space-delimited filters in field:"value" format.

    • Facet filters: ontology.tags, ontology.categories, domain

    • Date range filters on attachments.file.createdAt or attachments.file.modifiedAt:

      • Suffix notation: append gte (>=) or lt (<) to the field name. Example for Q4 2025: attachments.file.createdAtgte:"2025-10-01" attachments.file.createdAtlt:"2026-01-01"

      • Comma notation: attachments.file.createdAt:"2025-10-01,2026-01-01" (gte,lt)

      • Accepted date formats: YYYY-MM-DD, YYYY-MM-DDTHH:MM:SS, YYYY-MM-DDTHH:MM:SS+ZZZZ, or epoch milliseconds.

  • p: Page number (default: 1)

Example queries:

  • Immunosuppressant alerts in Q4 2025: q="immunosuppressant", f='attachments.file.createdAtgte:"2025-10-01" attachments.file.createdAtlt:"2026-01-01"'

  • All drug safety updates since March 2025: q="drug safety update", f='attachments.file.createdAtgte:"2025-03-01"'

  • Medical device alerts from gov.uk: q="medical device alert", f='domain:"gov.uk"'

Returns: Alerts with id, headline, description, tags, categories, date, and page-level content snippets showing where the query matched.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fNoSpace-delimited filters in `field:"value"` format. Facet fields: ontology.tags, ontology.categories, domain. Date range: use attachments.file.createdAt or attachments.file.modifiedAt with gte/lt suffix (e.g. attachments.file.createdAtgte:"2025-10-01" attachments.file.createdAtlt:"2026-01-01") or comma notation (e.g. attachments.file.createdAt:"2025-10-01,2026-01-01"). Accepts YYYY-MM-DD, ISO datetime, or epoch millis.
pNoPage number (default: 1)
qNoSearch query (drug names, device types, safety issues, etc.)

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, and non-destructive traits. The description adds meaningful behavioral context: it searches full-text document content, covers multiple MHRA publication types, and returns page-level content snippets. It does not mention any limits or pagination behavior beyond the p parameter, but the added value beyond annotations is solid.

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 well-organized and front-loaded: purpose first, then dataset scope, usage guidance, parameter explanations, examples, and return value. Despite its length, every section serves a purpose, and the examples are highly instructive. No redundant or filler content.

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 the tool's moderate complexity (search query, filtering syntax, date handling), the description is remarkably complete. It covers what the tool searches, when to use it, parameter specifics with examples, and what is returned. The absence of an output schema is compensated by the explicit return description.

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?

While schema coverage is 100%, the description greatly enriches parameter understanding. It explains the f filter syntax in detail, including facet fields, date-range suffix and comma notations, accepted date formats, and provides three concrete example queries. This goes well beyond the schema's parameter descriptions.

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 opens with a specific verb and resource: 'Search MHRA safety alerts and publications.' It further details content types (drug safety alerts, medical device alerts, field safety notices, regulatory publications) and clarifies search scope, making it clearly distinct from sibling search tools like search_drugs or get_mhra_alert.

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?

Provides explicit guidance: 'Use this tool when the question involves UK drug safety communications, MHRA medical device alerts, field safety notices, drug recalls, or MHRA regulatory guidance.' It does not explicitly name excluded alternatives or when-not-to-use, but the context is clear enough for sibling differentiation.

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

All Scite toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, but there is potential confusion between search_device510k and search_510k_summaries, and between get_device510k and get_510k_summary, despite descriptions differentiating them. Overall, the set is well-disambiguated.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with underscores, e.g., search_clinical_trials, create_collection, get_drug. No mixing of conventions, making it easy for an agent to predict tool names.

Tool Count4/5

25 tools is slightly above the typical range (3-15) but justified given the server covers multiple domains (literature, FDA, clinical trials, grants, patents, collections). Each tool serves a distinct function without feeling bloated.

Completeness4/5

The tool set covers essential operations for each domain: search and get details for most databases, and full CRUD for collections. Minor gaps exist, such as no ability to create saved-search collections (requires web app), but the surface is robust.

Resources