Arkame MCP

To see the MCP working before you sign up, use the public demo token. It only reads Harborline Logistics, a fictional company with four servers (one of them running Zimbra) and 90 days of backups. Every request to change something is refused.

In Claude Code:

claude mcp add --transport http arkame-demo https://save.arkame.app/api/mcp \
  --header "Authorization: Bearer ark_demo3udDYUJZLkUyggylcEst_-so91lJrIC4idHYcgY"

In other clients, use the configuration from Connect with this token.

Questions to start with:

• "How did last night's backups go at Harborline?"
• "Which Zimbra accounts are in the latest backup of mail-01? Did any of them leave Zimbra?"
• "Did any backup fail in the last 30 days? Why?"
• "Is restore proven on every server?"

The data is fictional and rewritten every few hours. Everyone shares the same token, and the limits count per IP address.

1. In the panel, open Settings → API and MCP.
2. Give it a name, choose the scope (Read, or Read and operate) and the validity (up to one year). Confirm with your two-step verification code.
3. Copy the token (ark_…): it is shown only once. The same screen has the configuration ready to paste.

The token can never do more than your role in the organization, checked on every call: if your role changes, or you leave the organization, the token changes too. Admins see and revoke everyone's tokens.

The server is at https://save.arkame.app/api/mcp, over HTTP, with the token in the Authorization: Bearer header.

claude mcp add --transport http arkame https://save.arkame.app/api/mcp \
  --header "Authorization: Bearer ark_…"

{
  "mcpServers": {
    "arkame": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://save.arkame.app/api/mcp",
        "--header",
        "Authorization:${ARKAME_AUTH}"
      ],
      "env": {
        "ARKAME_AUTH": "Bearer ark_…"
      }
    }
  }
}

{
  "mcpServers": {
    "arkame": {
      "url": "https://save.arkame.app/api/mcp",
      "headers": {
        "Authorization": "Bearer ark_…"
      }
    }
  }
}

{
  "servers": {
    "arkame": {
      "type": "http",
      "url": "https://save.arkame.app/api/mcp",
      "headers": {
        "Authorization": "Bearer ark_…"
      }
    }
  }
}

Any other MCP client over HTTP works the same way: the address and the header.

Read tools come with any token; operate tools only with an operate token of someone who operates plans.

Nothing changes without the token owner. Creating, editing and pausing a plan, registering a server and restoring become an approval request: it shows up in a panel window for the token owner, with the action’s details, the token, IP and region, and only happens after it is approved with the two-step verification code. Whoever does not recognize the request revokes the token right there. The request expires in 15 minutes. Run and resume act at once.

Never through MCP: retention and permanent deletion, before and after backup commands, archiving, members, billing, webhooks and tokens. That is what a leaked token (or an assistant tricked by malicious text) cannot destroy. Use the panel for those.

• Per token: 60 calls per minute and 2000 per day.
• Per organization, all tokens together: 300 calls per minute.
• Operate tools: 10 per minute per token.
• Per day, per token: run up to 20; resume up to 10; requests to create a plan or a server up to 5 (each), to edit up to 10, to pause up to 5 and to restore up to 10. A rejected request also counts.
• One call per request: JSON-RPC batches are not accepted.
• Lists return up to 50 rows per call.
• Every operate action goes to the activity log, with the token name.

• "How did last night's backups go? Any server not responding?"
• "Why did erp-01's backup fail yesterday, and since when?"
• "Which servers have not had a proven restore in more than 14 days?"
• "Run the file server's daily plan now."
• "Create a plan that copies the same erp-01 folders to the cloud bucket, after the local backup."

Confirmation does not depend on the assistant: creating, editing and pausing plans, registering servers and restoring only happen after the token owner approves them in a panel window, with their two-step verification code, which never goes through the chat. The window shows the token, IP, region and program that made the request; whoever does not recognize it rejects it and revokes the token right there. The request expires in 15 minutes. Text coming back from the tools (plan, server and file names) is the organization’s data, and the server tells the assistant it is not an instruction.