Apify MCP setup: check Actors, runs and datasets
An Actor run becomes verifiable when you inspect the matching dataset.
An Apify connection starts with selecting an appropriate Actor. Its name alone does not establish the required inputs or the data it returns. First choose one public test URL and define the result fields you need. This guide follows selection through a bounded run to inspection of the matching dataset.
Connect the intended account
The hosted MCP server is available at https://mcp.apify.com. Apify documents OAuth sign-in and a bearer-token alternative. For browser authentication, add this entry to .vscode/mcp.json; the file does not contain a key.
{
"servers": {
"apify": {
"type": "http",
"url": "https://mcp.apify.com"
}
}
}
Start the connection, complete sign-in and compare the account with your Console. Use the servers root in VS Code; examples for other clients may use mcpServers. The VS Code guide explains this mapping and the first startup.
Separate discovery, execution and results
| Question | Tool | What to record |
|---|---|---|
| Which Actor fits? | search-actors / fetch-actor-details | Actor ID and input schema |
| Which run started? | call-actor | Run status and storage IDs |
| Which data belongs to it? | get-dataset-items | Dataset ID and row selection |
Apify explicitly describes call-actor as returning run status and storage identifiers. Retrieve the actual rows from the dataset afterwards. A successful start response is therefore not yet a verified data delivery. Actor and documentation discovery also have a separately restricted anonymous access path; execution and stored results require authentication.
Begin with a bounded run
Open the Actor details. Check its input schema, sample output and conditions in the vendor interface before submitting data.
Limit the first run to your prepared URL and a small result set. Use input fields that the selected Actor actually supports.
Record the run ID and status. If the job is still running, continue checking that run instead of starting a duplicate request.
Read rows using the matching dataset ID. Compare one known fact, one absent field and the number of rows returned.
Keep a concise test record
A useful test report can be short: Actor, input, run ID, dataset and comparison result. That mapping lets another person establish whether they are looking at the same attempt. Keep credentials out of the report. The access planner helps establish required account permissions and tool approvals before expanding the workflow.
- Why do I have a successful run but no data yet?
- Check the returned storage identifier. A run call does not automatically return its output rows. Read the matching dataset and check the final run status before assessing the result.
- Do I need to expose every available Actor?
- Start with the functions and Actors required for your test. Compare the tool list with that intended selection after each configuration change.
- Why are fewer rows returned than I expected?
- Check the retrieval limit and offset, then compare them with the dataset total. A bounded response does not establish that the run generated only those rows.
- Is Apify MCP the same as an MCP connector inside an Actor?
- No. Here your client accesses the platform through Apify’s server. A connector inside an Actor describes the other direction: the Actor connects to another MCP service.
The Apify registry search adds declared entry attributes. If you only need one known page, compare the scope with the Firecrawl guide and begin with the smaller test you can verify.
Vendor documentation read on 3 October 2026. Run the proposed checks in your own environment.
- Apify: MCP connection, tools and results
Show retrieval command
curl -s https://docs.apify.com/integrations/mcp - Apify: server implementation
Show retrieval command
curl -s https://github.com/apify/apify-mcp-server - VS Code: MCP configuration
Show retrieval command
curl -s https://code.visualstudio.com/docs/agent-customization/mcp-servers