How to give Claude an FDA drug-label tool with the Apify MCP server

AI agents are good at reasoning and terrible at facts. Ask Claude whether prescription ibuprofen carries a boxed warning, what it is contraindicated for, and which company makes a specific version, and it will produce a confident answer from its training data that may be outdated, blended across products, or simply wrong. In health tech, pharma, and clinical settings, "probably correct" about a drug label is not a place you want to be.

In this guide we fix that. We connect Claude to the official Apify MCP server, expose a single Actor that reads structured US drug labeling from openFDA, and turn "what does the label say?" from a guess into a live lookup against the actual FDA-approved label. By the end you will have a working drug-label tool that Claude, Cursor, or any MCP client can call mid-conversation, and you will understand exactly where in the run the tool fires and what it returns.

Everything below is a real setup with real output. No mocked responses.

What is the Apify MCP server?

Model Context Protocol (MCP) is an open standard that lets AI clients call external tools. The Apify MCP server (https://mcp.apify.com) implements that standard on top of the Apify platform, which means every one of the thousands of Actors in the Apify Store becomes a tool an agent can invoke.

Why route an Actor through MCP instead of hard-coding an API call?

• The agent decides when to fetch. Claude reads the conversation, notices it needs a fact it does not have, and calls the tool on its own. You do not write glue code for every question.
• Structured input and output. The MCP server hands Claude the Actor's input schema, so the model fills in the parameters correctly, and returns a clean dataset it can reason over.
• One connection, many tools. The same MCP endpoint exposes search-actors, fetch-actor-details, and call-actor, so an agent can discover and run any Actor without new configuration.
• No infrastructure. The server is hosted. You add a few lines to a config file and you are done.

The Actor we will use

We will expose the openFDA Drug Labels & Ingredients Scraper. Given a drug name, it returns the structured FDA label for matching products: brand and generic name, manufacturer, product type (OTC or prescription), route, active and inactive ingredients, NDC and application numbers, pharmacologic class, and the full label sections a clinician reads, including indications, dosage, boxed warning, contraindications, warnings, adverse reactions, and drug interactions.

That field set is exactly what a medication-safety check, a formulary tool, or a clinical decision-support prototype needs. FDA labeling is a useful first data source because it is public, authoritative, and the single source of truth for what a drug is approved to do in the US.

Step 1: Get your Apify API token

Sign in to the Apify Console, open Settings → Integrations, and copy your personal API token. The MCP server uses it to authenticate and to bill Actor runs to your account.

📌 Note: the token is a secret. Keep it in the client config only, never in a prompt or a committed file.

Step 2: Point Claude Desktop at the Apify MCP server

Open Claude Desktop's config file (Settings → Developer → Edit Config, or ~/Library/Application Support/Claude/claude_desktop_config.json on macOS) and add the Apify server. The tools query parameter is the important part: it tells the server which Actor to expose, so Claude gets one focused tool instead of the entire Store.

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/openfda-drug-labels-scraper",
      "headers": {
        "Authorization": "Bearer YOUR_APIFY_TOKEN"
      }
    }
  }
}

Cursor uses the same JSON in .cursor/mcp.json. If you prefer to run it locally over stdio instead of the hosted endpoint:

{
  "mcpServers": {
    "apify": {
      "command": "npx",
      "args": ["-y", "@apify/actors-mcp-server", "--tools", "scrapers_lat/openfda-drug-labels-scraper"],
      "env": { "APIFY_TOKEN": "YOUR_APIFY_TOKEN" }
    }
  }
}

Restart Claude Desktop so it picks up the new server.

Step 3: Confirm the tool is loaded

After the restart, the Actor shows up as a callable tool. If you list the tools the Apify server exposes, you will see the storage helpers plus the Actor itself, named after its Store handle:

get-actor-run, get-dataset-items, get-key-value-store-record,
abort-actor-run, scrapers_lat--openfda-drug-labels-scraper

