DEV Community: Michael

I let an AI agent reconcile a drug's FDA label against its real-world reports. The mismatch was the point.

Michael — Mon, 03 Aug 2026 15:25:58 +0000

This is a story about an experiment that went the right kind of wrong. Naomi, a pharmacovigilance analyst at a health-tech company, wanted to see whether an AI agent could do the least glamorous part of drug-safety work: take a medicine, pull what people actually report about it, pull what its official label already warns about, and lay the two side by side. Not to reach a verdict. To surface where they agree, where they diverge, and where a human needs to look harder.

Everything below is a real setup with real output. Every report ID, reaction count, boxed warning, and run ID is a live lookup against FDA data, captured from an actual chat. Nothing is mocked. And because this touches drug safety, one rule is stated up front and never bent: FDA adverse-event reports are unverified and do not establish causation. This is research and triage, not medical advice.

The setup

Naomi's job is signal triage. A drug comes across her desk and she needs two pictures of it, fast. The first is the field picture: the FDA Adverse Event Reporting System (FAERS), a public database of what patients, clinicians, and manufacturers have reported after someone took a drug. The second is the reference picture: the drug's approved FDA label, the manufacturer's own document of what the drug is for and what it warns against, including the boxed warning at the top.

The hard part was never fetching either one. It was holding them in the same frame. A recurring reaction in the reports is only interesting if you know whether the label already flags it. A reaction the label features heavily is only reassuring if it actually shows up in the reports. Doing that by hand means two portals, two exports, and a spreadsheet where the columns never quite line up. It is exactly the mechanical work that gets skipped when a queue is deep.

So Naomi wired both data sources directly into Claude as tools, using the official Apify MCP server, and let the model do the fetching and the lining-up. Setup was one config block and a restart.

The two tools she connected:

The openFDA Drug Adverse Events & Recalls Scraper returns FAERS safety reports as structured records: the report ID, patient sex and age, the reactions, the seriousness flag and its reasons, and the full drug list, each drug marked suspect or concomitant.
The openFDA Drug Labels & Ingredients Scraper returns the structured FDA label: boxed warning, contraindications, warnings and precautions, and the adverse reactions the manufacturer already lists.

Both exposed to Claude through one MCP endpoint. Nothing else changed about how she works: she opens a chat and asks in plain English. The drug she picked to test the idea was metformin, the most-prescribed type 2 diabetes medicine in the country and a drug she knew well enough to catch the agent if it drifted.

What the reports actually say

She started with the field picture. Not "is metformin dangerous" (a question no honest tool should answer), but the concrete triage questions: how many reports are serious, which reactions recur, and, crucially, in how many is metformin the drug the reporter actually blamed.

Claude called the FAERS tool, pulled forty live reports (run LJtWYBdN8DahaKbWK), and came back with a picture that was more honest than a headline. Twenty-six of the forty were flagged serious. The recurring reactions were not the ones a layperson would guess: off-label use appeared six times, maternal exposure during pregnancy five, then fatigue, headache, and a cluster of gastrointestinal complaints and acute renal events.

Then the part that made the exercise worth running. The agent flagged, on its own, that in nearly every one of those reports metformin was marked concomitant, not suspect. It was on the patient's medication list, but the reporter pointed at a different drug. In report 10004089, a hospitalized 46-year-old man with acute renal failure, the suspect was Ampyra. In a fatal report, 10004186, the suspect was Jakafi. In report 10005223, a physician's report of diarrhoea and abdominal pain, the suspect was Humira. Metformin was a bystander in all three.

This is the distinction that a summary from memory flattens and a keyword search hides. A naive count of "reports mentioning metformin" would have inflated every one of these into a metformin signal. The structured characterization field let the agent say the honest thing: the reactions are real in the data, but this batch does not pin them on the drug. Every claim carried a safetyReportId you can open in the FAERS record.

What the label warns about

Next, the reference picture. Naomi asked the agent to pull metformin's official FDA label and tell her what it actually warns about.

One tool call later (run S5ILrX5tSt5q5Dbks), the agent read back the prescription label, effective 2024-08-21. The headline is a boxed warning for lactic acidosis, rare, potentially fatal, with a deliberately subtle onset: malaise, myalgia, abdominal pain, somnolence. Its named risk factors are renal impairment, age 65 and over, and contrast imaging. Below that, contraindications (severe renal impairment, hypersensitivity, metabolic acidosis), further warnings for vitamin B12 deficiency and hypoglycemia when combined with insulin, and the most common adverse reactions the manufacturer lists at over five percent: diarrhea, nausea and vomiting, flatulence, asthenia, indigestion, abdominal discomfort, and headache.

That is the manufacturer's own reference, pulled live, not a paraphrase from training data that might be a label revision or two out of date.

The reconciliation

Then the payoff, and the reason the experiment was bolder than a single lookup. Naomi asked the agent to reconcile the two: for each reaction, did it show up in the FAERS pull, and does the label already flag it? And to say honestly where they diverge.

The agent built the table from both runs and did not smooth over the seams. The middle of the table agrees cleanly: the diarrhoea, abdominal pain, nausea, headache, and fatigue in the reports are all reactions the label already lists as common. Reassuring, and exactly what you would hope to see: the field data and the reference document telling the same story about the routine stuff.

The edges are where it earned its keep. Acute renal impairment turned up in three reports; it is not a listed adverse reaction, but it is both a contraindication and the top risk factor for the boxed-warning event, so the agent marked it partly on the label rather than forcing a yes or no. Off-label use and pregnancy exposure, the two most frequent signals in the pull, are not adverse reactions at all. The label treats them as prescribing context. And the single most important row: lactic acidosis, the label's headline boxed warning, did not appear once in the forty-report sample.

That last mismatch is the finding, and it cuts both ways honestly. The rarest, most serious risk the manufacturer leads with was invisible in a small recent sample, which is exactly what you would expect from a rare event, and exactly why you never read absence in FAERS as safety. Meanwhile the sample's loudest signals were things the label does not frame as reactions at all. Neither document is wrong. They are answering different questions, and the value of the agent was making that legible in one table instead of two disconnected exports.

Why this is the honest version

It would have been easy to build a flashier demo, an agent that "detects safety signals" or "audits a drug label." That agent would be a liability. The reason this one is worth showing is that it is bounded by what the data can actually support:

It separates mention from cause. The suspect-versus-concomitant read is baked into every answer, so a report is never silently upgraded into a signal.
It refuses to over-read absence. Zero lactic-acidosis reports in a small sample is reported as a fact about the sample, not a claim about the drug.
It cites everything. Every reaction points back to a safetyReportId; every label claim to a run and an effective date. An analyst can open the source in one click.
It stays in its lane. The output is triage over unverified reports to help a trained reviewer look in the right place. It is not a diagnosis, a verdict, or medical advice, and the agent says so.

Naomi's judgment never moved to the machine. What moved was the reconciliation grind: the two portals, the mismatched columns, the reaction she would have had to manually check against the label one at a time. The agent did the lining-up in under a minute and handed her a table she could defend line by line.

Build the same agent

Everything here is reproducible today with a free Apify account and any MCP-capable client (Claude Desktop, Cursor, or your own agent):

Get your Apify API token from the Apify Console under Settings → Integrations.
Add the official Apify MCP server to your client and list both Actors in the tools parameter:

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

Restart the client and ask it, in plain English, to pull the FAERS reports and the label for a drug and reconcile them. It picks the right tool for each step.

📌 Note: each tool call is a real Actor run billed to your Apify account (both are pay-per-result, a fraction of a cent per lookup). For continuous monitoring across many drugs, run the Actors on a schedule through the Apify API instead of one call per chat.

🏹 A word on interpretation: FAERS is a spontaneous-reporting system. A report means someone submitted it, not that the drug caused the event; many reports come from consumers, the same case can list a dozen drugs, and duplicates exist. Absence of a reaction in a sample is not evidence of safety, and presence is not evidence of harm. The agent's job here is fast, auditable access to the raw reports and the label so a qualified reviewer can do the interpreting. Keep that framing and the tool earns its place. This is not medical advice.

The Actors used in this story: openFDA Drug Adverse Events & Recalls Scraper and openFDA Drug Labels & Ingredients Scraper.

Is this flat overpriced? I let Claude check the asking price against what actually sold.

Michael — Mon, 03 Aug 2026 15:25:12 +0000

Every property listing is a number with a story attached. "Renovated." "Huge." "Near the MRT." "Priced to sell." The one thing the story never tells you is whether the number is fair, because the only honest answer to that lives somewhere the seller has no incentive to show you: the record of what flats exactly like this one have actually changed hands for.

So I ran an experiment. I gave Claude two live data sources through the official Apify MCP server, pointed it at a real HDB flat on the market in Singapore, and asked it to do the one thing a buyer never has time to do properly at a viewing: compare the asking price against genuine recent transactions for the same segment, and tell me the truth. Not a mortgage calculator. Not a vibe. A verdict backed by numbers.

Everything below is real. A live listing pulled from the market, six hundred real resale transactions, actual run IDs. No mocked screens, no invented comps. I picked the flat, wired the tools, and let the agent make the call.

The setup

Here is the problem with buying a resale flat. You stand in someone's living room for fifteen minutes. The agent is friendly, the place smells like fresh paint, and there is a number on the table. Is it fair? You genuinely do not know. You have a gut feeling shaped by whatever three listings you half-remember from scrolling last night, and the agent has every transacted comparable in the district memorised. It is not a fair fight.

The data to level it exists and is public. Singapore's HDB publishes every resale transaction: town, flat type, block, floor area, lease year, storey, and the exact price it sold for. The problem was never access. The problem is that nobody, in the pressure of a viewing, opens a spreadsheet of six hundred sales, filters it down to the flats that genuinely match the one in front of them, and works out a median. So I wired that work into Claude and let it do the fetching and the maths.

The two tools I connected, both through one official Apify MCP endpoint:

The Singapore HDB Resale Flat Prices Scraper returns real transacted resale prices for any town and flat type: block, street, storey, floor area, remaining lease, resale price, and price per square foot.
The Singapore PropertyGuru Listings Scraper returns live asking listings: title, asking price, floor area, price per square foot, property type, and location.

One is the market's asking. The other is the market's reality. The whole experiment is putting them side by side.

