Chainstack

Quality 63 / 100needs work

23 tools, about 4,225 tokens to load them all · tool set 5b714763c15d · tools last changed 2026-10-12 · checked 2026-10-19 10:52 UTC

Tool changes

• 2026-10-12request_testnet_fundschangeddescription, output schema
  before

  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.

  after · 59% of words in common

  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.

• 2026-10-12create_nodechangedinput schema
• 2026-10-12get_deployment_optionschangedoutput schema
• 2026-10-11get_chainstack_pricingchangeddescription
  before

  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. Design: we pass pricing.md through as raw markdown. Marketing owns that file and its structure changes freely; parsing it server-side would couple us to heading text and table column names we don't control. The LLM reads markdown natively, so handing the raw text to the agent keeps us correct regardless of how the page is restructured. pricing_current.json is parsed into `dedicated_catalog` because it has a stable engineering-owned schema, and the catalog benefits from filtering (to user-orderable SKUs only), unit conversion (cents → USD, milli-cores → cores), and region humanization (via `region_legend`). 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. Already filtered to the ~87 orderable SKUs and unit-converted. - `region_legend`: slug → human city name map covering every region slug that appears in `dedicated_catalog`. Use `region_legend[slug]` to translate for display; `regions` keeps the slug as the canonical identifier. - `disclaimers`: list-price caveats (Enterprise "from" pricing, etc.). - `sources`: URL + ok/error per source; the JSON source carries its own `updated_at`. - `warnings`: populated when a source is unreachable or the JSON parser failed. The tool still returns best-effort results. - `fetched_at`: UTC timestamp of this call.

  after · 69% of words in common

  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.

• 2026-10-11contact_chainstackchangeddescription
  before

  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: "I'll also include your Chainstack account info (org name and ID) so the team can pull up your account immediately — this means significantly faster handling and a more tailored response." 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, or on-chain account details the user hasn't approved sharing - Any information the user hasn't explicitly approved sharing If the user shared sensitive data during the conversation, do NOT include it unless they specifically approve it in the review step. ## Writing an effective message A great message gets the user a faster, more tailored response. Include what you already know from the conversation: - What they're building and at what scale - Current plan and usage (e.g., "Pro plan, ~80M RU/month on Base") - What they need (upgrade, custom pricing, migration help, etc.) - What they've tried or what's not working - Specific numbers when available 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." The difference between a generic reply and a tailored proposal is the context you include. Not for incidents or urgent outages — point users to https://support.chainstack.com/hc/en-us/requests/new to file a support ticket, and https://status.chainstack.com for live status. For feature requests, do NOT use this tool — point users to https://ideas.chainstack.com (product) or https://github.com/chainstacklabs/mcp-server/issues/new (MCP server). Works with or without a Chainstack API key. With a key, the submission includes the user's Chainstack org info for faster account identification and handling.

  after · 79% of words in common

  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.

• 2026-10-11set_node_access_rules_statusadded

  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.

• 2026-10-11delete_node_access_ruleadded

  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.

• 2026-10-11update_node_access_ruleadded

  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.

• 2026-10-11create_node_access_ruleadded

  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.

• 2026-10-11list_node_access_rulesadded

  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.

Showing the latest 10. Full history: list_changes · trend: quality JSON.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.