USP

This server uniquely integrates AI agents with the vast Apify Store ecosystem, offering agentic payments and dynamic tool discovery for seamless, cost-effective web data extraction without API tokens for certain payments.

Use cases

• 01Extracting data from social media posts
• 02Scraping Google Search Results Pages (SERPs)
• 03Gathering contact details from Google Maps
• 04Automating web data collection for research
• 05Integrating web scraping into AI agent workflows

Detected files (5)

• .claude/skills/bug-triage/SKILL.mdskill
  Show content (6713 bytes)

  ---
  name: bug-triage
  description: >-
    Triage open GitHub bug issues for Apify MCP server. Fetches issues, analyzes
    root causes, drafts developer-to-developer responses, and posts after user
    approval. Use when handling user bug reports, responding to issues, or
    cleaning up stale bugs.
  argument-hint: "[issue numbers] [--label <label>] [--all]"
  allowed-tools: [Read, Glob, Grep, Bash, WebFetch, Agent]
  ---
  
  # Bug Triage
  
  Triage open bug issues on `apify/apify-mcp-server`. Analyze, draft responses, get approval, post.
  
  ## Permissions
  
  - **Read-only by default**: listing issues (`gh issue list`), viewing details and comments (`gh issue view`) — do these automatically, no need to ask.
  - **Write requires approval**: commenting (`gh issue comment`), closing (`gh issue close`), editing (`gh issue edit`) — **always present the draft and wait for explicit user approval before executing**.
  
  ## Step 0: Parse arguments
  
  `$ARGUMENTS` controls scope:
  
  | Input | Behavior |
  |---|---|
  | `623 641 639` | Triage specific issue numbers |
  | `--label bug` | Triage all open issues with label (default: `bug`) |
  | `--all` | Triage all open bug-labeled issues |
  | _(empty)_ | Same as `--all` |
  
  ## Step 1: Fetch issues
  
  Use the arguments parsed in Step 0 to determine what to fetch.
  
  **If specific issue numbers were provided**, skip the list queries and fetch each issue directly:
  
  ```bash
  gh issue view <number> --repo apify/apify-mcp-server --comments
  ```
  
  **Otherwise** (label mode, `--all`, or empty), fetch open bug reports. Use the label from Step 0 (default: `bug`). Bug reports come in two forms — find both:
  
  1. **By label**: issues with the parsed label
  2. **By title prefix**: issues with `[Bug]` in the title (the bug report template adds this, but the label isn't always applied)
  
  ```bash
  # By label (use the label from Step 0, default: bug)
  gh issue list --repo apify/apify-mcp-server --label <label> --state open --json number,title,labels,createdAt,body --limit 30
  
  # By title prefix (catches unlabeled bug reports)
  gh issue list --repo apify/apify-mcp-server --state open --search "[Bug] in:title" --json number,title,labels,createdAt,body --limit 30
  ```
  
  Merge both lists and deduplicate by issue number.
  
  For each issue, fetch full details **including all comments** (comments often contain the real context):
  
  ```bash
  gh issue view <number> --repo apify/apify-mcp-server --comments
  ```
  
  **Always read comments before drafting a response.** Previous team members may have already replied, asked for details, or provided workarounds. Don't duplicate existing responses.
  
  ## Step 2: Categorize each issue
  
  Assign one of these categories:
  
  | Category | Criteria | Typical action |
  |---|---|---|
  | **Known fix** | Root cause is clear, documented fix exists | Draft response with fix, optionally close |
  | **Not our bug** | Server logs show it works; issue is in the MCP client (Claude Desktop, Cowork, etc.) | Explain findings, suggest workaround |
  | **Duplicate** | Same root cause as another open issue | Comment with link, close as duplicate |
  | **Needs info** | No logs, no config, vague description | Ask for specifics |
  | **Stale** | We asked for info, no reply for 2+ weeks | Close with helpful pointer |
  | **Actionable bug** | Real server-side bug we need to fix | Acknowledge, investigate further |
  
  ### Common root causes (from past triage)
  
  These patterns recur. Check for them first:
  
  1. **SSE endpoint removed** (April 1, 2026): Users on `/sse` URLs get connection failures. Fix: switch to `https://mcp.apify.com` (streamable HTTP).
  
  2. **"Tools connected but Claude ignores them"**: MCP server logs show successful handshake and `tools/list`, but Claude doesn't use the tools in conversation. This is a Claude Desktop/Cowork behavior, not an Apify server bug. Users need to explicitly ask Claude to use Apify tools.
  
  3. **"Unable to connect to extension server"**: Claude Desktop extension install issues. Usually caused by corrupted npx cache, Claude silently downgrading the extension, or Node.js not on the GUI app's PATH. Fix: use the remote server `https://mcp.apify.com` as a custom connector.
  
  4. **npx cache corruption**: Stale cache prevents stdio server from starting. Fix: `rm -rf ~/.npm/_npx` (macOS/Linux) or `rmdir /s /q %LOCALAPPDATA%\npm-cache\_npx` (Windows).
  
  5. **Claude Desktop connector downgrade**: Claude Desktop silently downgrades connectors to older versions. Fix: remove and re-add the connector.
  
  ## Step 3: Draft response
  
  **Style rules:**
  - Developer-to-developer, plain language
  - Concise — 3-8 lines typical, no fluff
  - Acknowledge the issue and apologize briefly if the user is stuck
  - Reference documentation when a fix or troubleshooting guide exists
  - If the server works correctly (logs prove it), say so clearly
  - If closing, explain why and point to where to go next
  
  **Key documentation links:**
  - Setup guide: `https://docs.apify.com/platform/integrations/mcp`
  - Claude Desktop troubleshooting: `https://docs.apify.com/platform/integrations/claude-desktop#troubleshooting`
  - Configurator: `https://mcp.apify.com`
  
  **Use Apify MCP tools** (`search-apify-docs`, `fetch-apify-docs`) to find the right doc link if the issue touches a topic not covered above.
  
  **The default recommendation** for connection issues is the remote server:
  
  > Add a custom connector in Claude Desktop with URL `https://mcp.apify.com` and follow the OAuth flow.
  
  ## Step 4: Present and get approval
  
  Present each issue to the user with:
  1. **Issue number + title + link** (`https://github.com/apify/apify-mcp-server/issues/<number>`)
  2. **Category** (from Step 2)
  3. **Summary** — one line on what's going on
  4. **Proposed response** — the draft comment in a blockquote
  5. **Proposed action** — comment only / comment + close / close as duplicate of #X / skip
  
  **MANDATORY: Wait for explicit user approval before posting anything.** Never post, close, or modify an issue without the user saying yes.
  
  ## Step 5: Post
  
  After approval:
  
  ```bash
  # Comment only
  gh issue comment <number> --repo apify/apify-mcp-server --body "<response>"
  
  # Comment + close
  gh issue comment <number> --repo apify/apify-mcp-server --body "<response>" && \
  gh issue close <number> --repo apify/apify-mcp-server
  
  # Close as duplicate
  gh issue comment <number> --repo apify/apify-mcp-server --body "Closing as a duplicate of #<other> — same root cause. We'll track and update there." && \
  gh issue close <number> --repo apify/apify-mcp-server
  ```
  
  Then move to the next issue. After the last one, print a summary table:
  
  | Issue | Category | Action taken |
  |---|---|---|
  | #623 | Known fix | Commented, SSE migration |
  | #639 | Duplicate | Closed as dup of #641 |
  | ... | ... | ... |
  

• .claude/skills/dig/SKILL.mdskill
  Show content (8151 bytes)

  ---
  name: dig
  description: >-
    Explore, analyze, plan, or spec features for the Apify MCP server. Adapts to
    what the user asks — from quick code exploration to full GitHub issue specs.
    Use when the user asks to explore code, understand behavior, plan a change,
    design a feature, or create an issue spec.
  argument-hint: "<your request> [--sdk <path>] [--ext-apps <path>] [--internal <path>]"
  allowed-tools: [Read, Glob, Grep, Bash, WebFetch, WebSearch, Agent]
  ---
  
  # Dig
  
  Flexible skill for exploring, planning, and speccing work on the Apify MCP server. **Do NOT edit source files** — this skill is for understanding and planning only.
  
  ## Step 0: Parse arguments and determine intent
  
  `$ARGUMENTS` contains the user's request and optional repo path overrides.
  
  **Flags** (optional):
  
  | Flag           | Default                          | Purpose                        |
  |----------------|----------------------------------|--------------------------------|
  | `--sdk`        | `../typescript-sdk`              | MCP SDK source repo path       |
  | `--ext-apps`   | `../ext-apps`                    | MCP Apps SDK source repo path  |
  | `--internal`   | `../apify-mcp-server-internal`   | Internal server repo path      |
  
  Everything not matching a flag is the **user's request**.
  
  **Resolution order** for source repos: flag path → default sibling path → `node_modules/` (compiled types only) → GitHub URL (last resort). Always verify the path exists before using it.
  
  ### Determine the intent
  
  Infer the intent from the user's natural language. There are three modes:
  
  | Intent | What you do | Examples |
  |--------|-------------|---------|
  | **Explore** | Read code, explain findings, answer questions | "how does tool naming work", "look at the widget code", "why is this broken", "what would break if we change X" |
  | **Plan** | Enter plan mode, design the approach, assess impact | "plan implementing resource links", "figure out how to refactor metadata", "design the simplification" |
  | **Spec** | Plan + create GitHub issues | "write an issue for X", "create a spec for Y", "spec out resource links" |
  
  **Rules:**
  - Default to **Explore**. When in doubt, do less — the user can always ask for more.
  - Only enter plan mode for **Plan** and **Spec**.
  - Only create GitHub issues for **Spec**.
  
  ## Step 1: Explore
  
  Read the relevant source files and explain your findings. This is the baseline for all intents.
  
  **What to do:**
  1. Read the relevant source files in this repo
  2. Check similar existing features as reference
  3. Only check the internal repo, MCP SDK/spec, or MCP Apps SDK/spec if the user's question touches those areas
  4. If you spot a related open issue, mention it casually — but don't go searching for issues unless it's relevant
  
  **Stop here if the intent is Explore.**
  
  ## Step 2: Plan (Plan and Spec only)
  
  Use the `EnterPlanMode` tool, then design the approach.
  
  **What to do:**
  1. Assess internal repo impact (check `../apify-mcp-server-internal` if available)
  2. Check MCP spec/SDK if the feature involves protocol behavior
  3. Check MCP Apps spec/SDK if the feature involves widgets or interactive UIs
  4. Use `mcpc @stdio tools-call` to probe current behavior if useful (requires `npm run build`)
  5. Follow key conventions (see below)
  6. Ask clarifying questions if ambiguous — prefer narrowing scope over guessing intent
  
  **Key conventions:**
  - **Simple > complex, ruthlessly minimal** — only what's explicitly in scope
  - **Reuse before creating.** Search for existing helpers and patterns. Extend what exists.
  - **Smallest possible change.** Ask: is there a simpler way using what's already there?
  - **Zod** for input validation, **HelperTools enum** for tool names
  - Integration tests go in `tests/integration/suite.ts`
  - Changes may affect `apify-mcp-server-internal` — always assess impact
  - **Public/internal repo separation**: See `CLAUDE.md § Public/internal repo separation`
  - See `CLAUDE.md`, `CONTRIBUTING.md`, and `DEVELOPMENT.md` for full conventions
  
  **Stop here if the intent is Plan.** Exit plan mode with `ExitPlanMode`.
  
  ## Step 3: Spec (Spec only)
  
  Create GitHub issues. First exit plan mode with `ExitPlanMode`.
  
  ### Check existing issues
  
  Search for duplicates and related issues:
  
  ```
  gh issue list -R apify/apify-mcp-server --search "<keywords>" --json number,title,state
  gh issue list -R apify/ai-team --search "<keywords>" --json number,title,state
  gh issue list -R apify/apify-mcp-server-internal --search "<keywords>" --json number,title,state
  ```
  
  If a matching issue exists, update it with `gh issue edit` instead of creating a new one.
  
  ### Create issues
  
  **One issue per implementation phase.** A phase = one PR-sized unit of work (~50-200 lines changed). Each issue should be independently implementable.
  
  Use the repo's `feature_spec.yml` template. Only the **Problem** and **Proposed solution** fields are required. Include **Plan** and **Alternatives considered** only when they add real value. No fluff, no filler — straight to the point.
  
  ```markdown
  ## Problem
  [Concrete evidence: error messages, user reports, issue links. Not "users are confused" — instead "3 users reported X in #channel".]
  
  ## Proposed solution
  [Short. Reference existing code paths. List files inline if needed.]
  
  ## Plan
  - [ ] Step 1
  - [ ] Step 2
  
  ## Alternatives considered
  [Only if you actually evaluated other approaches.]
  ```
  
  **Style** (applies to issues AND all dig output — explanations, plans, specs):
  - Plain language, no fluff — see `CLAUDE.md § Communication style`
  - Skip any section that would be empty or generic
  - 10-30 lines, not 100
  - Concrete steps > prose
  
  **Self-review before presenting:**
  - Is this the minimal design? Could scope be smaller?
  - Am I reusing existing patterns or reinventing?
  - Could this adjust existing code rather than add new code?
  - Does it require refactoring first? If so, that's a separate issue.
  
  Present issue content to the user for review before creating. Use `gh issue create` with `t-ai` label.
  
  ## Available resources
  
  | Resource               | Path / URL                                                          | Use for                                                     |
  |------------------------|---------------------------------------------------------------------|-------------------------------------------------------------|
  | **Public repo**        | `.` (this repo root)                                                | Main codebase — tools, widgets, tests                       |
  | **Internal repo**      | `../apify-mcp-server-internal` (if available)                       | Hosted server — assess impact of changes                    |
  | **MCP SDK (types)**    | `node_modules/@modelcontextprotocol/sdk`                            | Protocol types, server/client APIs (compiled only)          |
  | **MCP SDK (source)**   | `../typescript-sdk` (if available)                                  | Examples, tests, full source — faster than GitHub           |
  | **MCP spec**           | `https://modelcontextprotocol.io/specification/2025-11-25`          | Protocol-level features                                     |
  | **MCP Apps SDK (types)** | `node_modules/@modelcontextprotocol/ext-apps`                     | MCP Apps types, React hooks, server helpers (compiled only) |
  | **MCP Apps SDK (source)** | `../ext-apps` (if available)                                     | Examples, tests, spec, full source — faster than GitHub     |
  | **MCP Apps spec**      | `https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/2026-01-26/apps.mdx` | MCP Apps extension specification                            |
  | **Dev server (no UI)** | `http://localhost:3001/` / tools: `mcp__apify-dev__*`               | Test tools without widgets                                  |
  | **Dev server (UI)**    | `http://localhost:3001/?ui=true` / tools: `mcp__apify-dev-ui__*`    | Test tools with widget rendering                            |
  | **mcpc stdio**         | `mcpc @stdio tools-call ...` (requires `npm run build`)             | Test tools — no running server needed                       |
  

• .claude/agents/mcpc-tester.mdagent
  Show content (8538 bytes)

  ---
  name: mcpc-tester
  description: Probe the local Apify MCP server with mcpc during development. Use proactively after implementing features or fixing bugs to test that the implementation follows the spec, confirm requirements are met, and discover failing or missing behavior.
  tools: Bash, Read, Glob, Grep
  model: sonnet
  memory: project
  ---
  
  You are a development testing agent for the Apify MCP server. Your job is to build the server, connect via mcpc, and test that the implementation follows the spec — confirming requirements are met and discovering failing or missing behavior. You are the fast feedback loop between writing code and knowing if it works.
  
  ## Key principles
  
  1. **Prefer mcpc + jq piping.** Always use `mcpc ... | jq` pipelines for verification. Keep pipelines short and readable — if you need multiple checks, run multiple commands rather than one giant pipeline. Never use Python or Node.js for parsing when jq can do the job.
  2. **Keep commands short.** Prefer simple, single-line `mcpc ... | jq '...'` calls. If a pipeline gets complex, break it into multiple shorter calls.
  3. **End-to-end focus.** You test that the server behaves correctly as a whole — tools appear, calls return expected output, schemas are correct, requirements from the spec are met. You do NOT run unit tests or replace the test suite. Unit tests (`npm run test:unit`) and integration tests (`npm run test:integration`) remain the source of truth. You are the fast, interactive middle ground — quicker than integration tests, more realistic than unit tests — for rapid spec validation during development.
  4. **Spec-driven.** When given a spec or requirements, systematically test each requirement and report which ones pass and which fail. When not given a spec, explore the relevant tools and report what you find.
  5. **Report concisely.** Return a clear, structured verdict: what you tested, what meets the spec, what doesn't, and any unexpected behavior. No fluff.
  
  ## Sessions (defined in `.mcp.json`)
  
  | Session | Transport | When to use |
  |---|---|---|
  | `@stdio` | `node dist/stdio.js` | Default — core tools only |
  | `@stdio-full` | `node dist/stdio.js --tools=...` | When you need non-default tools (add-actor, all categories, specific actors) |
  | `@dev` | `http://localhost:3001` | Widget / UI mode, or when you need **server logs** — requires `npm run dev` running |
  
  Server arguments come from `.mcp.json` — you cannot pass them inline. To test a different server configuration, add a new named entry to `.mcp.json` with the desired `args`, then connect it as a new session.
  
  Available `stdio.js` arguments: `--tools` (comma-separated tool names or actor IDs), `--actors` (comma-separated actor IDs), `--enable-adding-actors`, `--ui`.
  
  ## Workflow
  
  Every invocation follows this sequence:
  
  ```bash
  # 1. Build (always — mcpc runs the compiled dist/stdio.js)
  npm run build
  
  # 2. Check existing sessions
  mcpc
  
  # 3a. If @stdio is NOT listed — connect:
  mcpc --config .mcp.json stdio connect @stdio
  
  # 3b. If @stdio IS listed — restart to pick up the new build:
  mcpc @stdio restart
  
  # 4. Probe and verify (this is the main work)
  mcpc @stdio tools-list
  mcpc @stdio tools-call <tool> key:="value"
  
  # 5. Use --json for machine-readable output
  mcpc --json @stdio tools-call <tool> key:="value" | jq '...'
  ```
  
  If the task requires non-default tools, also connect/restart `@stdio-full`.
  
  ## Argument syntax
  
  Three ways to pass arguments to `tools-call` and `prompts-get`:
  
  1. **Key:=value pairs** (preferred): `key:=value` — auto-parses as JSON. `count:=10` → number, `enabled:=true` → boolean, `name:="hello"` → string
  2. **Inline JSON**: `'{"key":"value","count":10}'`
  3. **Stdin**: `echo '{"key":"value"}' | mcpc @stdio tools-call <tool>`
  
  ## All session subcommands
  
  Beyond tools, mcpc exposes the full MCP protocol surface:
  
  | Command | Purpose |
  |---|---|
  | `tools-list` / `tools` | List available tools |
  | `tools-get <name>` | Get tool schema details |
  | `tools-call <name> [args...]` | Call a tool |
  | `resources-list` / `resources` | List available resources |
  | `resources-read <uri>` | Read a resource by URI |
  | `resources-templates-list` | List resource templates |
  | `prompts-list` / `prompts` | List available prompts |
  | `prompts-get <name> [args...]` | Get a prompt with arguments |
  | `ping` | Check if server is alive |
  | `help` | Show server instructions and capabilities |
  | `grep <pattern>` | Search tools and instructions in session |
  | `tasks-list` | List active MCP tasks |
  | `tasks-get <taskId>` | Get task status |
  | `tasks-cancel <taskId>` | Cancel a running task |
  
  ## Useful flags
  
  | Flag | Purpose |
  |---|---|
  | `--json` / `-j` | Machine-readable JSON output (also via `MCPC_JSON=1`) |
  | `--full` | Show complete input schema on `tools-list` |
  | `--verbose` | Debug logging (also via `MCPC_VERBOSE=1`) |
  | `--timeout <sec>` | Request timeout (default: 300s) |
  | `--schema <file>` | Validate tool schema against expected schema file |
  | `--schema-mode <mode>` | Schema validation: `strict`, `compatible` (default), `ignore` |
  | `--task` | Async task execution (experimental) |
  | `--detach` | Start task and return immediately with task ID |
  
  ## Common verification patterns
  
  ```bash
  # List tool names
  mcpc --json @stdio tools-list | jq '.[].name'
  
  # Inspect a tool's full schema
  mcpc @stdio tools-get <tool-name>
  
  # Check tool annotations
  mcpc --json @stdio tools-list --full | jq '[.[] | {name, readOnly: .annotations.readOnlyHint}]'
  
  # Call a tool and extract text content
  mcpc --json @stdio tools-call search-actors keywords:="web scraper" | jq '.content[0].text'
  
  # Count tools
  mcpc --json @stdio tools-list | jq 'length'
  
  # Search across all tools by name/description
  mcpc @stdio grep "search"
  
  # Check server capabilities and instructions
  mcpc @stdio help
  
  # Verify server is alive
  mcpc @stdio ping
  
  # List resources and resource templates
  mcpc --json @stdio resources-list | jq '.[].uri'
  mcpc --json @stdio resources-templates-list | jq '.[].uriTemplate'
  
  # Read a specific resource
  mcpc @stdio resources-read "resource://uri"
  
  # Validate schema against expected file
  mcpc @stdio tools-get my-tool --schema expected.json --schema-mode strict
  ```
  
  ## Dynamic actor discovery
  
  Use `search-actors` and `fetch-actor-details` to dynamically load actors, then verify their behavior:
  
  ```bash
  # Find actors
  mcpc @stdio tools-call search-actors keywords:="google maps" limit:=3
  
  # Load one (registers it as a new tool)
  mcpc @stdio tools-call fetch-actor-details actorId:="compass/crawler-google-places"
  
  # Verify it appeared
  mcpc --json @stdio tools-list | jq '.[].name'
  
  # Inspect and call it
  mcpc @stdio tools-get <tool-name>
  mcpc --json @stdio tools-call <tool-name> key:="value" | jq '.content[0].text'
  ```
  
  ## Multi-step call sequences
  
  Many tests require chaining tool calls where one call's output feeds into the next. Use shell variables and jq subshells to pass data between calls:
  
  ```bash
  # Call an actor, extract datasetId, then fetch its output
  DATASET_ID=$(mcpc --json @stdio tools-call call-actor actorId:="apify/hello-world" input:='{}' | jq -r '.content[0].text | fromjson | .defaultDatasetId')
  mcpc --json @stdio tools-call get-actor-output datasetId:="$DATASET_ID"
  
  # Search → fetch details → call (full lifecycle)
  ACTOR_ID=$(mcpc --json @stdio tools-call search-actors keywords:="hello world" limit:=1 | jq -r '.content[0].text | fromjson | .[0].id')
  mcpc @stdio tools-call fetch-actor-details actorId:="$ACTOR_ID"
  mcpc --json @stdio tools-call call-actor actorId:="$ACTOR_ID" input:='{}'
  ```
  
  ## What to verify
  
  When probing, check these aspects as relevant to the task:
  
  - **Tool presence**: Expected tools appear in `tools-list`
  - **Tool schema**: Input schema matches expectations (`tools-get`)
  - **Tool annotations**: `readOnlyHint`, `destructiveHint`, `openWorldHint` are correct
  - **Tool output**: Calls return expected content structure and data
  - **Error handling**: Invalid inputs produce clear error messages
  - **Tool naming**: Names follow the expected format
  
  ## Reporting
  
  After probing, return a structured summary:
  
  **Tested:** What you tested (tools, calls, schemas, spec requirements)
  **Meets spec:** What works as expected / requirements confirmed
  **Fails spec:** What doesn't match the spec (with actual vs expected behavior)
  **Discovered:** Any unexpected behavior, edge cases, or missing functionality
  
  Keep it concise. The caller needs to understand what meets the spec, what doesn't, and why — so they can fix it immediately.
  

• server.jsonmcp_server
  Show content (759 bytes)

  {
    "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
    "name": "com.apify/apify-mcp-server",
    "description": "Extract data from any website with thousands of scrapers, crawlers, and automations on Apify Store ⚡",
    "repository": {
      "url": "https://github.com/apify/apify-mcp-server",
      "source": "github"
    },
    "version": "0.10.2",
    "remotes": [
      {
        "type": "streamable-http",
        "url": "https://mcp.apify.com/",
        "headers": [
          {
            "name": "Authorization",
            "description": "Apify API token for authentication with Apify platform services. For example 'Bearer <apify-api-token>'",
            "isRequired": true,
            "isSecret": true
          }
        ]
      }
    ]
  }
  

• .mcp.jsonmcp_server
  Show content (1056 bytes)

  {
      "mcpServers": {
          "storybook": {
              "type": "http",
              "url": "https://baldasseva--storybook-mcp.apify.actor/mcp?token=${APIFY_TOKEN}"
          },
          "figma": {
              "type": "http",
              "url": "https://mcp.figma.com/mcp"
          },
          "dev": {
              "type": "http",
              "url": "http://localhost:3001",
              "headers": {
                  "Authorization": "Bearer ${APIFY_TOKEN}"
              }
          },
          "stdio": {
              "command": "node",
              "args": ["dist/stdio.js"],
              "env": {
                  "APIFY_TOKEN": "${APIFY_TOKEN}",
                  "NODE_EXTRA_CA_CERTS": "${NODE_EXTRA_CA_CERTS}"
              }
          },
          "stdio-full": {
              "command": "node",
              "args": ["dist/stdio.js", "--tools=actors,docs,experimental,runs,storage,apify/rag-web-browser"],
              "env": {
                  "APIFY_TOKEN": "${APIFY_TOKEN}",
                  "NODE_EXTRA_CA_CERTS": "${NODE_EXTRA_CA_CERTS}"
              }
          }
      }
  }
  

README

# Create a new wallet
mcpc x402 init

# Import an existing wallet
mcpc x402 import <private-key>

# Show the wallet address so you can fund it with USDC on Base (https://base.org)
mcpc x402 info

mcpc connect "mcp.apify.com?payment=x402" @apify --x402

mcpc @apify tools-call call-actor actor:="apify/rag-web-browser" input:='{"query": "latest AI news"}'

{
  "mcpServers": {
    "skyfire": {
      "url": "https://api.skyfire.xyz/mcp/sse",
      "headers": {
        "skyfire-api-key": "<YOUR_SKYFIRE_API_KEY>"
      }
    },
    "apify": {
      "url": "https://mcp.apify.com?payment=skyfire"
    }
  }
}

{
  "query": "restaurants in San Francisco",
  "maxResults": 3
}

https://mcp.apify.com?tools=actors,docs,apify/rag-web-browser

https://mcp.apify.com?tools=apify/my-actor

npx @apify/actors-mcp-server --tools actors,docs,apify/rag-web-browser

npx @apify/actors-mcp-server --tools apify/my-actor

https://mcp.apify.com?ui=true

https://mcp.apify.com?tools=actors,docs&ui=true

npx @apify/actors-mcp-server --ui true

export UI_MODE=true
npx @apify/actors-mcp-server

# Disable via URL parameter
https://mcp.apify.com?telemetry-enabled=false

# Disable via CLI flag
npx @apify/actors-mcp-server --telemetry-enabled=false

# Or set environment variable
export TELEMETRY_ENABLED=false
npx @apify/actors-mcp-server

APIFY_TOKEN="your-apify-token"

npm run build

export APIFY_TOKEN="your-apify-token"
export APIFY_META_ORIGIN=STANDBY
apify run -p

export APIFY_TOKEN="your-apify-token"
npx @modelcontextprotocol/inspector node ./dist/stdio.js