Step one: pull the live listing

I did not want to argue with a screenshot, so the first thing I asked Claude to do was fetch the flat's real, current listing figures straight from the market rather than trust my typing.

Two seconds of tool call, and the flat was on the table with its numbers locked: a 4-room HDB in Tampines, near Tampines East MRT, asking S$620,000 for 1,087 sqft, a headline S$570.38 per square foot. That last figure is the one that matters, because price alone tells you nothing when floor areas differ. Price per square foot is how you compare a 1,087 sqft flat to one that is 1,000 or 1,200.

And here is where the trap opens. S$570 psf, for Tampines, sounds cheap. If your mental benchmark is "4-room flats in mature towns go for six-something a foot," this looks like a flat priced under the market, the kind of listing you rush to view before someone else grabs it. Claude flagged exactly that instinct and refused to trust it: "cheap only means something against what flats like this one actually sold for." Then it offered to go and find out.

Step two: compare it to what actually sold

This is the part I could never do at a viewing, and the part the agent does in one tool call. I told it to pull the recent transacted resale prices for the same segment and give me a straight answer: fair, or overpaying?

It pulled 600 real Tampines 4-room transactions spanning January 2025 to July 2026, and then it did the thing that separates an analyst from a calculator: it noticed the naive comparison was a trap and controlled for it.

Against every 4-room flat in Tampines, the median was S$608.63 psf. Measured that way, the listing's S$570 looked like a 6% discount, confirmation that this was a steal. But most of those 600 sales are newer flats with 90-plus years left on the lease, and lease age is the single biggest lever on an HDB flat's price per foot. The flat I was looking at is a 1980s-vintage, ~1,087 sqft unit, an older, larger Model A. Comparing it to a decade-newer flat is not a comparison at all.

So Claude filtered to the genuine like-for-like set: same size band, same lease era. 218 real sales of 1,000 to 1,200 sqft, 1980s-lease 4-room flats in Tampines. The median for that group (the flats that actually resemble the one on offer) is S$566.36 psf.

And the whole picture flips:

Against all 4-room flats: −6.3%, a bargain.
Against its true comparables: +0.7%, dead-on market.

The "discount" was never a discount. It was the older-lease haircut that every flat of this vintage carries. Priced against its actual peers, S$570 psf is the market clearing price, not a gift.

Claude backed the verdict with the receipts, three near-identical flats in the same cluster of blocks that sold in July 2026:

886 Tampines St 83 (1988 lease, 1,119 sqft) → S$635,888 at S$568 psf
852 Tampines St 82 (1985 lease, 1,119 sqft) → S$650,000 at S$581 psf
418 Tampines St 41 (1985 lease, 1,130 sqft) → S$620,000 at S$549 psf

Same size, same era, same town, sold within the last month. The asking flat sits right in that band, near the top of it. At the median psf of its true comps, the flat is worth about S$615,600, so the S$620k ask is roughly S$4,000 over fair value, sitting at the top of the recent range rather than the middle.

The verdict, and what it's worth

The honest answer was not the exciting one. The flat is not the underpriced steal the headline psf implies, and it is not overpriced either. It is priced about right, arguably S$4k rich, sitting at the ceiling of what its true comparables have fetched. That is genuinely useful, because it changes how you walk into the room. You are not chasing a bargain that will vanish, and you are not being fleeced. You have a specific, defensible number (around S$610,000) and three real recent sales to point at if you want to negotiate toward it.

That is the whole shift. A viewing usually runs on the seller's information and your gut. Here the buyer walks in with the same transacted data the agent has, distilled to a one-line verdict and a table of comps, in the time it takes to read a chat reply.

I want to be precise about what this is and is not. It is a data-driven estimate from live transactions, not a formal valuation. Price per square foot captures size and lease and town, but it cannot see the things that move the last few thousand dollars: which storey the unit is on, which way it faces, whether the renovation is genuinely done or lipstick, how motivated the seller is. A bank valuer weighs those. What the agent gives you is the evidence base those judgments should sit on top of, the difference between "I think it feels a bit high" and "it's 0.7% above the median of 218 real comparable sales, here are the closest three." One of those sentences wins a negotiation.

Build the same agent

Everything above is reproducible today with a free Apify account and any MCP-capable client (Claude Desktop, Cursor, or your own agent).

Get your Apify API token from the Apify Console under Settings → Integrations.
Add the official Apify MCP server to your client and list both Actors in the tools parameter:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/singapore-hdb-resale-prices-scraper,scrapers_lat/singapore-propertyguru-scraper",
      "headers": { "Authorization": "Bearer YOUR_APIFY_TOKEN" }
    }
  }
}

Restart the client, then hand it a listing in plain English: paste the asking price, floor area, town and flat type, and ask whether it is fair against recent transactions. The agent picks the listing tool to confirm the asking figures, then the resale tool to fetch the comps, and does the maths.

📌 The key instruction is "compare like for like." The single most valuable thing the agent did was refuse the all-flats median and filter to the same size and lease era. Tell it explicitly to match floor area and lease year, or it may hand you the flattering 6% "discount" instead of the real 0.7%. The data is only as honest as the segment you compare against.

🏹 Extend it. The same pattern scales to any town or flat type: query town: "BEDOK" and flatType: "5 ROOM", or point it at a whole shortlist and ask for the one priced furthest below its comps. Add the Singapore Property Guru rental angle to check rental yield, or the broader Singapore data set of registry and market Actors to layer in more context. Every extra tool is one more line in the tools list and zero new code.

The Actors used in this experiment: Singapore HDB Resale Flat Prices Scraper and Singapore PropertyGuru Listings Scraper.

Paste the VIN. The agent reads a used car's secrets back to you in plain English.

Michael — Mon, 03 Aug 2026 15:20:18 +0000

Buying a used car is one of the biggest checks most people write without a second opinion. The seller knows more than you do. The listing is written to sell. And the two databases that would actually tell you the truth about the car sitting in the driveway are public, free, and completely unreadable to a normal human being.

This is a story about closing that gap with one sentence: "Here's the VIN." No mocked screens, no toy data. Every specification and recall campaign below is a real lookup against live U.S. government records, captured from an actual chat.

The problem with buying used

Marcus is a first-time EV buyer. He found a 2018 Tesla Model 3 on a marketplace, priced a little under the others, and he has exactly one advantage the seller doesn't expect him to use: the seller texted him the VIN.

A VIN is the car's fingerprint. Two U.S. government databases can turn those seventeen characters into the truth about the vehicle:

The NHTSA vPIC database decodes the VIN into the real make, model, year, trim, drivetrain and factory-installed safety equipment. It settles what the car actually is, regardless of what the listing claims.
The NHTSA recalls database lists every open safety recall for that make, model and year, including the ones that never got fixed.

Both are free. Both are also built for engineers and insurers, not for a nervous buyer standing in someone's driveway on a Saturday. The data exists; the plain-English answer doesn't.

So instead of learning to read government JSON, Marcus did the thing anyone with a Claude account can do in twenty minutes: he wired both databases into Claude as tools using the official Apify MCP server, and then just talked to it like a knowledgeable friend.

The first tool he connected:

The NHTSA VIN Decoder & Vehicle Specs Scraper turns a VIN into the full factory spec sheet.
The NHTSA Recalls Scraper returns every recall campaign on record for a given make, model and year, with the safety consequence and the fix.

Two public databases, one chat window. Nothing to install on the car, no subscription, no salesperson. Marcus opens Claude and types the way he'd text a friend who happens to know cars.

"What is it, in plain English?"

He starts with the only fact he has. He pastes the VIN and asks what the car actually is.

The agent doesn't lecture. It runs the decode, then translates seventeen characters into a picture a human can hold: a 2018 Tesla Model 3, a single-motor Standard Range electric sedan, built in Fremont, California, that stickered around $46,000 new. It reads back the safety equipment that came standard on the car (automatic emergency braking, blind-spot monitoring, lane-keep assist, a backup camera, stability control) and notes, plainly, that this is a strong set for the model year.

Then it does the thing a good second opinion does: it flags something small but real. The VIN's built-in check digit doesn't validate cleanly. The agent doesn't dress it up as fraud. It explains that this is common for early-production and sample VINs, and gives Marcus one concrete action: confirm the VIN on the door-jamb sticker and the title exactly matches the one the seller texted. That is the difference between a data dump and advice.

Every field in that answer came from a real Actor run (2AbJcEVY9gWPpHAeD), not from the model's memory of what a Model 3 usually is. If the seller had quietly listed a base car as a Long Range, or fudged the year, the decode would have contradicted the listing on the spot.

Marcus didn't have to know that the vPIC database exists, or what "electrification level" means. He asked a question in English and got an answer in English. But identity is only half of a safe purchase. The agent knows that, and offers the second half itself: want me to check whether this car has any open safety recalls?

"Are there recalls, and what do I say to the seller?"

This is the question that actually protects Marcus's money and, more to the point, his safety. He says yes, and asks the thing every buyer is too polite or too unsure to ask: what does he actually say to the seller?

The agent runs the recalls lookup (7YfhB7mRkYSTgqQ4x) and comes back with a number that would scare anyone off cold: 18 recall campaigns on record. And here is where the agent stops being a search box and starts being a second opinion. It doesn't dump eighteen scary paragraphs. It reasons about the data on Marcus's behalf and sorts it into what matters and what doesn't:

14 of the 18 were fixed over the air: software updates the car downloads on its own. If the car has been online, they're already done. Nothing to chase.
4 need a physical shop repair. These do not fix themselves, and these are the only ones Marcus has to care about.

Then it names the four in plain terms, leading with the scary one: a front suspension recall (campaign 23V235000) where a lateral link fastener can loosen and let the suspension separate from the frame. It is safety-critical, and specific to 2018-2019 Model 3s. Plus a front seat-belt fastener recall (21V389000), a rear seat-belt anchor recall (22V798000), and a rearview camera cable recall (21V00D000). All four repaired free at any Tesla service center.

And then the payoff, the part no database gives you. The agent writes the exact message to send the seller:

"Hi, before I come see the car, can you send me the service records showing recalls 23V235000 (front suspension) and 21V389000 (front seat belt) were completed? If you're not sure, I can look up the VIN's recall status together, or we can swing by a Tesla service center. Just want to make sure the safety recalls are closed out."

