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

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?

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 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

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/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:

1. the named professional is actually on the MOH register,
2. their registration type is appropriate (full versus conditional or provisional), and
3. 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.

🏹 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). 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.