Apify MCP Server

Call Actor

call-actor

Destructive

Run any Apify Store Actor dynamically by providing its name and JSON input, then fetch results via dataset IDs. Use when no dedicated Actor tool exists.

Instructions

Call any Actor from the Apify Store.

WORKFLOW:

Use fetch-actor-details to get the Actor's input schema
Call this tool with the actor name and proper input based on the schema

If the actor name is not in "username/name" format, use search-actors to resolve the correct Actor first.

For MCP server Actors:

Use fetch-actor-details with output={ mcpTools: true } to list available tools
Call using format: "actorName:toolName" (e.g., "apify/actors-mcp-server:fetch-apify-docs")

IMPORTANT:

Waits up to waitSecs (default 30s) for completion; returns run status and storage IDs, and with waitSecs > 0 also reports dataset field metadata
Use get-dataset-items with the datasetId to fetch results; non-terminal runs include a nextStep with polling instructions
Use dedicated Actor tools when available for better experience

There are two ways to run Actors:

Dedicated Actor tools: These are pre-configured tools, offering a simpler and more direct experience.
Generic call-actor tool (call-actor): Use this when a dedicated tool is not available or when you want to run any Actor dynamically. This tool is especially useful if you do not want to add specific tools or your client does not support dynamic tool registration.

USAGE:

Always use dedicated tools when available
Use the generic call-actor tool only if a dedicated tool does not exist for your Actor.
Use waitSecs (0–45) to control how long to wait. Default 30s returns results for fast actors. Use waitSecs: 0 to start and return immediately for long-running actors.

EXAMPLES:

user_input: Get instagram posts using apify/instagram-scraper

Input Schema

TableJSON Schema

Name	Required	Description
`actor`	Yes	The Actor to call: its ID, or its name in the "username/name" form (e.g., "apify/rag-web-browser"). For MCP server Actors, use format "actorName:toolName" to call a specific tool (e.g., "apify/actors-mcp-server:fetch-apify-docs").
`input`	Yes	The input JSON to pass to the Actor. Required.
`waitSecs`	No	Seconds to wait for completion (0–45, default 30). Returns with current run status if not terminal within waitSecs.
`callOptions`	No	Optional run config: memory (MB), timeout (s), build, maxItems (pay-per-result cap), maxTotalChargeUsd (pay-per-event cap).

Output Schema

TableJSON Schema

Name	Required	Description
`runId`	Yes	Actor run ID
`stats`	No	Run statistics
`status`	Yes	Run status: READY \| RUNNING \| TIMING-OUT \| TIMED-OUT \| ABORTING \| ABORTED \| SUCCEEDED \| FAILED
`actorId`	Yes	Stable Apify Actor ID from the run record
`summary`	Yes	Past-tense summary of the run state
`exitCode`	No	Actor process exit code; populated for terminal states (especially FAILED)
`nextStep`	Yes	One primary follow-up action with identifiers interpolated
`storages`	Yes	Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry.
`actorName`	No	"username/actor-name"
`startedAt`	No	ISO timestamp when the run started
`finishedAt`	No	ISO timestamp when the run finished (terminal states only)
`statusMessage`	No	Pass-through from Apify run.statusMessage
`apifyConsoleUrl`	No	Personalized Apify Console link to the run; present only for Console sessions

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.17.0Oct 1, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: it discloses the wait behavior (up to waitSecs, default 30s), that non-terminal runs return a nextStep with polling instructions, that run status and storage IDs are returned along with dataset field metadata, and that results require a follow-up get-dataset-items call. This operational context is exactly what the destructive/openWorld annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and header-structured, which helps scanning, but it is over-long and repeats the dedicated-vs-generic-tool point in three separate places ('Use dedicated Actor tools', 'There are two ways to run Actors', 'Always use dedicated tools when available'). The trailing EXAMPLES block is a single truncated line that adds little.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter tool with nested callOptions, a 100%-covered schema, and an output schema, this covers everything an agent needs: prerequisites, naming conventions, wait timing, async completion handling, and follow-up retrieval. Nothing important to a correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains when to use waitSecs=0 versus the default 30s for long-running actors, and it clarifies the actor-name resolution path and the 'actorName:toolName' MCP-server form. It stops short of adding anything about callOptions beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Call any Actor from the Apify Store') and immediately scopes it as the generic, dynamic path versus pre-configured dedicated Actor tools. An agent can distinguish it from siblings like fetch-actor-details and search-actors without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it ('only if a dedicated tool does not exist') and when not to ('Always use dedicated tools when available'), plus a step-by-step workflow that routes through fetch-actor-details and search-actors, and guidance on waitSecs=0 for long-running actors. Alternatives and selection conditions are fully spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server