That is the whole product. A used-car buyer with no mechanical knowledge now has a specific, polite, informed ask (with campaign numbers in it) that turns "I guess it's fine" into leverage. As the agent points out: if the seller can't prove those two repairs were done, that's not a dealbreaker, it's a discount. The fixes are free. What Marcus can't afford is to drive off not knowing.

The cheat sheet in his pocket

Before he leaves for the viewing, Marcus asks for one thing he can keep on his phone.

The agent consolidates both lookups into a single dossier: what it checked, what the official record says, and what Marcus should do about each line. Identity confirmed. Safety features solid for the year. Fourteen recalls already handled by software. Four that need proof of repair. One VIN check-digit to verify against the door jamb. Two databases, one glance, every row traceable to a real government record rather than anyone's opinion.

The bottom line the agent gives him is the one a trusted friend would: the car is what the seller says it is, the safety kit is good, and the only real homework is the suspension and seat-belt recalls. Do that, and he's buying with his eyes open.

Why this matters beyond one buyer

Marcus is the obvious audience, but he's not the only one. The interesting reader here is the marketplace or insurer who could embed this exact agent.

A used-car marketplace could put a "paste the VIN" box on every listing and hand every buyer this second opinion automatically, closing the information gap that makes people distrust private-party sales in the first place.
An insurer or a warranty provider could screen a VIN for open safety recalls at quote time, in plain language, without building a data pipeline against two government sources.
A neighborhood mechanic could run it on a customer's behalf and print the dossier.

The point of the experiment isn't that the data was hard to get. It's public. It's that the judgment layer on top of the data used to require a human who knew cars, knew which recalls fix themselves, and knew what to say to a seller. That layer is now a conversation.

Build the same agent

Everything above is reproducible today with a free Apify account and any MCP-capable client (Claude Desktop, Cursor, or your own app):

Get your Apify API token from the Apify Console under Settings → Integrations.
Add the official Apify MCP server to your client and list both Actors in the tools parameter:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/nhtsa-vin-decoder-scraper,scrapers_lat/nhtsa-recalls-scraper",
      "headers": { "Authorization": "Bearer YOUR_APIFY_TOKEN" }
    }
  }
}

Restart the client, paste a VIN, and ask it, in plain English, to decode the car and check for recalls. It will pick the right tool for each step and reason across both.

📌 Note: each tool call is a real Actor run billed to your Apify account (both are pay-per-result, a fraction of a cent per lookup). To offer this at scale on a marketplace, call the Actors through the Apify API behind your own "paste the VIN" box instead of one call per chat.

🏹 Extend it: the same pattern grows into a full pre-purchase agent. Add a used-car listings source to compare the asking price against the market, or a title and odometer source, and the agent goes from "what is this car" to "should you buy this car, at this price", all over live data, by adding one more Actor to the tools list, with no new code.

The Actors used in this story: NHTSA VIN Decoder & Vehicle Specs Scraper and NHTSA Recalls Scraper.

I asked an AI agent whether NVIDIA insiders were selling. It read the filings and found one director.

Michael — Mon, 03 Aug 2026 15:19:31 +0000

I run a small event-driven book, and the question I get asked most on any big name is also the one that's hardest to answer honestly: are the insiders selling? Not "is there a scary headline about insider sales," but the real thing. Who sold, how much, was it a decision or a formality, and does it actually mean anything.

If you ask a language model that question cold, you get a fluent paragraph that is worse than useless: confidently phrased, months out of date, and occasionally invented. Insider transactions are a matter of public record, filed on SEC Form 4 within two business days of the trade. There is a right answer sitting in the filings. So this time I didn't ask Claude to know the answer. I gave it the filings and asked it to read them for me.

What follows is a real session. Every number below came out of live SEC data during the chat, through the official Apify MCP server. No mocked screens, no cherry-picked record. The interesting part is not that the agent fetched some data. It's what it did with it.

The one thing I wired up beforehand

The setup is embarrassingly small. Apify's Store has an Actor that reads SEC Form 4 filings and returns each insider transaction as a clean, structured record. I connected it to Claude as a tool through the official Apify MCP server, which turns any Apify Actor into something the model can call mid-conversation. One line of config, one restart. After that, Claude can pull insider filings on its own whenever a question needs them.

The Actor is the SEC Form 4 Insider Trading Transactions Scraper. Give it a ticker and it returns, per transaction: the insider's name and role, the transaction code and type (open-market buy, open-market sale, grant, gift, tax withholding), the number of shares, the price, the total value, how much of the insider's stake it moved, and whether it ran under a Rule 10b5-1 plan. That last field is the one that separates a real signal from noise, and I'll come back to it. The point is that the agent doesn't get a headline. It gets the same fields a filing does, and it has to reason over them.

Asking the real question

So I asked it the real question, the way I'd ask a junior analyst: don't guess, pull the filings, and tell me what's genuine trading versus routine noise.

The first thing it did was the thing most people skip. It pulled 40 real transactions and, before saying anything about a "signal," sorted them by transaction code. This matters more than it sounds. A Form 4 marked as a "disposal" is very often not someone choosing to sell:

11 were code A: stock grants to the board and officers, zero cash. Not selling.
8 were code F: shares handed back to cover taxes when awards vested, all on the same day, including CEO Jensen Huang and CFO Colette Kress. This is payroll mechanics, not a market call.
3 were code G: gifts, including a 400,000-share gift by the CEO. A transfer, not a sale.
18 were code S: actual open-market sales. This is the only bucket that carries information.

An analyst who reads "insider disposed of shares" across all 40 of those and panics has misread the filing. The agent didn't. It said, in effect: strip the housekeeping, and the honest headline isn't "insiders are dumping," it's that there are eighteen genuine sales worth looking at, and they look concentrated. Then it offered to go deeper. That framing (noise first, signal second) is exactly what I want and rarely get from an automated tool.

Making it characterize the pattern

A count of sales is still not an answer. Eighteen sales could be the whole C-suite trimming a little, or one person doing something unusual. Those mean opposite things. So I asked it to roll the open-market selling up by person, and to tell me for each whether the sale was discretionary or ran on a pre-set Rule 10b5-1 plan.

This is the shot that changed my read of the name. Rolled up by person, five insiders sold on the open market since January, but the values are wildly lopsided: Mark A. Stevens at roughly $445.6M across 2,106,682 shares, then a steep drop to Aarti S. Shah at $3.36M, Stephen C. Neal at $3.34M, Donald F. Robertson Jr at $0.94M, and John Dabiri at $0.13M. Next to each name, the agent put the field that actually carries the signal: was the sale discretionary, or run on a pre-scheduled Rule 10b5-1 plan.

The characterization the agent gave was sharper than "insiders sold $460M of stock," which is the kind of line that ends up in a scary headline. It said: this is not a broad insider exodus. It is essentially one director. Mark A. Stevens accounts for about 99% of the open-market sale dollars, seven trades, all off-plan (discretionary, not on a 10b5-1 schedule), clustered in two waves: a bit in late March, then a heavy June (500,000 shares on the 2nd, another 500,000 on the 4th, 885,000 on the 18th). One June block alone trimmed 6.76% of his own position. Everyone else who sold was small, and three of the four sold under pre-scheduled 10b5-1 plans, which carry little signal by construction. The CEO and CFO you might expect to see selling into a high? Not one open-market sale between them. They appear only for tax withholding.

That is a genuinely different story than the aggregate number tells. "The board is bailing" would be wrong. "One director has been selling large, discretionary blocks" is right, and it's specific enough to actually do something with, like read his filing history, or check whether it's a known diversification pattern.

Context, and being honest about the limits

The last thing I did was the part that keeps this from turning into a conspiracy board. I asked whether any of the selling lined up with company disclosures, and (explicitly) to be blunt about what this signal does and doesn't tell me. Because the same MCP connection can expose more than one Actor, the agent reached for a second tool without being told which one.

It pulled NVIDIA's recent 8-Ks and noted one honest timing coincidence: Stevens' largest single-day selling, roughly $186M across two blocks on 2026-06-18, fell on the same day the company filed an 8-K (Item 8.01, Other Events). It flagged the date and immediately declined to draw a line through it. Then it said the thing I most needed it to say, unprompted:

This is a faster way to read the public record. It is not investment advice, and it is not a claim that anyone did anything wrong. Off-plan open-market sales by a director are legal and ordinary: people sell for taxes, diversification, estate planning, a new house, and a hundred reasons that have nothing to do with a view on the stock. "Discretionary versus 10b5-1" is a factual box on the filing, not an accusation. A sale that happens to land on an 8-K date is a coincidence worth a footnote, not evidence of anything. Do your own diligence.

I want to be equally blunt in print: nothing here is a recommendation, and nothing here implies illegality. The value of the exercise is not a verdict. It's that a task that used to mean opening EDGAR, pulling every Form 4, decoding transaction codes by hand, and rolling them up in a spreadsheet became a three-message conversation, with the noise stripped, the outlier named, and the caveats stated out loud.

What the agent actually did

Strip the theatrics and the useful pattern is this: the agent didn't fetch a fact, it reasoned over a filing set. Three moves, in order, that I'd want from a human:

It separated signal from noise before interpreting. Grants, gifts, and tax withholding got sorted out first, so an $8-figure "disposal" that was really a payroll tax event never got mistaken for a bearish sale.
It characterized rather than aggregated. "One director is 99% of the selling, all discretionary" is an insight. "$460M of insider sales" is a number that misleads.
It stated its own limits. It named a timing coincidence and then refused to make it mean something, and it labeled the whole output as public-record summarization, not advice.

None of my judgment moved to the machine. I still decide whether Stevens' selling matters for the thesis. What moved was the mechanical, error-prone middle (the fetching and decoding and de-noising), which is exactly the part a person under time pressure gets wrong.

Build the same agent

You can reproduce this today with a free Apify account and any MCP-capable client (Claude Desktop, Cursor, or your own agent):

Get your Apify API token from the Apify Console under Settings → Integrations.
Add the official Apify MCP server and list the Actors you want in the tools parameter. For the insider-activity agent above, that's the Form 4 Actor plus the EDGAR filings Actor for context:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/sec-form4-insider-trades-scraper,scrapers_lat/sec-edgar-filings-scraper",
      "headers": { "Authorization": "Bearer YOUR_APIFY_TOKEN" }
    }
  }
}

