Update the Apify adapter to the MCP server 0.21 tool list - #1552

Summary

Apify released version 0.21 of its MCP server (mcp.apify.com) on 2026-11-05, and it breaks one of our tools. apify--web-fetch now goes through the Actor's server interface, so it takes {method, path, query, body} instead of {url, formats, ...}. apify--web-search was added the same way, apify--rag-web-browser was removed, and three tools were added for Actors that run their own HTTP API or MCP server. Since 2026-11-05 13:00 UTC, every apify_web_fetch call from a connector that still has the old schema fails with -32602 Invalid arguments ... must have required property 'method'.

This PR updates the catalog snapshot in intl/apify.json to the current server tool list (server 0.21.2, 15 tools, read-only tools/list). It also rewrites the connector instructions so they no longer mention the RAG Web Browser or the old web-fetch arguments.

Changes

• packages/backend/src/adapters/intl/apify.json:

  • Removed: apify_rag_web_browser.
  • Changed: apify_web_fetch now has the 0.21 schema (required method and path, plus query and body). The server now marks it read-only (readOnlyHint: true, destructiveHint: false). The other ten tools that are still served got Apify's current descriptions and schemas. Their names did not change.
  • Added (all switched on): apify_web_search, apify_fetch_actor_mcp_tool_list, apify_call_actor_mcp_tool and apify_send_server_actor_request.
  • enabled: I applied the same policy as before. Only apify_report_problem installs switched off, because its text goes to Apify. apify_call_actor_mcp_tool and apify_send_server_actor_request spend credits just like apify_call_actor, which has always been on: running Actors is the point of this connector. So they install switched on, and the Safety section names them as tools to restrict with roles. apify_send_server_actor_request can send any HTTP method, DELETE included, to an Actor's own API.
  • Each tool keeps the existing conventions: name = apify_ + remote name with -/-- turned into _, endpointMapping: {method: <remote name>, path: "/"}, parameters = the server's inputSchema, and the server's annotations without title. As before, em and en dashes in Apify's text are replaced (0–45 becomes 0 to 45, — becomes , ).
  • Instructions:
    • Web search and web fetch with an example request for each.
    • Server Actors (fetch-actor-details with serverInterface, then send-server-actor-request) and MCP server Actors.
    • The per-request and idle-run costs.
    • The real button label, Discover from MCP Server, and what it does.

• packages/backend/src/adapters/intl/apify.live.spec.ts: static assertions for:

  • The 15-tool set and the absence of rag-web-browser.
  • The required method/path of apify_web_fetch and apify_web_search, and the required fields of send-server-actor-request.
  • The switched-off set and the destructive tools that stay on.
  • The install path: mergeDiscoveredMcpTools over a discovery of this list gives the same local names and endpoint mappings, with only report-problem off.

  The spec has no live calls, so there is nothing to put behind RUN_APIFY_LIVE=1.

• catalog.ts, llms.txt and llms-full.txt: no diff after regeneration. Tool counts are not quoted anywhere adapter-count.mjs checks.

What happens to connectors that are already installed

I checked CatalogResyncService.computeDiff/resync, CatalogReconciler, the discover-tools endpoint and the connector page. Apify is an MCP adapter, so the catalog never adds, rewrites or retires its tools (serverOwnsTools). This PR does not fix the tools of installed connectors on its own:

• At boot (CATALOG_AUTOSYNC on, which is the default on both Cloud and self-hosted), the reconciler sees a new adapter version. The only thing it can change is the instructions: it refreshes them when the user has not edited them (safe class) and stamps the version. No "Catalog update available" card stays behind. If the user edited the instructions, they keep their text and the connector counts as up to date.
• "Apply update" shows up only where auto-sync is off (CATALOG_AUTOSYNC=false). It too refreshes only the instructions. It does not remove apify_rag_web_browser and does not fix the schema of apify_web_fetch.
• The fix for an installed connector is the "Discover from MCP Server" button on the connector page (Tools section). It is shown for every MCP connector, bearer token included. ("Re-discover Tools" in the OAuth card only appears for OAUTH2 connectors.) It runs tools/list and goes through catalogMcpToolsFor, which applies this catalog's policy:
  • apify_web_fetch is matched by its endpoint and gets the new schema and annotations.
  • The new tools are created. report-problem would stay off if it were new.
  • apify_rag_web_browser is soft-deprecated and switched off.
  • Role access and manual on/off settings are kept.
• Until then, apify_web_fetch on an installed connector keeps failing with -32602, both on Cloud and on self-hosted installs (both call mcp.apify.com). New installs on either deployment discover the 0.21 tools at install, so they are not affected. This snapshot is what the catalog lists, and the fallback when the server cannot be reached at install.

Type

• Bug fix
• New feature
• Documentation
• Refactoring
• Performance improvement
• Other (describe below)

Testing

• Added/updated unit tests
• Tested manually (describe steps below)
• No tests needed (explain why)

Commands and results (worktree off main at 3dc2604, after npm ci and npx prisma generate):

Repository root:

• node scripts/validate-adapters.mjs --warn: exit 0, 1440 warnings, the same output as on main (diff of the two outputs is empty). None of them is for apify.
• node scripts/regenerate-catalog.mjs: 729 adapters across 15 regions. catalog.ts has no diff.
• node scripts/adapter-count.mjs --check: OK: every quoted count equals 713 adapters (35 keyless, 12893 tools) (it was 12890 tools on main). No quoted tool count to fix.
• node scripts/generate-llms-txt.mjs: llms.txt and llms-full.txt have no diff.

packages/backend:

• npx jest src/adapters/intl/apify --maxWorkers=4: 1 suite, 8 tests passed.
• npx jest src/adapters src/connectors/catalog --maxWorkers=4: 721 suites passed, 1 skipped, 1 failed. The failure is catalog-summary.spec.ts, "serves one adapter's instructions, and 404 for an unknown slug", which hit the 5000 ms timeout while the machine was under load. It is not related to this change. Re-run alone, npx jest src/adapters/catalog-summary --maxWorkers=4: 12/12 passed.
• npx tsc --noEmit -p tsconfig.json: exit 0.
• npx eslint src/adapters/intl/apify.live.spec.ts: exit 0. I did not run the full npm run lint, because its --fix rewrites files across the package.

Checklist

• My code follows the existing code style
• I have tested my changes locally
• I have updated documentation (if applicable): the adapter instructions are the user-facing documentation
• All existing tests pass (npm test): the root npm test was not run (see AGENTS.md). The backend catalog/adapters/catalog-resync specs pass, see above.
• This PR has a descriptive title

Related Issues

None. Upstream change: https://github.com/apify/apify-mcp-server/blob/master/CHANGELOG.md (v0.20.0, v0.21.0).