MCP Server (Claude, ChatGPT, Cursor)

The Nahook MCP server lets an AI assistant drive your webhook platform — list endpoints, inspect failed deliveries, replay them, and manage endpoints — using the same permissions you have in the dashboard.

There are two ways to connect:

Hosted MCP server (recommended)

The hosted server lives at a single URL — the same one for every client:

https://mcp.nahook.com/

No install, no keys to paste. When you first connect, your browser opens a Nahook consent screen where you sign in and pick the workspace to grant access to. Authentication is OAuth 2.1 (Authorization Code + PKCE, with Dynamic Client Registration), so the client configures itself — you never copy a client id or secret.

Prerequisites

• A Nahook account with at least one workspace.
• An MCP client that supports remote servers (Claude, ChatGPT, Cursor, VS Code, …).

Connect your client

claude mcp add --transport http nahook https://mcp.nahook.com/

// ~/.cursor/mcp.json
{
  "mcpServers": {
    "nahook": {
      "url": "https://mcp.nahook.com/"
    }
  }
}

// .vscode/mcp.json
{
  "servers": {
    "nahook": {
      "type": "http",
      "url": "https://mcp.nahook.com/"
    }
  }
}

https://mcp.nahook.com/

https://mcp.nahook.com/

Local CLI MCP server (full toolset)

The local server ships as a subcommand of the Nahook CLI (nahook mcp serve). One binary, one credentials file. It exposes all 12 tools, including trigger_event and send_to_endpoint, which fire real webhooks through the production ingestion pipeline — these are intentionally not in the hosted server.

1. Install the Nahook CLI

The MCP server is bundled with the CLI binary.

brew install getnahook/tap/nahook

Other install paths: CLI install docs.

2. Log in once

nahook login

This writes credentials to ~/.nahook/config.toml — the MCP server reads from there.

3. Wire it into your client

claude mcp add nahook -- nahook mcp serve

// ~/.cursor/mcp.json
{
  "mcpServers": {
    "nahook": {
      "command": "nahook",
      "args": ["mcp", "serve"]
    }
  }
}

// Cline settings → MCP Servers
{
  "nahook": {
    "command": "nahook",
    "args": ["mcp", "serve"]
  }
}

// settings.json
{
  "assistant": {
    "mcp_servers": {
      "nahook": {
        "command": "nahook",
        "args": ["mcp", "serve"]
      }
    }
  }
}

// Continue, Windsurf, Goose, and other MCP-compatible clients
// follow the same command + args shape:
{
  "command": "nahook",
  "args": ["mcp", "serve"]
}

After wiring, restart the client. The assistant will see Nahook's tools in its tool list.

Local authentication: CLI token vs ingestion key

The local server uses two separate credentials:

The ingestion key is the same one your SDKs use. If you call a write tool without one configured, the server fails with a clear message.

What tools the Nahook MCP server provides

Both servers call the same Nahook API with your workspace's permissions. The hosted server exposes the 10 read + management tools; the local CLI adds the two event-firing tools.

On the local CLI, get_delivery also accepts include_payload: true to return the original webhook body — useful when debugging.

Read vs write tools

Read tools (whoami, list_*, get_*) never modify anything and are always safe to call.

Write tools (create_endpoint, update_endpoint, retry_delivery, and on the local CLI trigger_event, send_to_endpoint) are tagged with the MCP annotations contract (readOnlyHint: false / destructiveHint: true). Clients that honor these annotations surface a per-call human-approval prompt before any of these run.

Security

• Permissions are evaluated per request against your workspace role. The MCP session has exactly the permissions you have in the dashboard — nothing more, nothing less. Revoke access (dashboard for hosted, or by rotating the CLI token locally) and the server loses it.
• Secrets are never returned. Endpoint signing secrets and Basic-auth credentials are never exposed by any tool; endpoints report only whether auth is configured.
• Treat webhook payloads as untrusted. Delivery bodies and headers can contain text controlled by whoever sent the event. When you ask an assistant to summarize or act on a delivery, that content could attempt prompt injection — review any write actions before approving them.

Common use cases

• Debugging failed webhooks: "Pull the most recent failed delivery for endpoint ep_xxx and tell me what the error was." The assistant uses list_deliveries → get_delivery → list_attempts and walks you through the failure.
• Operational tasks: "Pause every endpoint in the staging environment." The assistant calls list_environments, list_endpoints, and update_endpoint with is_active: false for each (with approval prompts).
• Recovering deliveries: "Find the dead-lettered deliveries for ep_xxx from the last hour and retry them." The assistant lists the failures and calls retry_delivery after you approve.
• Testing (local CLI): "Fire an order.created event with this payload and watch what happens." The assistant calls trigger_event (after your approval) and inspects the resulting deliveries.

Troubleshooting

• My client doesn't show Nahook's tools. Restart the client after adding the server. For the hosted server, make sure you completed the browser OAuth consent (the tools only load after you authorize a workspace). For the local server, confirm the nahook binary is on your PATH.
• OAuth / connection fails (hosted). Connect to exactly https://mcp.nahook.com/. Your client must support remote MCP servers with OAuth; older or stdio-only clients should use the local CLI instead.
• A write tool says "forbidden". Your workspace role doesn't have permission for that action — the MCP server enforces the same RBAC as the dashboard.
• I'm being rate limited. The hosted server applies per-workspace rate limits. Back off and retry; for high-volume automation use the SDKs or ingestion API.
• I need trigger_event or send_to_endpoint. Those fire real production webhooks and are only available on the local CLI server. Use it, or the SDKs / ingestion API.

Find Nahook in the MCP directories

Source code