Restart the client and ask it, in plain English, whether a company's insiders have been buying or selling, and to separate real open-market trades from grants and tax withholding. It will pick the right tool, pull the filings, and characterize the pattern.

📌 Note: each tool call is a real Actor run billed to your Apify account (this one is pay-per-result, a fraction of a cent per lookup). To watch a whole basket of tickers continuously, run the Actor on a schedule through the Apify API instead of one call per chat.

🏹 Extend it: widen the window with dateFrom on a name with heavier activity, or pin the agent to one behaviour by passing transactionCode (P for open-market buys, S for open-market sales) so it never sees the housekeeping in the first place. Add more Actors to the tools list and the same agent covers more of the disclosure surface without a line of new code.

The Actors used in this piece: SEC Form 4 Insider Trading Transactions Scraper and SEC EDGAR Filings Scraper. Everything shown is real output from live runs, and none of it is investment advice.

I gave Claude four compliance tools and one prompt. It built the due-diligence memo itself.

Michael — Mon, 03 Aug 2026 15:14:34 +0000

This is an experiment, and I want to be precise about what it does and does not prove. I connected Claude to four live compliance data sources through the official Apify MCP server, gave it a single plain-English instruction, and watched to see whether it could run a real due-diligence check end to end: decide which sources to query, run them, cross-reference the results, score the risk, and hand back a memo where every claim points at a source.

No mocked screens. Every registry record, sanctions hit, and SEC filing below is a real lookup against a live source, captured from an actual chat, with the Apify run ID printed next to it so you can reproduce it. The interesting part is not that a tool returned data. It is that nobody told Claude which tools to call or in what order. It read the request, picked the checks, and organized the evidence on its own.

The bold version of the pitch: due diligence in one prompt. You name a company, the agent builds the dossier.

The four tools I wired in

A due-diligence check on a counterparty is really four separate questions, each answered by a different authority:

Is the legal entity real and currently active? A name on an invoice proves nothing. Companies dissolve, get wound up, or never existed under the name on the paperwork.
Is the party on a US sanctions list? Wiring money to an entity on the US Treasury's OFAC list is a strict-liability federal offense. "We didn't know" is not a defense.
Is it on the EU list too? A second jurisdiction either corroborates a hit or widens the exposure.
Does it file publicly, and do the identifiers match? A company that files a 10-K with the SEC leaves a paper trail you can cross-check against the registry.

I connected one Apify Actor for each, all exposed to Claude through a single MCP endpoint:

The Sunbiz Florida Business Registry & Officers Scraper (the full registry record: legal name, status, document number, officers, registered agent, and event history).
The OFAC Sanctions List Screening Scraper screens a name against the Specially Designated Nationals (SDN) list and returns programs, aliases, addresses, and linked entities.
The EU Consolidated Sanctions List Scraper (the same screening against the European list, with regulation references and identifiers).
The SEC EDGAR Filings Scraper pulls a company's filings (10-K, 10-Q, 8-K) with the CIK, accession numbers, and filing dates.

Four tools, one config line, no glue code. Then I opened a chat and typed a sentence.

One prompt, and the agent decided the rest

I picked a clean subject on purpose for the first run: Publix Super Markets, the Florida grocery chain. A real, active, Florida-incorporated company that also happens to file with the SEC, a good test of whether the agent would reach for the right combination of tools without being told.

Here is the entire instruction I gave it, and what happened next:

I did not name a single tool. Claude decomposed the request into four checks and ran them in a sensible order (registry first to establish the entity, then both sanctions lists, then SEC filings), narrating its reasoning between calls. Every call is a real Apify run:

Sunbiz → run pDNlZeA1aBU6oCQrS: ACTIVE, PUBLIX SUPER MARKETS, INC., Florida Profit Corporation, document #112252, filed in 1921, with named officers (CEO Kevin S. Murphy, President John L. Goff, Jr., CFO David P. Phillips).
OFAC → run GSsSWcL3Kd2CoN63s: 0 matches.
EU consolidated list → run mOYdsujWKycKzbakB: 0 matches.
SEC EDGAR → run PDMwwh0FVfgzytjCu: a 10-K filed 2026-03-02 for the fiscal year ending 2025-12-27, under CIK 0000081061.

Then it did the thing I was actually watching for. It noticed that the EIN on the SEC filing (59-0324412) is an exact match to the FEI number on the Florida registry record. The same legal entity, confirmed by two independent government sources. Nobody asked it to reconcile identifiers across databases. It reasoned that a cross-check was worth doing and did it.

The scored dossier

Data is not a decision. The last step, and the one that usually eats an analyst's afternoon, is turning four raw results into something you can attach to a file and defend to an auditor. I asked Claude to score the risk and write it up.

It scored Publix LOW and laid out the reasoning as a table where every row carries the run ID behind it: registry PASS, OFAC CLEAR, EU CLEAR, SEC VERIFIED, and the identity cross-check MATCH. The recommendation is "proceed with onboarding," explicitly subject to human sign-off.

That last clause is not decoration. The score is a heuristic the agent applies to evidence it gathered; it is a starting point for a human, not a verdict that replaces one. What the agent removed was the mechanical labor (the tab-switching, the copy-paste, the risk of skipping a check under deadline pressure), not the judgment.

The contrast: what a bad name looks like

A clean result only means something if the same workflow catches a dirty one. So I ran the identical instruction against a name I knew would be a problem: Rosoboronexport, a Russian state arms exporter.

The agent screened the US list first, hit a match, and (instead of stopping) reasoned that a second jurisdiction was worth confirming before it reported. Both runs came back positive:

OFAC → run MLnvX5XE9E8vZYPK7: 1 SDN match. Listed as ROSOBORONEKSPORT OAO, under three programs (UKRAINE-EO13662, RUSSIA-EO14024, IRAN-CON-ARMS-EO), linked to State Corporation Rostec, at 27 Stromynka Ul., Moscow.
EU consolidated list → run wEU9R9n6McPW5SAfh: 1 match, reference EU.7808.66, programme UKR, designated 2022-03-15.

And again the agent did the cross-reference on its own. It noticed that both lists carry the same tax ID (7718852163) and the same registration number (1117746521452), meaning this is not a fuzzy name coincidence but the same legal entity, corroborated by two independent authorities. It scored the counterparty HIGH, returned a STOP verdict, and recommended blocking the party and escalating to legal. Everything a compliance officer needs to act, with the evidence already attached.

What the agent actually did, and what it didn't

I want to be honest about the boundary, because the interesting claim here is narrow and the overselling would be easy.

What the agent did:

Chose the tools. From one sentence, it decomposed the task into the right four checks and picked the matching source for each. It was not following a script.
Sequenced the work. Registry before sanctions before filings; on the sanctions hit, it confirmed a second jurisdiction before reporting rather than firing everything blindly.
Cross-referenced identifiers. It matched an EIN to an FEI across two databases, and a tax ID across two sanctions lists, without being asked, the kind of corroboration that separates a real check from a name lookup.
Scored and cited. It turned raw records into a risk band with a source run ID on every line.

What the agent did not do:

It did not make the final call. LOW and HIGH are recommendations. A human still signs off on onboarding or blocking.
It did not invent anything. Every figure came from a live source in the last few minutes, printed with its run ID. When OFAC and EU returned nothing for Publix, the agent reported "no match," not "clean," an important distinction it kept straight.
It did not replace a compliance program. Fuzzy-name edge cases, beneficial-ownership tracing, and adverse-media checks are still human work. This automates the first, mechanical pass.

That division (the fetch and the first-pass scoring are automated, the judgment and sign-off stay human) is exactly the right one, and it is why the output is audit-ready by default instead of a black box.

Build the same agent

Everything above is reproducible today with a free Apify account and any MCP-capable client (Claude Desktop, Cursor, or your own agent):

Get your Apify API token from the Apify Console under Settings → Integrations.
Add the official Apify MCP server and list the four Actors in the tools parameter:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/sunbiz-florida-scraper,scrapers_lat/ofac-sanctions-scraper,scrapers_lat/eu-sanctions-list-scraper,scrapers_lat/sec-edgar-filings-scraper",
      "headers": { "Authorization": "Bearer YOUR_APIFY_TOKEN" }
    }
  }
}

Restart the client and ask it, in plain English, to run due diligence on a company. It will pick the right tool for each question, run them, and score the result.

📌 Note: each tool call is a real Actor run billed to your Apify account, and each of these Actors is pay-per-result, a fraction of a cent per lookup. For continuous screening of thousands of counterparties, run the Actors on a schedule through the Apify API instead of one call per chat.

🏹 Extend it: the same pattern scales to any jurisdiction or check. Add UK Companies House for British entities, or a company-registry Actor for whatever market your counterparties sit in, to the tools list, and your agent covers more ground without a single new line of code.

The point of the experiment was never that a scraper can pull a record; that has been true for years. It is that a capable model, handed the right tools and one clear instruction, can now do the assembly (decide what to check, reconcile it, score it, and cite it) and leave a human with the one thing that should stay human: the decision.

The Actors used in this experiment: Sunbiz Florida Business Registry & Officers Scraper, OFAC Sanctions List Screening Scraper, EU Consolidated Sanctions List Scraper, and SEC EDGAR Filings Scraper.

The morning an AI agent caught a Takata airbag before the car hit the lot

Michael — Mon, 03 Aug 2026 15:13:47 +0000

This is a story about a used-car dealership that stopped losing an hour a day to browser tabs, because someone spent twenty minutes wiring two Apify Actors into Claude the week before. No mocked screens, no toy VINs. Every decoded spec and recall campaign below is a real lookup against a live source, captured from an actual chat.

The setup

Rosa runs inventory at a mid-size used-car dealer. Every vehicle that comes in the door (auction buys, trade-ins, wholesale lots) has to clear two checks before it can be photographed, priced, and put on the lot:

