# Pocket Network MCP > Pocket Network RPC Nodes API provides decentralized access to blockchain data. Use this server to query account states, retrieve block history, or send complex relay requests across multiple chains without relying on single centralized endpoints. ## Overview - **Category:** developer-tools - **Price:** Free - **Tags:** rpc-nodes, web3-infrastructure, decentralized-api, pokt-network, blockchain-data ## Description You're hooking your AI client up to **Pocket Network** through an MCP server, and it’s all about decentralized control. This isn't some single choke point; you get direct access to read and write blockchain data by talking straight to a whole mesh of nodes. It lets you do stuff across multiple chains without trusting any one centralized endpoint. When you need to check up on an account, you use `get_account` to grab the current balance and full status details for any Pocket Network address you throw at it. If you're digging into how the network works historically, you pull all necessary data for a specific block using `get_block`, letting you inspect the chain history deep down. You can check what’s going on with the infrastructure itself; `get_node` spits out status and ID data for any single node running on Pocket Network, so you know it's healthy. For managing applications, you first use `get_app` to get general info about a deployed app, then you nail down which specific nodes are handling the action by calling `get_session`. If you need to finalize an action—like staking or sending POKT—you run `submit_transaction`, which submits that signed data directly onto the Pocket Network. But it doesn't stop there. The real power is in connecting disparate systems. When you use `relay_request`, you’re broadcasting a custom RPC request payload to any external blockchain network, letting your agent talk to chains outside of Pocket. You'll send an arbitrary operation—like checking the block number on Ethereum or reading data from Polygon—and it handles the whole package: the payload, metadata, and proof objects for that external chain. Think about how you manage complex state changes. Your AI client can use `get_session` to figure out exactly which specific set of nodes are running for a given application session, giving you visibility into the resources doing the heavy lifting. This setup makes sure your agent doesn't guess where it needs to look. Your whole process flows like this: You tell your AI client what data it needs—maybe it’s the account balance, or maybe it's submitting a new transaction. Your client then routes that command through the appropriate tool. If you need external chain data, `relay_request` takes over and hits that target blockchain. If you're sticking to Pocket Network, `get_account`, `get_block`, or `submit_transaction` handles it. The system doesn't just read; it verifies and finalizes actions across the decentralized graph. ## Tools ### get_account Retrieves the current balance and status details for a specific Pocket Network account address. ### get_app Fetches general information about an application deployed on the Pocket Network. ### get_block Retrieves all necessary details for a specific block, allowing you to inspect chain history. ### get_node Gets status and identification data for an individual node running on the Pocket Network. ### relay_request Sends an arbitrary RPC request payload to any external blockchain network. ### get_session Retrieves details about a current application session, including assigned nodes. ### submit_transaction Finalizes a transaction (staking or POKT transfer) by submitting the signed data directly to the Pocket Network. ## Prompt Examples **Prompt:** ``` Get account details for the POKT address 12345... ``` **Response:** ``` I've retrieved the account details for address 12345... The current balance is 5,000 POKT and the account is currently in an 'Unstaked' state. ``` **Prompt:** ``` Show me the nodes assigned to app public key ABCDE for Ethereum (0021). ``` **Response:** ``` Querying session details... I found 5 nodes assigned to your application for the current session on Ethereum. Would you like the specific addresses of these nodes? ``` **Prompt:** ``` Relay this RPC payload to the blockchain: { "method": "eth_blockNumber", ... } ``` **Response:** ``` Sending relay request through Pocket nodes... The request was successful. The current block height on the target chain is 18,450,210. ``` ## Capabilities ### Query account details Fetch current balance and state information for any specified Pocket Network address using `get_account`. ### Send cross-chain RPC requests Broadcast a specific operation (like checking the block number) to an external blockchain using `relay_request`. ### Submit state changes and transactions Finalize actions on the chain by submitting signed data, such as staking or sending POKT, via `submit_transaction`. ### Inspect network infrastructure Get real-time details about nodes and blocks using `get_node` and `get_block`, helping you verify the network's health. ### Manage application sessions Determine which specific set of nodes are running for a given application or session with `get_session` and `get_app`. ## Use Cases ### Validating a New Staking Contract A DApp builder needs to test if their staking contract will actually work across different chains. Instead of deploying multiple services, they use `get_node` first to check the network health, then call `relay_request` to send a mock transaction payload to several target blockchains. This verifies connectivity before spending any real gas. ### Auditing an Account's History A security team needs to trace every movement for a high-value account. They use `get_account` to check the current balance, and then use `get_block` iteratively, passing block numbers to see exactly when and how the funds moved through the chain. ### Automating Cross-Chain Data Fetching A bot needs to verify that an application is properly connected. It runs `get_session` to find the assigned nodes, then uses those node details in a script alongside `get_app` data. This confirms both the app's intended scope and its current operational status. ### Executing a Complex DeFi Trade A user needs to execute a trade that requires multiple steps: first, they confirm their balance using `get_account`. Then, if everything looks good, the agent calls `submit_transaction` with the signed payload. The system handles the state change atomically. ## Benefits - **Decentralization:** Stop relying on single RPC endpoints. You use `relay_request` to send payloads across any blockchain, making your app resilient when one network goes down. - **Full Lifecycle Control:** Manage the entire process from checking session details (`get_session`) to submitting the final transaction using `submit_transaction`. It's all in one place. - **Deep State Visibility:** Need to know what happened? Use `get_block` and `get_account` together. You get a clear picture of history—the block data, and then who owns it. - **Infrastructure Insight:** Before you build anything, check the plumbing. Query node status with `get_node` to make sure your network connections are solid before deployment. - **Multi-Chain Agility:** The single biggest win is using `relay_request`. It means you can write code that talks to Bitcoin *and* Ethereum without changing endpoints or libraries. ## How It Works The bottom line is: it lets your AI client talk to multiple blockchains using one standard interface. 1. First, connect your AI client to the server and provide the required Pocket Node URL (POCKET_NODE_URL). 2. Next, tell your agent exactly what you need—for example, 'Send a block number request to Ethereum.' 3. The agent executes the necessary tool (`relay_request`), sends the payload across the decentralized nodes, and returns the result. ## Frequently Asked Questions **How does get_account work in Pocket Network?** The `get_account` tool takes a specific address and returns its current data, including its balance and operational state (e.g., 'Unstaked'). It's your primary way to check funds. **Do I need get_session before relay_request?** No, they serve different purposes. `get_session` helps you see which nodes are assigned to an app for a current run. `relay_request` is used when you need to send data to an entirely different external blockchain. **What's the difference between get_block and relay_request?** `get_block` reads historical, structured information about a specific block on this network. `relay_request`, however, is for sending an arbitrary command or payload to any external blockchain. **Can I use submit_transaction if I don't know the exact payload?** No. The tool requires a signed transaction object. You must have the necessary data and signatures prepared before calling `submit_transaction` to avoid failure. **What should I do if my connection fails when using get_node?** Check your POCKET_NODE_URL for typos or outdated endpoints. The tool will return a connectivity error code (e.g., 503) if the URL is inaccessible or misconfigured. Always verify the endpoint before querying node details. **If relay_request fails, how do I diagnose the payload issue?** The response body includes specific error codes explaining failure reasons (e.g., invalid method signature, missing proof). Inspect this detailed output; it tells you exactly which piece of the external RPC request needs correction. **Are there rate limits when calling get_account frequently?** Yes, continuous high-frequency calls can trigger throttling. When you receive a 429 status code, implement an exponential backoff strategy in your agent's logic before retrying the account query. **Does get_app return real-time data or just application metadata?** It returns the current state of the app details as indexed by the network. If the underlying data changes rapidly, you might need to run a secondary verification tool like `get_session` for immediate consistency checks. **Can I send requests to other blockchains like Ethereum using this server?** Yes. Use the `relay_request` tool to send RPC payloads to external chains. You will need to provide the payload, metadata, and session proof. **How do I check which nodes are currently serving my application?** You can use the `get_session` tool by providing your App Public Key and the Blockchain ID. It will return the set of nodes assigned to that specific session. **Is it possible to submit POKT transactions through this interface?** Yes, the `submit_transaction` tool allows you to send hex-encoded signed transactions directly to the Pocket Network.