For AI agents: an LLM-friendly Markdown version of every page is available by appending .md to its URL or by sending an Accept: text/markdown request header. The full documentation index is at https://www.ankr.com/docs/llms.txt
Skip to main content

Management MCP

Management MCP is the control plane for your Ankr account, exposed to an MCP client. It manages API keys and their security settings, reads usage and spending, handles balance and payment setup, and configures notifications, so an agent can do the account work you would otherwise do by hand in the Web3 API platform.

It is a separate server from the Agent RPC MCP data plane, with a separate auth model. Reading chain data needs no identity, only a key. Changing your account needs to know who you are, so this server signs you in.

info

The Management MCP is new and we are still rolling it out. The tool surface below is what ships today, with each limit stated where you would meet it.

What it manages​

Keys and projects. Create a key, optionally scoped to a set of chains, and get back a URL you can call immediately. List your keys with their name, description, slot, and chain scope. Rename one, change its chain scope, freeze or unfreeze it, or delete it. Check how many keys your plan allows.

  • mgmt_create_api_key, mgmt_list_api_keys, mgmt_reveal_api_key, mgmt_get_api_key_status, mgmt_get_allowed_key_count, mgmt_edit_api_key, mgmt_freeze_api_key, mgmt_delete_api_key

mgmt_list_api_keys stays redacted on purpose: it never returns key material. To get the endpoint token of a key you did not just create, use mgmt_reveal_api_key, which is gated by a human approval per key. Keys that also carry Enterprise access are labeled as such, and the reply names the enterprise.onerpc.com entry point rather than assembling a per-chain URL for it.

Per-key security. Restrict a key to specific IPs, referers, or contract addresses, restrict it to a set of chains, and read the enforcement mode back.

  • mgmt_add_allowlist_item, mgmt_edit_allowlist, mgmt_replace_allowlist, mgmt_set_allowlist_mode, mgmt_set_blockchain_allowlist, mgmt_get_allowlist, mgmt_get_allowlist_mode, mgmt_get_blockchain_allowlist

Three limits worth knowing before you rely on this: mgmt_get_allowlist reports the mode but does not list the entries in it, turning enforcement off is not effective today (the way to widen access is to replace the list), and CIDR ranges are not accepted anywhere in the allowlist path, only single addresses. Use the console when you need to read a list back item by item.

Usage and spending. Requests by day or interval, per chain, and spending split between pay-as-you-go and bundles.

  • mgmt_get_usage, mgmt_get_interval_stats, mgmt_get_spending_stats

Usage rollups lag behind live traffic by longer than the smallest interval window, so a report for the last few minutes will read low. The tool descriptions say so at the point of use.

Balance and payments. Current balance, level, and an estimate of how long it lasts at your current burn. Card top-ups and recurring subscriptions are started here, along with reads for subscriptions, prices, card eligibility, and invoices.

  • mgmt_get_balance, mgmt_get_days_estimate, mgmt_deposit_with_card, mgmt_subscribe_recurrent, mgmt_get_subscriptions, mgmt_get_subscription_prices, mgmt_card_payment_eligibility, mgmt_get_invoice_details

Notifications. Read notifications and mark them seen, add an email address, connect Telegram or Slack, choose which alerts fire, and enable, disable, or delete a delivery channel. See Notifications and alerts for what each alert covers.

  • mgmt_get_notifications, mgmt_mark_notifications_seen, mgmt_get_notification_channels, mgmt_get_notification_config, mgmt_set_notification_config, mgmt_add_notification_email, mgmt_integrate_telegram, mgmt_integrate_slack, mgmt_set_delivery_channel_status, mgmt_delete_delivery_channel

The write side configures more alert types than the read side reports back, so after changing the configuration, trust what you set rather than what the read returns.

Identity. Which account you are acting on, and a way to assert it.

  • mgmt_whoami, mgmt_pin_account

Connect and sign in​

The server is at:

https://mcp.ankr.com/mcp

There is no token to paste. Login is a real browser OAuth flow: your client discovers the authorization server, registers itself automatically, and opens a browser where you sign in to your Ankr account with Google. The client only ever holds a short-lived bearer issued by the MCP server; the Ankr session behind it stays server-side.