That last entry, scrapers_lat--openfda-drug-labels-scraper, is our drug-label tool. Claude now knows it exists, what it does (from the Actor's README), and what inputs it takes (from the input schema the server passes along).

Step 4: Ask Claude about a drug label

Now the payoff. In a normal chat, ask a question that requires ground truth:

"For prescription ibuprofen, what does the FDA label say about its boxed warning and contraindications, and who manufactures it?"

Claude recognizes it cannot answer this reliably from memory, selects the drug-label tool, and fills in the input from your question. Under the hood the client sends a tools/call with the Actor's parameters:

{
  "name": "scrapers_lat--openfda-drug-labels-scraper",
  "arguments": {
    "query": "ibuprofen",
    "maxLabels": 5
  }
}

The Apify MCP server starts the Actor, waits for it to finish, and returns the dataset. Here is the real run metadata it produced:

{
  "runId": "H0JcoVdo3IP456L6o",
  "actorName": "scrapers_lat/openfda-drug-labels-scraper",
  "status": "SUCCEEDED",
  "startedAt": "2026-07-30T17:43:51.221Z",
  "finishedAt": "2026-07-30T17:43:55.217Z",
  "stats": { "runTimeSecs": 3.9 }
}

Under four seconds, live against the FDA label set.

Step 5: Read the real output

The dataset the tool returns is structured labeling data, one record per product. The query for "ibuprofen" comes back with several products, from OTC store-brand tablets to prescription formulations. The prescription record is the interesting one for a safety check. This is an actual record from the run (trimmed to the fields that matter):

{
  "brandName": ["Ibuprofen"],
  "genericName": ["IBUPROFEN"],
  "manufacturerName": ["Aurobindo Pharma Limited"],
  "productType": "HUMAN PRESCRIPTION DRUG",
  "route": ["ORAL"],
  "productNdc": ["59651-360", "59651-361", "59651-362"],
  "applicationNumber": ["ANDA213794"],
  "pharmClass": [
    "Nonsteroidal Anti-inflammatory Drug [EPC]",
    "Cyclooxygenase Inhibitors [MoA]"
  ],
  "unii": ["WK2XYI10QM"],
  "boxedWarning": "Cardiovascular Thrombotic Events ... NSAIDs cause an increased risk of serious cardiovascular thrombotic events, including myocardial infarction and stroke, which can be fatal. ... contraindicated in the setting of coronary artery bypass graft (CABG) surgery ...",
  "indicationsAndUsage": "Ibuprofen tablets are indicated for relief of the signs and symptoms of rheumatoid arthritis and osteoarthritis ...",
  "effectiveTime": "2025-02-14"
}

Claude reads that and answers in plain language: this prescription ibuprofen (Aurobindo Pharma, ANDA213794) carries a boxed warning for serious cardiovascular thrombotic events and GI bleeding, is contraindicated in the CABG surgery setting and for patients with aspirin- or NSAID-triggered asthma or urticaria, and is indicated for rheumatoid arthritis and osteoarthritis. Every one of those facts is traceable to a label effective 2025-02-14, not the model's memory.

The distinction between products is just as important. The same query also returns OTC records, such as a store-brand 200 mg tablet from a national pharmacy chain, with no boxed warning and a plain "temporarily relieves minor aches and pains" indication. A safety tool has to know the difference between an OTC tablet and a prescription-strength formulation, because the warnings, dosing, and approved uses are not the same. The Actor surfaces both, with productType, applicationNumber, and the label sections attached, so the agent can pick the right one.

A real use case: a medication-safety agent

Put this in context. A health-tech team is building an intake assistant that checks a patient's current medications against a new prescription. Before flagging anything, it needs to confirm, from the authoritative label and not a memorized approximation, that:

1. the drug in question actually carries the warning being cited,
2. the patient's condition is not listed under contraindications, and
3. the product type and strength match what was prescribed.

Without a tool, an analyst opens the FDA label lookup, searches the drug, reads through the boxed warning and contraindications sections, and copies the relevant lines into the record, once per medication. With the tool wired into Claude, the analyst pastes the medication list into the chat and asks the agent to pull each label. Claude calls the Actor per drug, extracts the boxedWarning, contraindications, and drugInteractions sections, compares them against the patient context, and produces a short structured note with the NDC and application number as evidence. The mechanical lookup disappears; the clinical judgment stays with the human.

This is the shape of every good agent tool: it removes the fetch, not the decision.

Going further: chain a second tool

A label tells you what a drug is approved to do and what it warns against. It does not tell you what people actually reported after taking it. The same MCP connection can expose more Actors by extending the tools parameter:

https://mcp.apify.com?tools=scrapers_lat/openfda-drug-labels-scraper,scrapers_lat/openfda-drug-events-scraper

Now the agent can read the official label and pull real-world adverse-event reports for the same drug from the FDA's reporting system in one conversation, then combine both into a single safety summary: what the label warns about, and what patients and clinicians have actually reported. Because each Actor is a separate tool, the agent picks the right one for each step on its own.

🏹 Troubleshooting: if the tool does not appear in Claude, the two usual causes are a missing or misspelled Actor handle in the tools parameter (it must be the exact username/actor-name from the Store URL) and a config that was edited while Claude was running. Fix the handle, save, and fully restart the client.

📌 Note: each tool call is a real Actor run billed to your Apify account (this Actor is pay-per-result). For one-off lookups the cost is a fraction of a cent; if you plan to pull thousands of labels on a schedule, run the Actor directly through the Apify API or a scheduled task instead of one call per chat message. A drug name like "ibuprofen" can match dozens of products, so keep maxLabels tight and lean on productType, route, or manufacturer to narrow the result set when you need a specific label.

Wrapping up

You now have an AI agent that can read the actual FDA label for a US medicine, on demand, mid-conversation, with the boxed warning, contraindication, ingredient, and identifier detail a clinical or pharma check actually needs. The pattern is reusable: pick an Actor that returns authoritative structured data, expose it through the Apify MCP server with the tools parameter, and let the agent decide when to call it.

To take it further:

• Narrow queries with the productType, route, and manufacturer inputs to pin down a specific label instead of a whole drug class.
• Add the adverse-events Actor to move from "what the label warns about" to "what was actually reported."
• Read the Apify MCP server docs for OAuth setup, resource reads, and the search-actors / call-actor tools that let an agent discover Actors it was not preconfigured with.

The Actor used in this guide: openFDA Drug Labels & Ingredients Scraper.