Apify MCP Server

The local server runs every tool with a single Apify API token taken from the APIFY_TOKEN environment variable or, failing that, from the Apify CLI login file in the home directory. Nothing in the server narrows that token per tool or checks a request against a policy before it is used, so by default every tool acts with the full authority of the user's Apify account. The one exception is the opt-in delete-actor tool, which checks that the Actor belongs to the token's account and is not public. Users can hand the server a scoped token from Apify Console, but the server neither asks for one nor behaves differently with one.

As a tool server it leaves approval to the MCP host, and gives the host risk hints: every built-in tool declares read-only, destructive and open-world hints, and the tool that starts Actor runs is marked destructive. A few opt-in tools that overwrite or publish settings are marked non-destructive, and tools proxied from Actor MCP servers carry whatever hints the remote server declares. There is no dry-run or preview and no confirmation step the server enforces itself. The default consequential actions are paid Actor runs, which cannot be undone and whose spend cap is optional and chosen by the model.

Every tool call is validated against the tool's JSON schema in one central step before it runs, including schemas that come from Actors and proxied MCP servers. Several tools go further: the docs fetcher only accepts HTTPS URLs on the Apify and Crawlee documentation hosts, generic API reads are limited to the Apify API origin, Actor MCP endpoints are confined to the Actor's own standby origin, and delete-actor refuses Actors the user does not own. The default tool set, however, includes call-actor, which runs any Actor in Apify Store with free-form input, so the default reach is the whole Store and, through web-fetch Actors, any URL. Tool categories can be narrowed with --tools, but the default includes this generic tool.

The server never runs model-influenced code on the local machine: there is no shell, eval or subprocess call anywhere in its source. Code runs only as Apify Actor runs, which the server starts through the Apify API, so isolation is provided by Apify's cloud containers rather than by anything in this repository, and could not be verified here. Every execution path goes to that remote service and there is no local fallback. Inside a run, an Actor has unrestricted network access and the run's platform token, and the model chooses memory and timeout, so a misbehaving run can still spend money and reach the internet.

Web pages fetched by the default rag-web-browser and web-fetch Actors, third-party Actor READMEs and descriptions, and run results all come back to the model without any marking that they are untrusted. Third-party Actor descriptions are written into tool descriptions, tools proxied from Actor MCP servers keep the remote server's descriptions, and the server's own results add instructions to the model alongside that content. Some outputs do carry structured run metadata and a source URL or run ID. Nothing in the server stops a session that has read untrusted web content from then starting arbitrary paid Actor runs, sending data to any URL through a fetch Actor, or reading the account's private storages.

The server keeps no memory that outlives the process: its only state is in-memory caches of Actor definitions and documentation pages that expire within an hour. It writes no files and loads no instruction or settings files from the working directory; the only files it reads are its own package metadata, its bundled widget scripts, and the Apify CLI login file in the user's home directory. No project or workspace file can add tools or change its behaviour.

The third-party code this server can launch is Apify Actors, which run in Apify's cloud. In the default configuration the model can start any public Actor in Apify Store through call-actor, at whatever build the developer has tagged or one the model names, with no pin, integrity check, allowlist or user consent in the server. Actor definitions and proxied MCP tool lists are fetched again each session with no check for changes. Runs do not execute on the local machine, and Apify requires a separate approval for Actors that ask for full account permissions, but Actor MCP servers are contacted with the session's account credentials, as a source comment documents, so what a malicious Actor gets depends on platform controls that are outside this repository.

The Apify token comes from an environment variable or the Apify CLI's plaintext login file, and is attached to API requests by the Apify client rather than placed in model-visible output; the user-ID cache keys on a hash of the token. Log redaction covers only the Skyfire payment token. Usage telemetry to Segment and crash reporting to Sentry are on by default and send tool names, statuses, Actor and run IDs and short error details, but not tool arguments. The token itself is long-lived and, as usually configured, account-wide. A report-problem tool, served by default to some clients while telemetry is on, sends model-written problem reports to Apify; only its description asks the model to leave out personal data and credentials.

The server writes a structured line for every completed tool call, but the local stdio entry point sets the log level to errors only, so in the default configuration successful calls leave no local record; only failures are printed to standard error, where the MCP host may capture them. Every call is also reported to Apify's usage telemetry with the tool name, status and Actor and run IDs, but that goes to the vendor, not to the operator. The Apify platform keeps its own run history, which is outside this server. No record links a call to an approver.

The server caps how long it waits for an Actor run (45 seconds at most), times out calls to Actor MCP servers after two minutes, limits inline output to 256 KB, and caps search and key listings. When the client cancels a call while the server is waiting, it aborts the Actor run it started. But a run keeps going in Apify's cloud after the tool returns, the model chooses its timeout (zero means no limit), memory and optional spend cap, and dataset reads have no maximum page size. Any spend ceiling comes from the user's Apify plan rather than from the server.