Is this actually the car the paperwork says it is? A title that reads "2003 Honda Accord" tells you almost nothing. Is it the four-cylinder sedan or the V6 coupe? Was the VIN re-stamped or transposed? The make on the door jamb is not proof of the make, the model, or the year.
Does it have an open safety recall? Retailing a used car with an unremedied recall is a liability the moment something goes wrong, and in several states it is a disclosure problem too. The Takata airbag recalls alone still cover millions of older cars sitting on lots and in auction lanes.

For years this meant Rosa kept two browser tabs open. One on a VIN decoder, one on the NHTSA recall lookup. For every car she typed the VIN, read the spec sheet, copied the make and model into the recall page, and read the campaign list. A ten-car auction run was most of a morning. The check was only as reliable as her patience on a busy day, and intake is always a busy day.

So the week before this story, she did something different. She wired both data sources directly into Claude as tools, using the official Apify MCP server, and let the model do the fetching. Setup was one config file and a restart.

The two tools she connected:

The NHTSA VIN Decoder & Vehicle Specs Scraper turns any VIN into the full spec sheet: make, model, year, trim, body class, engine, cylinders, horsepower, fuel type, and assembly plant, with a check-digit validation on the VIN itself.
The NHTSA Recalls Scraper returns every safety recall campaign for a make, model, and year: campaign number, affected component, the official summary, the remedy, and the date the recall began.

Both exposed to Claude through one MCP endpoint. Nothing else changed about how Rosa works: she still opens a chat and types in plain English.

The first car

Monday morning, four vehicles came off the weekend auction run. Rosa started with the one whose title told her the least (a plain "2003 Honda Accord") and asked Claude to decode the VIN before she wrote a word of the listing.

One tool call, and the car had an identity. The VIN decoded clean. The check digit in the ninth position was correct, which is the first guard against a re-stamped or transposed number. And it was not a generic Accord. It was a 2003 Honda Accord EX-V6 Coupe: a two-door body, a 3.0-liter V6 (engine model J30A4), 240 horsepower, five-speed automatic, built in Marysville, Ohio. That is a different listing and a different price band than the four-cylinder sedan someone might have assumed from the title.

This is the quiet part that matters. A make on a title is not a car. The decode caught the real trim and drivetrain in two seconds, and it did it the same way for every VIN, whether it was car one or car forty.

The catch

Then the check that actually stops cars from being sold. Rosa asked Claude to pull open safety recalls for that same Accord before it went anywhere near the lot.

The answer put the car on hold.

The 2003 Accord is covered by multiple recall campaigns, and the ones that matter are the Takata airbag inflators. Claude surfaced them with campaign numbers, components, and remedies attached:

19V182000: driver frontal airbag inflator. Remedy: a dealer replaces the driver airbag inflator, free of charge. The recall began April 10, 2019, and covers roughly 1.1 million vehicles.
19V501000: passenger frontal airbag inflator. Remedy: a dealer replaces the passenger inflator, free of charge. Began August 12, 2019, roughly 1.66 million vehicles.
10V364000: ignition switch interlock lever wear. Remedy: a dealer replaces the interlock pin and lever, free of charge.

Takata inflators can rupture and fire metal fragments at the people in the car; they are the defect behind multiple U.S. fatalities. Selling a used vehicle with that recall still open is exactly the exposure Rosa's manager wants avoided. Claude's recommendation was the right one: route the Accord to a Honda dealer for the free inflator replacement, get the campaigns closed, and only then list it. Nobody had to remember to run this as a separate ritual. It was one sentence in the same conversation, backed by the live recall list rather than anyone's memory of which years Takata covered.

The batch

The last step is the one that used to eat the most time: doing the same thing for the rest of the run and writing it up. Rosa asked Claude to consolidate all four inbound vehicles into a single lot / hold table she could paste straight into the intake sheet.

Four cars, four decisions, each traceable to a campaign number or a run ID:

2003 Honda Accord EX-V6: Takata airbag (19V182000, 19V501000) and ignition switch (10V364000). No, hold off lot until the airbag remedy is confirmed.
2013 Ford F-150: brake master cylinder (16V345000) and transmission control module (19V075000). Hold and book the service; the brake recall is a physical repair.
2018 Tesla Model 3: seat-belt fastener (21V389000) and front suspension link (23V235000), plus software recalls that apply over the air. Hold and verify the two physical items at a service center.
2003 Toyota Sienna: a structure recall (10V160000). Hold and verify the remedy.

The headline was uncomfortable and completely real: not one of the four inbound cars was clean. Every vehicle carried at least one open safety recall. On a busy morning, with the old two-tab process, at least one of those (probably the Accord's airbag) had a real chance of being missed.

What actually changed

Nothing about Rosa's judgment moved to the machine. She still decides what to list, what to send for service, and what to send back. What moved was the mechanical part: the tab-switching, the copy-paste between a VIN decoder and a recall page, the risk of skipping a check when the lane is full. That is the right division of labor:

The fetch is automated. Claude decodes the VIN and pulls the recall campaigns on its own, the moment the conversation needs them.
The evidence is preserved. Every line cites a campaign number or a run ID, so the intake sheet is audit-ready by default, useful the day a buyer, an insurer, or a regulator asks how the car was cleared.
The check is consistent. The agent runs the same decode-and-recall screen on every car, at 9am or 6pm, whether it is the first of the day or the fortieth.

The dissolved-shell equivalent here (a life-threatening airbag on a twenty-year-old coupe) was caught before the car ever reached a customer.

Build the same agent

Everything in this story is reproducible today with a free Apify account and any MCP-capable client (Claude Desktop, Cursor, or your own agent):

Get your Apify API token from the Apify Console under Settings → Integrations.
Add the official Apify MCP server to your client and list the two Actors in the tools parameter:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/nhtsa-vin-decoder-scraper,scrapers_lat/nhtsa-recalls-scraper",
      "headers": { "Authorization": "Bearer YOUR_APIFY_TOKEN" }
    }
  }
}

Restart the client and ask it, in plain English, to decode a VIN and check the car for open recalls. It will pick the right tool for each step.

📌 Note: each tool call is a real Actor run billed to your Apify account (both are pay-per-result, a fraction of a cent per lookup). For continuous screening of a full lot or a fleet, run the Actors on a schedule through the Apify API and feed a whole VIN list at once instead of one call per chat.

🏹 Extend it: the same pattern scales past intake. A marketplace can screen every new listing at upload; a fleet operator can re-run the recall check monthly against its VIN list; an insurer can flag open safety recalls at quote or renewal. Point the agent at a VIN list and it decodes and screens the whole book without a line of new code.

The Actors used in this story: NHTSA VIN Decoder & Vehicle Specs Scraper and NHTSA Recalls Scraper.

The cross-border vendor that almost got paid against a VAT number that did not exist

Michael — Mon, 03 Aug 2026 15:08:54 +0000

This is a story about a contract that nearly went out clean, and the twenty minutes of setup that stopped it. No mocked screens, no toy data. Every registry record, UEN, and VAT result below is a real lookup against a live official source, captured from an actual chat.

The setup

Marcus runs revenue operations at a US software company. When the business signs a new vendor, he owns the last gate before legal countersigns and finance sets up the payee. Most of the time that gate is a formality. This week it was not.

The vendor was a cross-border one, which is where these deals get slippery. The contracting party was a Singapore entity. The invoices, though, would come from a separate EU entity in France, with a VAT number on them so finance could handle the tax treatment. Two legal entities, two jurisdictions, one signature about to bind them all.

Marcus had learned the hard way that a name on a contract is not proof of anything, and a VAT number on an invoice is just a string of digits until something authoritative says otherwise. Before he would move the contract forward, two things had to be true:

The Singapore company has to be a live, registered entity, and he needs its UEN (Unique Entity Number) to set up the payee correctly, not a similarly named shell.
The EU VAT number on the invoice has to be valid and resolve to the entity that is actually billing us. If it does not, finance cannot reclaim the input VAT, and the contract is exposed at the next audit.

For years this meant two government websites, two search boxes, and a lot of squinting at screens in languages he does not read. It was reliable exactly as long as he was not rushed. Onboarding is always rushed.

So a couple of weeks earlier, Marcus had done something different. He wired both data sources directly into Claude as tools, using the official Apify MCP server, and let the model do the fetching. It took one config block and a restart.

The two tools he connected:

The Singapore ACRA Company Registry Scraper looks up any Singapore company on the official ACRA corporate register and returns the UEN, entity status, incorporation date, registered address, industry codes, and former names.
The EU VAT VIES Validation Scraper validates one or many EU VAT numbers against the European Commission's VIES service and, where the member state provides it, returns the registered trader name and address.

Both exposed to Claude through a single MCP endpoint. Nothing else changed about how Marcus works: he opens a chat and types in plain English.

Check one: is the Singapore company real?

The contracting entity on the paperwork was "DBS Bank Ltd". Marcus pasted the name into Claude and asked it to confirm the company was live and pull the UEN.

Two seconds of tool call, and he had a clean answer straight off the official register. DBS BANK LTD. came back as a Live Company, UEN 196800306E, a Public Company Limited by Shares incorporated on 16 July 1968, registered at 12 Marina Boulevard, and even carrying its former name (The Development Bank of Singapore) in the record.

But the useful part was the thing Marcus would not have thought to look for. The same search surfaced a near-namesake, DBS PTE. LTD., UEN 197700546G, that was Dissolved through a members' voluntary winding up. Claude flagged it unprompted: a different legal entity with a confusingly similar name, and it warned him to make sure the payee and the contract were set up under 196800306E, the live one, not the dead namesake sitting one row away in the register.

This is exactly the trap that catches busy teams. The name matches. The UEN does not. Set finance up against the wrong one and you have wired money to an entity that legally no longer exists. The agent caught it and said which UEN to trust, with the register as evidence.

Check two: does the VAT number hold up?

The Singapore side cleared. Now the EU billing entity. The invoice draft carried a French VAT number, and the vendor's master-data form listed two more numbers for good measure. Marcus asked Claude to run all of them through VIES and tell him which one finance could actually pay against.

The answer stopped the invoice.

The number printed on the invoice, FR99999999999, came back INVALID. VIES had no such registration. In plain terms: if finance had paid that invoice as it stood, the input VAT would not have been reclaimable and the document would have failed audit. It was not a live registration at all, just a plausible-looking string of the right length.

