Skip to main content
This page is both a migration guide and an executable runbook for AI coding agents. Paste the one-liner below into any AI coding agent — Claude Code, Codex CLI, Cursor, Windsurf, Gemini CLI, Antigravity — and the agent will fetch this page and follow it.

​
Quick start

Paste this into your AI agent: 
get docs.chainstack.com/docs/migrate-to-chainstack-with-ai.md
The agent fetches this page and walks through the migration in three phases: Assess → Plan → Implement. It stops after Plan and waits for your approval before touching the codebase.

​
Tools used

The runbook calls the Chainstack MCP server — a single remote server that covers docs search, deployment options, node and project management, platform status, faucets, and pricing. Two URLs, two different purposes:
  • mcp.chainstack.com — the agent onboarding page. Point any AI agent at this URL and it reads setup instructions, tool reference, and install options.
  • https://mcp.chainstack.com/mcp — the actual JSON-RPC 2.0 endpoint the agent calls once it’s set up.
You don’t have to register the MCP server with your LLM client. The server accepts JSON-RPC 2.0 over plain HTTP, so the agent can call it directly — on demand, no persistent connection, no forced tool list in the context window. If you prefer a lighter install, the server ships a skill file at mcp.chainstack.com/skill that drops into ~/.claude/skills/chainstack/ (or the equivalent for your agent) and triggers HTTP calls only when relevant. Formal MCP registration works too — pick whichever fits your workflow.
The Assess phase mostly runs on no-auth tools (search_docs, get_doc_page, get_chainstack_pricing, contact_chainstack). The get_deployment_options, Dry run, and Implement steps require a Chainstack API key.
How to read this page. When the runbook links to another Chainstack doc page (for example, /docs/dedicated-node), call get_doc_page to fetch it — don’t follow the relative link directly.

​
Agent instructions

Migrate this project’s blockchain RPC endpoints to Chainstack.

​
Assess

​
Coverage check

  1. Scan the codebase for all blockchain RPC endpoint URLs that are not Chainstack. Check source code, environment variables, config files, and hardcoded URLs.
  2. For each endpoint found, identify:
    • The blockchain protocol and network (mainnet/testnet).
    • The RPC methods used (standard, debug/trace, archive queries like historical block lookups).
    • Whether WebSocket, gRPC, or Solana Geyser is needed.
  3. Check what Chainstack supports. Do not use web search for Chainstack docs — call the MCP server directly:
    • search_docs — search for each protocol found in the codebase to check supported networks, node types, available API methods, and features like debug/trace or archive.
    • get_doc_page — get the full doc page for details on a specific chain.
    • get_deployment_options (API key required) — all supported chains, networks, node tiers, and features (full, archive, debug_trace).
  4. Report what’s fully covered, what needs a specific node tier, what’s unsupported, and any endpoints that are already dead or deprecated.
Do not rely on training data for what Chainstack supports. Always verify against the Chainstack docs and get_deployment_options. Docs are the primary source of truth — they cover features, methods, node configurations, and console-only capabilities. get_deployment_options supplements docs with exact deployable chains, tiers, and features. If something can’t be verified through either, flag it as uncertain and direct the user to Chainstack support.
For pricing questions, call get_chainstack_pricing. For unsupported chains that may be available as dedicated deployments, sales inquiries, or anything else that needs a Chainstack human, call contact_chainstack — it works for any user, including those who don’t use Telegram. Flag the following if the codebase needs them — they require manual setup in the Chainstack console and are not available through the API: Answer any follow-up questions — use the MCP server tools to provide accurate, specific answers.

​
Dry run

If the user already has Chainstack nodes deployed (API key required):
  1. Use list_nodes to get all deployed Chainstack endpoints.
  2. For each RPC method found in the codebase, send a test request to the corresponding Chainstack endpoint to verify it works.
  3. Optionally, if the codebase has RPS patterns (batch calls, concurrent requests, polling intervals), test at that throughput. Use search_docs to find additional information and recommended optimizations.
  4. Report what works, what fails, and any rate limit or method support gaps.

​
Plan

  1. For each endpoint to migrate, lay out the specific replacement — which existing Chainstack node covers it, or whether a new node needs to be created. Flag anything that needs the user’s input (tier choice, project assignment, unsupported chains).
STOP here. Present the plan and wait for the user to approve or adjust before making any changes. Do not proceed to implementation until the user explicitly confirms. Answer any follow-up questions — use the MCP server tools to provide accurate, specific answers. For implementation issues, direct the user to Chainstack support.

​
Implement

  1. Create any nodes needed via create_node (use global nodes for instant deployment).
  2. Replace each endpoint with the corresponding Chainstack URL from list_nodes.
  3. Summarize what changed.

​
Support

For implementation issues, contact Chainstack support. For unsupported chains that may be available as dedicated deployments, reach out to @ChainstackGrowthBot on Telegram.
Last modified on April 20, 2026