Chainstack

Get organization name and ID.

Takes no parameters.

List blockchain/cloud/network combinations for node deployment. Call before create_node to get valid blockchain and cloud IDs.

Takes no parameters.

List all projects. Projects are containers for nodes.

Takes no parameters.

Create a new project.

List nodes with status and connection endpoints.

Get a node's full details including endpoints and cloud info.

Deploy a new blockchain node. Call get_deployment_options first for valid IDs. Use a Global option (node_tier "Global") from get_deployment_options.

Get project details.

Update a project's name or description.

Delete a project (irreversible).

Rename a node.

Delete a node (irreversible).

List a node's access rules (IP and Origin allowlists, Global nodes only). With no active rules, the node accepts requests from any IP and origin. If correctly configured rules still return 403, that's a support case: offer contact_chainstack.

Add an IP or Origin allowlist rule to a Global node. New rules are deactivated and do nothing until activated. Active IP rules limit which client IPs can call the node; active origin rules limit which Origin headers it accepts. With both kinds active, a request must pass both. Everything else gets HTTP 403 within about 10 seconds. Rules don't affect the Chainstack API, so they can always be changed or deactivated with these tools. Before activating, confirm with the user that the IP rules cover every IP that calls the node (servers, CI, their own machine); you can't check this. Origin rules are for browser-only access: once one is active, every request without an Origin header (servers, scripts, curl) is blocked, even from an allowed IP. If an identical rule exists, it is returned instead of a duplicate.

Change an access rule's value, or activate or deactivate it. A rule's type can't change; delete it and create a new one. Before activating, confirm with the user that the IP rules cover every IP that calls the node. Activating the first origin rule blocks every request without an Origin header (servers, scripts, curl), even from allowed IPs. Changing or deactivating a rule can block clients that only it allowed.

Delete an access rule from a node (irreversible). Deleting an active rule changes who can reach the node; the result says what's enforced afterwards. With no active rules left, the node accepts requests from any IP and origin.

Activate or deactivate every access rule on a node at once. Activating enforces every rule within about 10 seconds: active IP rules limit which IPs can call the node, active origin rules limit which Origin headers it accepts, and a request must pass both kinds. Others get HTTP 403. First confirm with the user that the IP rules cover every IP that calls the node (servers, CI, their own machine); you can't check this. Origin rules block every request without an Origin header (servers, scripts, curl), even from an allowed IP. Deactivating opens the node to any IP and origin.

Search Chainstack docs — blockchain RPC methods, node infrastructure, Web3 APIs, deployment guides, and code examples.

Get the full content of a Chainstack documentation page. Use after search_docs to fetch the complete page when a snippet isn't enough.

Check platform status, active incidents, and maintenances.

Submit a message to Chainstack's sales and support team. Use when the user wants to ask about pricing, get a custom quote, request a plan upgrade, request node customizations (Enterprise), report a problem, or reach Chainstack for any reason. Posts to the same contact form as chainstack.com/contact/. ## Before calling this tool CRITICAL — follow these steps EVERY time: 1. Draft the message based on your conversation context. 2. Show the user the EXACT message, email, and name you will send. 3. If the user has a Chainstack API key configured, tell them their org name and ID will be included so the team can find their account and reply faster. 4. Ask: "Shall I send this to Chainstack? Please confirm there's no sensitive information you'd like removed." 5. Only call this tool after the user explicitly confirms. NEVER include in the message: - API keys, tokens, passwords, private keys, wallet seeds, mnemonics - RPC endpoint URLs (Chainstack or any other provider) - Wallet addresses, transaction hashes, on-chain account details, or anything else the user hasn't explicitly approved sharing ## Writing an effective message Include what you know: what they're building and at what scale, current plan and usage, what they need, what they've tried, and specific numbers. Bad: "I have a question about pricing." Good: "Pro plan user running 200M RU/month across Base and Ethereum, evaluating Business plan for archive access and higher RPS. Looking for annual pricing or a trial." Not for incidents or urgent outages — point users to https://support.chainstack.com/hc/en-us/requests/new and https://status.chainstack.com. Not for feature requests — point users to https://ideas.chainstack.com (product) or https://github.com/chainstacklabs/mcp-server/issues/new (MCP server). Works with or without an API key; with one, the org info is attached.

Top up a testnet address from Chainstack's faucet. The faucet does not send a fixed amount — it tops the address up to the per-network maximum (e.g. 0.5 ETH for sepolia). If the address already sits above the cap, the call fails with an insufficient-balance error. Describe the behavior to the user as "top up" not "give", and surface the returned `amountSent` so they see the actual delta. One top-up per network every 24 hours: a repeat call for the same network is refused (429) if the same organization or the same address got funds there in the last 24 hours, and the error says when the next top-up is available. Other networks have separate cooldowns. A success is final even if the balance hasn't updated yet; track the returned `transaction` instead of calling again.

Fetch Chainstack's public pricing and return a normalized snapshot. Use this to answer pricing questions before quoting the user: plan fit, overage math, per-chain dedicated-node costs, and add-on pricing (Unlimited Node flat-fee tiers, Yellowstone gRPC streams, Warp transactions, dedicated-node base rates). This tool returns the menu, not the bill — the calling agent does the arithmetic. All prices are list prices in USD; disclaimers are surfaced in the `disclaimers` field. Per-method RU billing rules are NOT in these sources. Plan-level rates (Full Node = 1 RU, Archive Node = 2 RU) are in the markdown, but some EVM archive-state methods (eth_getBalance, eth_call, eth_getProof, eth_getStorageAt, eth_getCode, eth_getTransactionCount, eth_callMany, eth_createAccessList) and all debug_* / trace_* methods are billed at 2 RU on a full node when called against old blocks. For method-level detail, call `search_docs` with "request units" or `get_doc_page("docs/request-units")`. No API key required — sources are fully public. Each call fetches both sources fresh (no caching), so a stale result isn't possible. Returns: A dict with fields: - `pricing_markdown`: raw markdown from chainstack.com/pricing.md. Read this for plan tiers, feature matrix, add-on pricing, support levels, PAYG details, and provider comparisons. - `dedicated_catalog`: user-orderable per-chain dedicated-node SKUs with flavor, regions (as infra slugs like "sgp1"), hourly and monthly prices in USD. - `region_legend`: slug → city name for every region slug in `dedicated_catalog`; use it for display. - `disclaimers`: list-price caveats (Enterprise "from" pricing, etc.). - `sources`, `warnings`: per-source status; warnings are set when a source failed and the result is best-effort. - `fetched_at`: UTC timestamp of this call.

Takes no parameters.