The corrected French number, FR40303265045, came back VALID and, better still, resolved to a real registered trader: SA SODIMAS, at 11 Rue Ampere, 26600 Pont de l'Isere. That is the piece that makes VIES more than a yes/no check. The name and address it returns are the thing Marcus can reconcile against the EU entity written into the contract. Valid and matching is the bar, not valid alone.

The third number, a German VAT (DE811193231), was VALID too, though Claude was careful to note that Germany does not return a trader name through VIES, only the confirmation, so that one has to be matched to the contract by number rather than by name. An honest caveat, surfaced without being asked, rather than a false sense of a name match that VIES never actually provided.

So the picture was: the vendor genuinely holds a valid EU VAT registration, but the number their own invoice carried was not it.

The memo

The last step is the one that used to eat the most time: writing it up so someone else can trust the decision. Marcus asked Claude to consolidate everything into a single go/no-go table he could staple to the contract approval.

Five lines, each tied to the identifier it rests on. The Singapore counterparty: GO, under UEN 196800306E. The dissolved namesake: do not use. The EU entity SA SODIMAS: GO, on a valid VAT that returns a matching name. The number actually on the invoice: NO-GO, reject and re-issue. The secondary German VAT: fine, match by number.

The bottom line the agent wrote was not "approved" and it was not "blocked." It was the precise, defensible thing: cleared to sign once the vendor re-issues the invoice against the valid VAT number. Both lookups had run against official sources that morning, and both run IDs were in the memo, so the approval file was audit-ready the moment it was written.

What actually changed

Nothing about Marcus's judgment moved to the machine. He still decides which vendors to onboard and when to hold a signature. What moved was the mechanical part that fails under time pressure:

The fetch is automated. Claude pulls the live ACRA record and runs the VAT numbers through VIES on its own, the moment the conversation needs them, in jurisdictions and languages Marcus does not have to navigate by hand.
The evidence is preserved. Every answer cites a UEN or a VAT number and the run it came from, so the output is audit-ready by default instead of a screenshot someone took and lost.
The check is consistent. The same two-part screening happens on vendor one and vendor fifty, whether or not anyone is watching the clock.

Two problems got caught before the contract went out: a dissolved namesake that could have become the payee, and an invalid VAT number that would have surfaced months later as an audit finding. On a rushed onboarding, with the old two-tab process, at least one of them slips through.

Build the same agent

Everything in this story is reproducible today with a free Apify account and any MCP-capable client (Claude Desktop, Cursor, or your own agent):

Get your Apify API token from the Apify Console under Settings → Integrations.
Add the official Apify MCP server to your client and list the two Actors in the tools parameter:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/singapore-acra-entities-scraper,scrapers_lat/eu-vat-vies-validation-scraper",
      "headers": { "Authorization": "Bearer YOUR_APIFY_TOKEN" }
    }
  }
}

Restart the client and ask it, in plain English, to verify a Singapore counterparty and validate the VAT number on its invoice. It will pick the right tool for each step.

📌 Note: each tool call is a real Actor run billed to your Apify account (both are pay-per-result, a fraction of a cent per lookup). For continuous screening of a whole vendor master, run the Actors on a schedule through the Apify API instead of one call per chat.

🏹 Extend it: the same pattern scales to any jurisdiction or check. Add UK Companies House for British counterparties, or the OFAC Sanctions List Screening Scraper to screen the same party against the US Treasury list, and your onboarding agent covers more ground without a single line of new code.

The Actors used in this story: Singapore ACRA Company Registry Scraper and EU VAT VIES Validation Scraper.

The hour before the call: how an analyst built a company one-pager from the filings, not the model's memory

Michael — Mon, 03 Aug 2026 15:08:06 +0000

This is a story about the last hour before an investment call, and the two Apify Actors that turned a scramble into a five-minute job. No mocked screens, no toy numbers. Every filing date, accession number, and insider trade below is a real lookup against the live SEC, captured from an actual chat.

The setup

Daniel does buy-side research at a fund that moves fast. When a name lands on the calendar, he has to walk into the call already fluent in it: what the company most recently told the SEC, and what the people who run it have been doing with their own shares. Two questions, both boring, both non-negotiable, and both easy to get subtly wrong under time pressure.

The trap is obvious once you have been burned by it. Ask a language model "what was in NVIDIA's latest 10-K" and it will answer confidently from training data that may be a year stale, with a fiscal period that quietly does not match the filing on record. For a one-pager that a portfolio manager will act on, "roughly right, from memory" is worse than useless. Daniel needs facts that trace back to a document with an accession number, not a plausible paragraph.

For years the manual version of this was two browser tabs. One on SEC EDGAR's full-text search, hunting for the most recent annual report and copying the filing date and period. One on the Form 4 feed, scrolling insider transactions and trying to eyeball whether the selling meant anything. Ten minutes if the site was fast and he knew exactly what he was looking for. Longer when he didn't, which was most of the time on a name he was meeting cold.

So the week before this call, he did it differently. He wired the two SEC data sources directly into Claude as tools, using the official Apify MCP server, and let the model do the fetching. Setup was one config block and a restart.

The two Actors he connected:

The SEC EDGAR 10-K, 10-Q & 8-K Filings Scraper returns a company's filings of record by ticker or CIK: form type, filing date, period of report, accession number, filer category, and the direct link to the document on sec.gov.
The SEC Form 4 Insider Trading Transactions Scraper returns insider trades as structured rows: insider name, role, transaction code (buy, sell, grant, gift), shares, price per share, transaction value, and shares owned afterward.

Both exposed to Claude through one MCP endpoint. Nothing else changed about how he works: he opens a chat and types in plain English.

Sixty minutes out: the filing

An hour before the call, Daniel opened a chat and asked for the one thing he refuses to take from memory: the latest annual report on file.

One tool call, and the filing came back as a record, not a recollection. The latest 10-K for NVIDIA Corp was filed 2026-02-25, covering the fiscal year ended 2026-01-25, under accession number 0001045810-26-000021. Claude also handed back the CIK (0001045810), the filer status (large accelerated filer), the Nasdaq listing, and the four prior 10-Ks going back to fiscal 2022, so Daniel had a clean five-year annual trail if the call turned historical.

The distinction that matters: the agent did not tell Daniel what NVIDIA earned. It told him which document to trust, with the exact period and accession, so any figure he cites on the call traces to that filing rather than to a model's guess about last year. That is the honest division of labor. The tool finds and identifies the primary source; the analyst reads it.

The insider question

Filing in hand, Daniel asked the second question, the one that separates a real read from a headline. Insider selling at NVIDIA had been in the news, big dollar figures attached. He wanted to know what was actually underneath the number.

He didn't want a total. He wanted the composition.

One tool call pulled forty Form 4 transactions filed since January, and Claude did the part that a raw dollar sum hides: it separated the flow into buckets.

Almost all the dollar volume came from one person. Director Mark A. Stevens sold roughly $446 million of stock on the open market across the window: 565,615 shares at $210.44 and 319,385 at $209.70 on a single day in June, half a million more shares at $222.38 earlier that month, and so on. Enormous, but it is one insider, and the sales are staggered across dates in a way that reads as a pre-arranged plan rather than a reaction to anything.

The executives' "selling" was mostly not selling at all. The CFO and the EVPs appear under transaction code F: shares automatically surrendered to cover taxes when equity awards vest, all at the same $207.41 on the same day. That is a mechanical event, not a market call. Colette Kress, the CFO, shows 40,746 shares withheld this way, not sold into a decision.

The CEO made no open-market sale at all. Jensen Huang's only entries in the window are a 400,000-share gift and tax withholding on vesting. And across all forty transactions, there was not a single open-market insider buy.

Claude's read, stated plainly: this is not a broad executive exodus. The scary headline is one director's programmatic sales plus routine vesting mechanics, and the person running the company did not sell a share on the market. Then the line that keeps the tool in its lane: this is the structure of the insider flow, not a buy or sell recommendation; the judgment call is yours. That is exactly right. The agent organized the evidence. It did not tell Daniel what to think of it.

Five minutes out: the dossier

With both pieces gathered, Daniel asked for the deliverable: a single one-pager he could drop into his call notes, with the source run cited for each block so anyone reviewing it later could reproduce every line.

Two tables and a two-sentence read. The company and its latest annual filing at the top, the insider composition below, and under each block the Actor and run ID it came from. An analyst reading this six months from now can re-run either pull and get the same rows. That is the difference between a note that says "insiders are selling" and a note that says "insider selling is concentrated in one director's plan; here is the run that proves it."

The whole thing (filing, insider breakdown, consolidated one-pager) took the length of a coffee. The old version of this hour was two tabs, a lot of scrolling, and a quiet worry that the fiscal period on the slide didn't quite match the filing.

What actually changed

Nothing about Daniel's analysis moved to the machine. He still decides what the company is worth and what to say on the call. What moved was the fetching and the sorting, the mechanical layer that used to eat the hour and occasionally introduced a stale fact:

The source is authoritative. Every filing fact carries an accession number and every insider figure carries a run ID. The one-pager is audit-ready by construction, not by cleanup afterward.
The signal is separated from the noise. A raw "insiders sold $500M" is a trap. Splitting it into one director's plan, mechanical tax withholding, and zero buys is the actual read, and the agent did that sorting in seconds.
The model's memory never touched the numbers. The point of wiring in the tools is precisely so Claude answers from today's filings, not from whatever it absorbed in training. On a name that reports every quarter, that is the whole ballgame.

Daniel walked into the call working from the record. On a busy morning, with the old two-tab process, the fiscal period might have been last year's and the insider story might have been the headline instead of the truth.

Build the same agent

Everything in this story is reproducible today with a free Apify account and any MCP-capable client (Claude Desktop, Cursor, or your own agent):

Get your Apify API token from the Apify Console under Settings → Integrations.
Add the official Apify MCP server to your client and list the two Actors in the tools parameter:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/sec-edgar-filings-scraper,scrapers_lat/sec-form4-insider-trades-scraper",
      "headers": { "Authorization": "Bearer YOUR_APIFY_TOKEN" }
    }
  }
}

Restart the client and ask it, in plain English, for a company's latest 10-K and its recent Form 4 activity. It will pick the right tool for each question and cite the run.