Claude Code​

claude mcp add --transport http ankr-management https://mcp.ankr.com/mcp

Run /mcp inside Claude Code, pick the server, and complete the browser login it opens.

Cursor​

{
  "mcpServers": {
    "ankr-management": {
      "url": "https://mcp.ankr.com/mcp"
    }
  }
}

VS Code​

{
  "servers": {
    "ankr-management": {
      "type": "http",
      "url": "https://mcp.ankr.com/mcp"
    }
  }
}
note

A session acts on the account you signed in with, and there is no account switcher: which account a login lands on is decided by the credential you sign in with. If you own more than one Ankr account, this matters. Every state-changing result and every account-scoped read names the account address it applied to, mgmt_whoami returns the same address, and you can assert the one you expect (with expectAccount on any call, or mgmt_pin_account once per session) so a call on the wrong account is refused and names both addresses instead of quietly succeeding. To act on a different account, sign in again as that account.

Two actions need a human, out of band​

An agent cannot approve its own sensitive action here, and neither can a compromised prompt. Where an action IS gated, it needs an out-of-band human approval that the model has no way to fabricate. Which actions those are is stated exactly below; the flow is:

  1. The agent calls the tool. Instead of acting, the server mints a short-lived, single-use approval link bound to that exact action, those exact arguments, and your account. The tool result tells the agent it needs approval, and describes the action in the same words the page will.
  2. You open the link and sign in again, interactively, in a browser. Approval succeeds only when the freshly signed-in human is the same account the request came from.
  3. The login alone does not approve anything. You get a consent page that names the action, what it affects, the concrete effects, an explicit warning when it cannot be undone, the account it applies to as its address, and when the link expires. Approval is a deliberate click on that page, so a link merely opened while signed in cannot grant it. The whole round-trip is bound to the browser it started in, and no key material is ever rendered on the page.
  4. The agent's next call carries the approved token, and the action goes through once.

Human approval covers two actions: deleting a dedicated API key, and revoking a Platform API key. Everything else executes on the first call with no human in the path, including revealing a key's endpoint token, minting a Platform API key, freezing a key, starting a payment, and every allowlist, notification, team and session write. Each tool states which of the two it is.

There is one case in between: six gateway routes are protected by the gateway's own second factor, and on an account with 2FA enabled those keep the approval page, because it is the only place a code is collected. On an account without 2FA they execute on the first call like everything else.

A confirm argument exists on some tools as a dry-run convenience. It is a model-set input and is never a security boundary: a client that wants a human in the loop for the ungated writes has to ask for one itself, because this server cannot see, require, or audit a prompt you show.

Six gateway routes are additionally protected by your account's 2FA, on accounts that have it enabled. The code is collected on the approval page, by the human, and never reaches the model, the transcript, or a log. A totp argument exists for a caller that genuinely holds a code already and is normally left empty — you should not be asked to type a 2FA code into a conversation with an agent.

What it cannot do​

These are limits of the design, not gaps waiting on a release:

  • Accounts whose key material is MetaMask-encrypted are not supported. Recovering the value of such a key requires eth_decrypt with the user's own wallet key, which no server can perform on your behalf. The tool says exactly this and points you at the console, where your wallet does the decryption. Everything else on the account still works here.
  • The agent cannot charge a card. mgmt_deposit_with_card starts a Stripe Checkout session and returns the hosted checkout URL for a human to open and pay. The agent never sees or handles card data, and cannot move money on its own.
  • Transaction broadcast is out of scope by design. Custody belongs to a wallet, not to an RPC management server. Nothing here signs or sends a transaction, and the data plane refuses broadcast on every chain family.
  • Scoping a usage report to a single project costs one human approval, because it needs that key's token, which is itself approval-gated. An unattended agent can report on the whole account, not per key.
  • A key created here is not immediately usable by an existing data-plane session. The create and reveal replies hand you a working rpc.ankr.com/<chain>/<token> URL you can call over plain HTTPS right away, but an Agent RPC MCP session is bound to the key it was opened with, so the data tools pick up a new key on a new session.