What passed in our sandbox?
Our run on October 1, 2026, at commit 556bbaa recorded successful install, build and test commands in our sandbox. The full SHA is 556bbaab8c669b8d665e4d53f6536982b0c7cbc3. Our harness records each command's outcome, exit code, timeout status and elapsed time separately from parsed test counts.
The stored harness durations were 24 seconds for installation, 24 seconds for building and 43 seconds for testing. It recorded 750 dependency packages occupying 673 MB. These are repository preparation and check results, not measurements of scraping speed or Actor charges.
The stored parser summaries report 1,945 passed tests, zero failed tests and one skipped test out of 1,946. The raw Vitest footer agrees. Its separate file total counts test files, not individual tests. Repeated summary lines must not be added together, and no complete-log reconciliation established exhaustive unique coverage.
The raw tail logs an error while testing rejection of an Actor MCP path that resolves outside its standby origin. That test file is marked passed. The message does not establish a failed test or a new security finding; the skipped test is also separate from failures.
What remains untested?
Our run did not establish authenticated Apify access, paid Actor execution, extraction accuracy, deployment or reliable long-job retrieval. Audit data is absent, so advisory results and scan coverage are unknown. The record identifies the sandbox image as lab-node:22; manifest detection of nodeMajor 24 does not establish the runtime version used.
MrKeyoor's testing methodology explains how command outcomes and parsed counts reach the review. It provides provenance context, not proof that today's procedure was used for this older run. This correction uses the supplied stored record and includes no new execution.
Does local stdio keep scraping local?
Actors run and store results on Apify in both hosted and local modes. Local stdio places the MCP process on your machine, while requests and Actor inputs still reach the Apify API. That rules it out for offline collection or a policy that forbids those transfers.
The current Apify MCP Server README recommends hosted OAuth and lists output-schema inference as a hosted feature unavailable locally. Local setup requires Node.js 22 or later and authentication through a token or Apify CLI login. Client support for OAuth, dynamic tools and MCP Apps varies.
The README at our measured commit documents that checkout. Current documentation describes later behavior and does not show what our sandbox exercised. The supplied v0.15.3 release documents a specific schema fix; it does not identify the package version at our later measured commit.
What should an initial deployment expose?
An explicit tools selection gives the agent a defined interface; Apify warns that the default tool set can change. Start with an approved Actor and the result helpers it needs. Review its inputs, pricing and data handling before allowing unattended execution.
The server supports Actor discovery, input and pricing inspection, execution, and result retrieval. Actor calls return run information and storage identifiers; reading dataset items requires a subsequent call. Test pagination as well as the initial execution request. Connecting to the server is free, while Actor runs bill according to each Actor's pricing.
Telemetry is enabled by default, and local stdio also uses Sentry. The README documents an opt-out that includes Sentry. Decide that setting before rollout.
Can long jobs finish after a tool call returns?
Actor runs can outlast the server's wait of up to 45 seconds. Issue 1119 on long-running Actor tasks describes a separate legacy task-retention problem: a quiet Actor can outlive its hosted task record, complete successfully, and still leave task-result retrieval returning not found. The issue is deferred pending adoption of the MCP Tasks extension.
Run-status and dataset helpers provide retrieval paths, but their presence does not prove that task-retention problem is resolved. Before relying on long jobs, test a quiet run with your client and confirm that results remain retrievable after completion. Our successful repository test command does not answer that operational question.
Which alternative fits the task?
Firecrawl MCP Server supports scraping a known URL into Markdown or structured JSON. Its README also documents crawling, search, document parsing and browser interaction. Consider it as a replacement when those workflows meet your needs without selecting an Apify Actor. Calling it only a narrow crawler would understate its scope.
Playwright MCP lets an agent interact with web pages through structured accessibility snapshots. Its README supports choosing it for browser interaction and inspection of page state. It can replace a suitable Actor task or complement Apify when the assistant needs both browser control and managed Actor results. We measured no comparative advantage in cost, footprint, extraction quality or runtime.
What do the ratings mean?
The ratings are editorial assessments of documented support and limitations, not performance scores. The rubric is: 1 means substantial obstacles, 2 means significant constraints, 3 means usable with material caveats, 4 means strong documented support with remaining requirements, and 5 means unusually complete evidence for the assessed dimension.
Setup considers configuration guidance and our repository checks, without treating hosted login as tested. Documentation considers coverage of setup and operational limits. Community considers visible maintainer activity and contribution access, without inferring adoption or response times. Maturity considers repository checks and documented reliability limits. Bug reports and documentation fixes are welcomed, while code contributions require a maintainer invitation.