📌 Note: each tool call is a real Actor run billed to your Apify account (both are pay-per-result, a fraction of a cent per lookup). For a watchlist rather than one name, run the Actors on a schedule through the Apify API and have the agent read the latest results, instead of one call per chat.

🏹 Extend it: the same pattern covers the rest of a diligence sheet. Add SEC 13F Institutional Holdings to see who owns the stock, or SEC Financial Statements to pull the actual line items behind the 10-K, and your research agent builds the whole one-pager from filings of record, without a single line of new code.

The Actors used in this story: SEC EDGAR 10-K, 10-Q & 8-K Filings Scraper and SEC Form 4 Insider Trading Transactions Scraper.

The provider roster that would have failed in the claims system, caught before it loaded

Michael — Mon, 03 Aug 2026 15:03:14 +0000

This is a story about a task nobody puts on a slide: checking a list of doctors before it goes into the system that pays them. It is dull, it is repetitive, and when it goes wrong the failure shows up weeks later as a pile of rejected claims and angry providers. Every registry record below is a real lookup against the live national provider registry, captured from an actual chat. No mocked screens, no toy data.

The setup

Priya runs provider-network operations at a regional health plan. When the contracting team signs a new group or a batch of clinicians, the roster lands on her desk as a spreadsheet: an NPI for each provider, a name, and a claimed specialty. Her job is to verify each row and then load it into the claims system so the plan can actually pay those providers.

The verification is not glamorous, but it is load-bearing. For every NPI she has to confirm three things:

Is the NPI Active? A deactivated or non-existent NPI that slips into the claims system rejects every claim tied to it.
Is it the right entity type? An individual clinician is a Type 1 NPI; a facility or group is Type 2. Load one where the other belongs and claims edit out.
Does the registry taxonomy match the specialty the contracting sheet claims? If the roster says "ophthalmologist" and the registry says something else, the claim edits that key off specialty will reject the claim downstream.

For years this meant one browser tab on the national NPI registry, one row at a time: type the number, read the record, eyeball the specialty, copy the status into the load file. Twenty providers was a morning. And it was reliable exactly as long as she was not rushed, which, at roster-load time, she always is. The rejects that follow a bad load are expensive: reworked claims, provider abrasion, and a network-adequacy report that no longer matches reality.

So she changed the mechanical part. She wired the national provider registry directly into Claude as a tool, using the official Apify MCP server, and let the model do the lookups. Setup was one config block and a restart. Nothing about how she works changed: she still opens a chat and types in plain English.

The tool she connected:

The NPPES NPI Healthcare Provider Data Scraper returns the full registry record for any US provider: NPI status, entity type, legal name, credential, the full taxonomy (specialty) list with license numbers, and practice address. Exposed to Claude through one MCP endpoint, it turns a tab-and-type chore into a sentence.

The batch

Monday morning, a new roster: six providers to verify and load. A multi-specialty facility, a couple of dentists, a cardiologist, an oncologist, and an eye doctor. Instead of opening the registry six times, Priya pasted the list into Claude and asked it to check each NPI for status, type, and a taxonomy match against the specialty her sheet claimed.

A few seconds of tool calls, and the picture was clear. Five of the six came back clean:

Mayo Clinic (NPI 1881018208): Active, Type 2 (Organization), Clinic/Center, Multi-Specialty, Rochester, MN. Matches "facility."
Dr. Steven Aaker (1538202965): Active, Type 1, Dentist (DDS, license D8075), Prior Lake, MN. Matches "general dentist."
Dr. John Aamodt (1790723302): Active, Type 1, Dentist, Orthodontics, Eagan, MN. Matches "orthodontist."
Dr. Michael Aaron, MD (1790762623): Active, Type 1, Internal Medicine, Cardiovascular Disease, West Islip, NY. Matches "cardiologist."
Dr. Laurent Gressot, MD (1215930367): Active, Type 1, Hematology & Oncology, Houston, TX. Matches "oncologist."

The sixth is the reason the check exists. Dr. Steven Sheiner (NPI 1417918293) came back Active (so a naive "is the NPI good?" check would have waved it through), but the registry listed him as an Optometrist, while Priya's sheet claimed ophthalmologist. Claude flagged it and offered to pull the detail.

This is the part that matters. A live, Active NPI is not the same as a correct roster row. The registry check catches the difference and says why, so the flag is auditable, not a hunch.

The catch

Priya asked Claude to open up row six: why the flag, and what exactly to tell contracting.

The detail made the problem concrete. The registry record for NPI 1417918293 shows the provider's credential is OD (Doctor of Optometry) and the primary taxonomy is 152W00000X, Optometrist, licensed OPC3172 in Florida. The roster claimed Ophthalmology (207W00000X). Those are two different professions: an optometrist (OD) and an ophthalmologist (MD) are not interchangeable, and they carry different billable service sets.

Loaded as an ophthalmologist, this row would have sailed past a basic eligibility check and then rejected the moment a claim came in with a procedure code restricted to that specialty, a taxonomy edit denial. The provider disputes the denial, and it lands right back on Priya's desk weeks later, harder to trace. Caught at load time, it is one line in an email to contracting: the registry shows this NPI belongs to an optometrist, not an ophthalmologist, so either the wrong NPI was pulled for the intended physician or the specialty column is wrong. Confirm which, fix it, then load.

Nobody had to remember the OD-versus-MD distinction, or hold the taxonomy codes in their head. The check was one sentence, backed by the live registry rather than anyone's memory of what Dr. Sheiner does.

The load ticket

The last step used to eat the most time: writing it all up so the load could proceed and an auditor could follow it later. Priya asked Claude to consolidate the morning's verification into a go/load table she could attach to the ticket.

Six providers, six decisions, each with the NPI status, entity type, and registry taxonomy it was based on. Five cleared to load, one on hold pending a specialty correction. The whole thing traces back to the official registry, so the load ticket carries its own evidence. If a claim on any of these providers is questioned six months from now, the reasoning is right there.

What actually changed

Priya still owns the judgment. She still decides what loads and what goes back to contracting. What moved to the machine was the mechanical part: the tab-switching, the copy-paste, the risk of skimming a taxonomy under deadline. That is the right division of labor:

The lookup is automated. Claude pulls the live registry record the moment the conversation needs it, one NPI or fifty.
The evidence is preserved. Every verdict cites a status, a type, and a taxonomy code, so the load ticket is audit-ready by default.
The check is consistent. The same three tests run on row six as on row one, at 9am or at 6pm, whether or not it is a busy morning.

The mismatched provider was caught before a single claim rejected. On the old one-tab process, an Active NPI with the wrong specialty is exactly the kind of thing that gets waved through under time pressure, and surfaces later as a denial report.

Build the same agent

Everything in this story is reproducible today with a free Apify account and any MCP-capable client (Claude Desktop, Cursor, or your own agent):

Get your Apify API token from the Apify Console under Settings → Integrations.
Add the official Apify MCP server to your client and list the Actor in the tools parameter:

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

Restart the client and paste a roster in plain English. Ask it to confirm each NPI is Active, the right type, and a taxonomy match. It will pick the tool and do the lookups.

📌 Note: each tool call is a real Actor run billed to your Apify account (the NPPES Actor is pay-per-result, a fraction of a cent per lookup). For a nightly re-verification of an entire loaded network (catching providers who deactivate or change taxonomy after you loaded them), run the Actor on a schedule through the Apify API instead of one call per chat.

🏹 Extend it: the same pattern covers the rest of a provider-file check. Add SAM.gov exclusions to screen each provider against federal exclusion and debarment lists, or the OFAC sanctions list for a sanctions check, to the tools list, and your roster agent verifies more of the file without a line of new code.

The Actor used in this story: NPPES NPI Healthcare Provider Data Scraper.

How to give Claude a US restaurant inspection lookup tool with the Apify MCP server

Michael — Mon, 03 Aug 2026 15:02:27 +0000

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, 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 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-actor tools that let an agent discover Actors it was not preconfigured with.

The Actor used in this guide: US Restaurant Inspections Scraper: Food Establishments.

How to give Claude a Singapore government-tender tool with the Apify MCP server

Michael — Mon, 03 Aug 2026 14:57:36 +0000

If you sell to the Singapore public sector, the single most useful thing you can know is what the government already buys, from whom, and for how much. That information exists, it is public, and it sits in GeBIZ, the Singapore Government e-procurement register. The problem is not access. The problem is that GeBIZ is a portal built for one-off human lookups, not for the "read fifty awards and tell me the pattern" question a bid or capture team actually asks.

Ask Claude the same question from memory and it will happily invent an answer. It does not know that Workforce Singapore awarded a S$2.17M SaaS contract to AvePoint in May 2025, and if you press it, it will guess. For anything that feeds a bid decision, a confident guess is worse than no answer.

In this guide we fix that. We connect Claude to the official Apify MCP server, expose a single Actor that reads GeBIZ awarded contracts, and turn "who is winning Singapore government software work?" from a guess into a live query against the register. By the end you will have a working market-intelligence 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?

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 Singapore GeBIZ Government Contracts Scraper. It reads awarded tenders from GeBIZ and returns a structured record for each one: the tender number, the procuring agency, the awarded supplier, the awarded amount and currency, the award date, and the tender status. You can pull the newest awards, filter by a keyword like "software" or "cleaning" or "consultancy," and set a minimum award value to skip the small stuff.

That field set is exactly what a market-research or capture team needs: who buys, who wins, and at what price. GeBIZ is a good first source because it is public, authoritative, and covers the whole of Singapore central government.

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

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/singapore-gebiz-contracts-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/singapore-gebiz-contracts-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--singapore-gebiz-contracts-scraper

That last entry, scrapers_lat--singapore-gebiz-contracts-scraper, is our procurement 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 the market

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

"We sell SaaS to the Singapore public sector. Pull recent GeBIZ software awards so I can see who's winning, which agency, and the contract values."

Claude recognizes it cannot answer this reliably from memory, selects the GeBIZ 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--singapore-gebiz-contracts-scraper",
  "arguments": {
    "searchQuery": "software",
    "maxContracts": 25,
    "sortByNewest": true
  }
}

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": "yzPcUrUNdDn1pHyH6",
  "actorName": "scrapers_lat/singapore-gebiz-contracts-scraper",
  "status": "SUCCEEDED",
  "startedAt": "2026-07-30T17:47:24.601Z",
  "finishedAt": "2026-07-30T17:47:28.043Z",
  "stats": { "runTimeSecs": 3.3 }
}

