AI agents are confident and forgetful. Ask Claude whether a specific Chicago cafe passed its last health inspection, and it will answer from training data that is months stale, or invent a plausible-sounding result. For a trust and safety team deciding whether to activate a restaurant on a delivery marketplace, or an insurer pricing a food-service policy, "probably fine" is not an answer you can put your name on.
In this guide we fix that. We connect Claude to the official Apify MCP server, expose a single Actor that reads US food-establishment health inspections, and turn "did this place pass its last inspection?" from a guess into a live lookup against the public inspection record. By the end you will have a working food-safety 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, andcall-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 US Restaurant Inspections Scraper: Food Establishments. It searches public US food-establishment inspection records and returns, per inspection: the business name (DBA and AKA), license number, facility type, risk level, full address with geo coordinates, inspection date and type, the pass/fail result, a violation count, and a full violations summary with the inspector's comments.
That field set is exactly what a food-safety or marketplace-trust check needs. You can filter by establishment name, city, result, and date range, so a query can be as narrow as "every failed inspection for this one cafe" or as broad as "all inspections in this city last month."
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/usa-restaurant-inspections-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/usa-restaurant-inspections-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--usa-restaurant-inspections-scraper
That last entry, scrapers_lat--usa-restaurant-inspections-scraper, is our food-safety 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 to check an establishment
Now the payoff. In a normal chat, ask a question that requires ground truth:
"We're onboarding a Starbucks-branded cafe at the Palmer House in Chicago onto our delivery marketplace. Pull its latest health inspection record so I can check for any recent failures."
Claude recognizes it cannot answer this reliably from memory, selects the inspections 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--usa-restaurant-inspections-scraper",
"arguments": {
"searchQueries": ["Starbucks"],
"cities": ["CHICAGO"],
"maxInspections": 20
}
}
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": "7NUszN8Ahes7pybfI",
"actorName": "scrapers_lat/usa-restaurant-inspections-scraper",
"status": "SUCCEEDED",
"startedAt": "2026-07-30T17:47:30.797Z",
"finishedAt": "2026-07-30T17:47:35.233Z",
"stats": { "runTimeSecs": 4.3 }
}
Under five seconds, live against the public inspection record.
Step 5: Read the real output
The dataset the tool returns is structured inspection data, one object per inspection. This is an actual record from the run (trimmed to the fields that matter for a trust check):
{
"inspectionId": "2632789",
"dbaName": "STARBUCKS PALMER HOUSE",
"licenseNumber": "2948168",
"facilityType": "Restaurant",
"risk": "Risk 2 (Medium)",
"result": "Fail",
"inspectionType": "Complaint",
"inspectionDate": "2026-03-19T00:00:00.000Z",
"address": "17 E MONROE ST",
"city": "CHICAGO",
"state": "IL",
"zip": "60603",
"violationCount": 14,
"violationsSummary": "38. INSECTS, RODENTS, & ANIMALS NOT PRESENT - Comments: OBSERVED EVIDENCE OF 3 LIVE ROACHES ... (CITATION ISSUED) | 2. CITY OF CHICAGO FOOD SERVICE SANITATION CERTIFICATE - Comments: OBSERVED NO CERTIFIED FOOD MANAGER ON DUTY WHILE TCS FOODS ARE BEING PREPARED ... (CITATION ISSUED)"
}
Claude reads that and answers in plain language: the Palmer House Starbucks (17 E Monroe St) failed its 2026-03-19 complaint inspection with 14 violations, three of them carrying citations, including live roaches, no certified food manager on duty, and an employee handling food without washing hands after mopping. A previous core violation was flagged as not corrected. Every one of those facts is traceable to an official inspection report, not the model's memory.
The full-history view is just as important. The same query returns the follow-up re-inspections on 03-26 and 03-30 that also failed, so an analyst can see at a glance that the problems were not resolved on the first re-check. The single most recent record can look clean; the inspection trail tells the real story.
A real use case: a marketplace onboarding agent
Put this in context. A trust and safety analyst at a food-delivery marketplace is activating a batch of new restaurant listings and needs to confirm, before any of them go live, that each establishment:
- has a real, current inspection on file,
- is not sitting on an unresolved failed inspection, and
- does not have a pattern of repeat critical violations (pests, no certified manager, temperature abuse).
Without a tool, the analyst opens the city inspection portal, types each name, reads the latest report, and copies the result into an onboarding sheet, once per restaurant. With the tool wired into Claude, the analyst pastes the batch into the chat and asks the agent to check each one. Claude calls the Actor per establishment, sorts the returned inspections by date, flags any recent Fail or Pass w/ Conditions, counts repeat violations, and produces a short activate/hold note with the inspection ID as evidence. The manual lookup step disappears; the judgment stays with the human.
The same shape works for an insurer pricing food-service coverage, a franchisor auditing licensees, or a consumer-facing app that wants to show a live safety badge next to each listing. The mechanical fetch is removed; the decision is not.
Going further: chain a second tool
Inspection history answers "is this kitchen clean," but food-safety risk does not stop at the door. A brand can pass every inspection and still be shipping a product under recall. The same MCP connection can expose more Actors by extending the tools parameter:
https://mcp.apify.com?tools=scrapers_lat/usa-restaurant-inspections-scraper,scrapers_lat/openfda-food-recalls-scraper
Now the agent can check an establishment's inspection record and screen the brands or products it serves against the openFDA Food Recall & Enforcement Scraper in the same conversation, then combine both into one risk summary: local hygiene from the inspection record, product-level recalls from the federal enforcement feed. 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 a single onboarding check the cost is a fraction of a cent; if you plan to sweep thousands of establishments on a schedule, run the Actor directly through the Apify API or a scheduled task instead of one call per chat message. Coverage is strongest in jurisdictions that publish inspection data openly, such as Chicago and New York City, so match your cities filter to where the establishment actually operates.
Wrapping up
You now have an AI agent that can check a US food establishment against its official inspection record, on demand, mid-conversation, with the violation detail and pass/fail history a real trust decision 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 or widen the query with the
cities,results, and date-range filters to build anything from a single-store check to a citywide sweep. - Add the food-recall Actor above, or a business-registry Actor, to build a multi-signal food-safety and vendor-vetting agent.
- Read the Apify MCP server docs for OAuth setup, resource reads, and the
search-actors/call-actortools that let an agent discover Actors it was not preconfigured with.
The Actor used in this guide: US Restaurant Inspections Scraper: Food Establishments.
Top comments (0)