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

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?

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

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

1. which agencies actually buy software in their category,
2. what the winning contracts have been worth, and
3. 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.

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