Skip to main content
Glama

orange_book_protections

Read-onlyIdempotent

Find FDA Orange Book patent and exclusivity listings for NDAs/ANDAs, sorted by soonest expiry, to assess generic entry timing; filter by dates, company, ingredient, or application.

Instructions

FDA Orange Book patent and exclusivity listings for NDAs/ANDAs, soonest expiry first: application, brand, ingredient, applicant, kind (patent / exclusivity), code (patent number, '*PED' = pediatric extension; or exclusivity code such as NCE, ODE, PED, NP, M-xx, I-xxx, D-xxx, PC, CGT), expiry date, drug substance / drug product flags, patent use codes, delist flag, product numbers and the Orange Book page. Patents are as listed by the applicant; FDA does not verify them, and actual generic entry can differ (litigation, settlements, 30-month stays). Data refreshes monthly. Source: FDA Orange Book data files (public domain).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "orange_book_protections"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoListing kinds to keep: 'patent', 'exclusivity' (default both).
sinceNoExpiry date from (YYYY-MM-DD; default today).
untilNoExpiry date to (YYYY-MM-DD).
companyNoApplicant names, OR'd (e.g. 'Novo Nordisk').
excludeNoDrop results whose text fields contain any of these terms (whole word, case-insensitive; trailing * = prefix).
keywordNoAny word in brand, ingredient, applicant or patent/exclusivity code.
ingredientNoActive ingredient names, OR'd (e.g. 'semaglutide').
trade_nameNoBrand / trade names, OR'd (e.g. 'Ozempic').
applicationNo'NDA 209637', 'ANDA 215328' or '209637'.
max_resultsNoMaximum number of results to return (capped server-side).
upcoming_daysNoOnly listings expiring from today to today+N days (0-3650).
include_expiredNoIf true, also return listings that have already expired.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.1

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the description correctly spends its words on behavior the annotations cannot express: monthly refresh cadence, that patents are applicant-listed and unverified by FDA, that actual generic entry may differ due to litigation, settlements, and 30-month stays, and that the source is public-domain FDA data files. That is exactly the kind of trust/recency caveat an agent needs before citing this data.

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?

The purpose and sort order are front-loaded in the first line, followed by a compact field enumeration and then the important caveats about data provenance. It is dense but nearly every clause carries information; the only slight waste is the long parenthetical code glossary, which could be trimmed.

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?

Twelve parameters are all documented in the schema, an output schema exists so return shape needn't be restated, and annotations cover the safety profile. The description fills the remaining gaps an agent would care about: data vintage, sort order, source, and the litigation caveat that bounds how strongly the results can be relied on.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by decoding the 'code' values ('*PED' pediatric extension; exclusivity codes NCE, ODE, PED, NP, M-xx, I-xxx, D-xxx, PC, CGT) and the drug substance/product flags and patent use codes, which helps the agent interpret the keyword filter and results. It does not, however, explain the interaction between since/until and upcoming_days, or how max_results caps behave.

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?

The description opens with a specific verb+resource+scope: 'FDA Orange Book patent and exclusivity listings for NDAs/ANDAs, soonest expiry first', then enumerates the returned fields (application, brand, ingredient, code, expiry, delist flag, etc.). An agent can immediately tell what this returns. It does not differentiate itself from the sibling orange_book_loe or orange_book_changes_since, which is why it falls short of a 5.

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

Usage Guidelines3/5

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

Usage is only implied: 'soonest expiry first' plus the schema defaults (since = today, include_expired = false) suggest a forward-looking exclusivity landscape query rather than a historical or change-feed query. There is no explicit statement of when to prefer this over orange_book_loe, orange_book_changes_since, or fda_approvals, and no prerequisites or exclusions are named.

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