Just over three seconds, live against the register.

Step 5: Read the real output

The dataset the tool returns is structured award data, one object per contract. This is an actual record from the run:

{
  "tenderNo": "WSG000ETT25000003",
  "description": "Provision of Public Cloud Integrated Training and Learning Management System (ITLMS) Software as a Service (SaaS)",
  "agency": "Workforce Singapore",
  "supplier": "AVEPOINT SINGAPORE PTE. LTD.",
  "awardedAmount": 2177024.5,
  "currency": "SGD",
  "awardDate": "16/5/2025",
  "awardYear": 2025,
  "status": "Awarded to Suppliers"
}

Claude reads that and answers in plain language: Workforce Singapore awarded a public-cloud learning-management SaaS contract to AvePoint Singapore for S$2,177,024.50 in May 2025, under tender WSG000ETT25000003. Every one of those facts is traceable to the register, not the model's memory.

The value of the tool is in the set, not the single row. Across the same 25 awards you can see that Workforce Singapore is a repeat SaaS buyer, that award values cluster in the S$0.5M to S$5M band, and that incumbents such as ST Engineering Mission Software win, and re-win, similar iBPMS work over multiple years. That is a competitive map, assembled in one query, that a person would have paged through GeBIZ for an afternoon to build by hand.

A real use case: a bid-qualification agent

Put this in context. A capture manager at a SaaS vendor is deciding which Singapore government opportunities are worth pursuing this quarter. Before committing a bid team, they need to know:

which agencies actually buy software in their category,
what the winning contracts have been worth, and
who the incumbent supplier is, because unseating one is a different bid than an open field.

Without a tool, the analyst opens GeBIZ, searches a keyword, clicks into each award, and copies the agency, supplier, and value into a spreadsheet, one row at a time. With the tool wired into Claude, the analyst asks the agent to pull recent awards for a keyword, group them by agency, and rank suppliers by total value won. Claude calls the Actor, reasons over the returned dataset, and produces a short target list with an incumbent named against each agency. The manual paging disappears; the qualification call stays with the human.

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

Going further: chain a second tool

Knowing who won a contract is the first question. The obvious next one is "who exactly is that supplier?" The same MCP connection can expose more Actors by extending the tools parameter:

https://mcp.apify.com?tools=scrapers_lat/singapore-gebiz-contracts-scraper,scrapers_lat/singapore-acra-entities-scraper

Now the agent can pull an award from GeBIZ and look the winning supplier up on the official Singapore ACRA corporate register in the same conversation, resolving "AVEPOINT SINGAPORE PTE. LTD." to its UEN, incorporation date, registered address, and current status. The result is a single briefing that ties a contract to a verified legal entity. Because each Actor is a separate tool, the agent picks the right one for each step on its own: GeBIZ for the award, ACRA for the company behind it.

📌 Note: each tool call is a real Actor run billed to your Apify account (this Actor is pay-per-result). Award amounts are reported by the register in Singapore dollars, and some legacy records carry rounded or estimated values, so treat a single figure as an indicator and read the set for the trend. For a one-off market pull the cost is a fraction of a cent; if you plan to sweep every category on a schedule, run the Actor directly through the Apify API or a scheduled task instead of one call per chat message.

Wrapping up

You now have an AI agent that can survey the Singapore government procurement market on demand, mid-conversation, with the agency, supplier, and contract-value detail a bid decision 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:

Change the searchQuery to your own category, or set a minimum award value to focus on the contracts worth bidding.
Chain the ACRA Actor to turn a winning supplier name into a verified company profile.
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: Singapore GeBIZ Government Contracts Scraper.

How to give Claude a Singapore healthcare-credential verification tool with the Apify MCP server

Michael — Mon, 03 Aug 2026 14:56:49 +0000

AI agents are good at reasoning and terrible at facts. Ask Claude whether "Dr Alex Tanoto Lim" is a doctor registered to practise in Singapore, and it will give you a confident answer from its training data that may be months or years stale, or simply invented. For anything credentialing-related, "probably correct" is not good enough. A locum with a lapsed practising certificate, or a name that never appears on the register at all, is exactly the case you cannot afford to wave through.

In this guide we fix that. We connect Claude to the official Apify MCP server, expose a single Actor that reads Singapore's Ministry of Health (MOH) public register of healthcare professionals, and turn "is this clinician actually registered?" from a guess into a live lookup against the source of record. By the end you will have a working verification tool that Claude, Cursor, or any MCP client can call during a 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?

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 Singapore MOH Healthcare Professionals Register Scraper. It searches Singapore's MOH public register and returns the full record for a registered professional: full name, registration number, profession type and register, registration type and start date, practising certificate start and end dates, qualifications with awarding institution and year, and current place of practice.

MOH is the authority behind the professional boards that register clinicians in Singapore, covering doctors (SMC), dentists (SDC), nurses and midwives (SNB), pharmacists (SPC), and traditional Chinese medicine practitioners (TCMPB). That field set is exactly what a credentialing, panel-onboarding, or insurer network-admission check needs. Singapore is a useful jurisdiction because the register is public, authoritative, and has no login wall.

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

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/singapore-moh-health-professionals-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/singapore-moh-health-professionals-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--singapore-moh-health-professionals-scraper

That last entry, scrapers_lat--singapore-moh-health-professionals-scraper, is our verification 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 verify a professional

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

"A locum doctor named 'Alex Tanoto Lim' is applying to join our clinic panel. Confirm he's on Singapore's MOH register, and give me his registration number, qualification, and whether his practising certificate is currently valid."

Claude recognizes it cannot answer this reliably from memory, selects the MOH 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--singapore-moh-health-professionals-scraper",
  "arguments": {
    "council": "doctors",
    "searchName": "tan",
    "withDetails": true
  }
}

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": "vP5udmMb50cVuwGe1",
  "actorName": "scrapers_lat/singapore-moh-health-professionals-scraper",
  "status": "SUCCEEDED",
  "startedAt": "2026-07-30T17:47:20.805Z",
  "finishedAt": "2026-07-30T17:47:31.987Z",
  "stats": { "runTimeSecs": 11.2 }
}

Eleven seconds, live against the MOH register.

Step 5: Read the real output

The dataset the tool returns is structured register data. This is an actual record from the run (trimmed to the fields that matter for credentialing):

{
  "name": "ALEX TANOTO LIM",
  "registrationNo": "M66411A",
  "professionType": "Doctor",
  "typeOfRegister": "Medical Practitioner",
  "registrationType": "Full Registration",
  "registrationStartDate": "27/04/2021",
  "practisingCertStartDate": "01/01/2025",
  "practisingCertEndDate": "31/12/2026",
  "qualifications": [
    { "qualification": "MBBS",
      "institution": "NTU-Imperial College London, Singapore",
      "year": "2020" }
  ],
  "placesOfPractice": [
    { "name": "TAN TOCK SENG HOSPITAL",
      "address": "11 JALAN TAN TOCK SENG Singapore 308433" }
  ],
  "council": "SMC"
}

Claude reads that and answers in plain language: yes, Alex Tanoto Lim holds registration number M66411A on the Singapore Medical Council register, with Full Registration, an MBBS from NTU-Imperial College London (Singapore, 2020), and a practising certificate valid from 01/01/2025 through 31/12/2026, so he is cleared to practise today. His listed place of practice is Tan Tock Seng Hospital. Every one of those facts is traceable to the official register, not the model's memory.

The counter-example is just as important. Suppose the applicant's name returns no match, or returns a record whose practisingCertEndDate has already passed. A doctor can be validly registered yet not hold a current practising certificate, which means they are not cleared to see patients. An agent doing credentialing needs to see that distinction, and the practising-certificate dates surface it directly. The tool shows the gap; the model alone would not.

A real use case: a credentialing intake agent

Put this in context. A clinic network, a telehealth platform, or an insurer's provider-network team is onboarding clinicians and needs to confirm, before granting panel access or network admission, that:

the named professional is actually on the MOH register,
their registration type is appropriate (full versus conditional or provisional), and
their practising certificate is current, not lapsed.

Without a tool, an intake officer opens the MOH website, selects the right board, types the name, opens the matching record, and copies fields into a credentialing form, once per applicant. With the tool wired into Claude, the officer pastes the applicant list into the chat and asks the agent to verify each one. Claude calls the Actor per name, reads back the registration number and register, checks the practisingCertEndDate against today, flags anyone whose certificate has expired or who does not appear at all, and produces a short pass/refer note with the registration number as evidence. The manual lookup step disappears; the judgment stays with the human.

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

Going further: chain a second tool

Credentialing rarely stops at the individual clinician. You often need to confirm the practice that employs or engages them is a real, live Singapore entity too. The same MCP connection can expose more Actors by extending the tools parameter:

https://mcp.apify.com?tools=scrapers_lat/singapore-moh-health-professionals-scraper,scrapers_lat/singapore-acra-entities-scraper

Now the agent can verify the clinician on the MOH register and confirm the employing clinic or medical group on the Singapore ACRA Company Registry Scraper in the same conversation, pulling the entity's UEN, status, and registered address, then combine both results into one onboarding summary. Because each Actor is a separate tool, the agent picks the right one for each step on its own: MOH for the person, ACRA for the corporate entity behind them.

📌 Note: each tool call is a real Actor run billed to your Apify account (this Actor is pay-per-result). Search by a specific surname and set the profession (council) so the run returns the record you want rather than a broad list. For one-off verification the cost is a fraction of a cent; if you plan to verify thousands of professionals on a schedule, run the Actor directly through the Apify API or a scheduled task instead of one call per chat message.

Wrapping up

You now have an AI agent that can verify a Singapore healthcare professional against the official MOH register, on demand, mid-conversation, with the registration number, register type, qualification, and practising-certificate validity a credentialing 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:

Switch the council input to check dentists, nurses, pharmacists, or TCM practitioners with the same tool.
Add the ACRA company registry, sanctions, or licensing Actors to build a multi-step provider-onboarding agent.
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: Singapore MOH Healthcare Professionals Register Scraper.