Pocket Network MCP for AI. Query, Submit, and Relay Across Multiple Blockchains
Gemini Works with every AI agent you already use
…and any MCP-compatible client
How this MCP server connects to your AI agent
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.
What AI agents can do with Pocket Network (Decentralized RPC Nodes API) Automation
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.
Fetch current balance and state information for any specified Pocket Network address using get_account.
Broadcast a specific operation (like checking the block number) to an external blockchain using relay_request.
Finalize actions on the chain by submitting signed data, such as staking or sending POKT, via submit_transaction.
Get real-time details about nodes and blocks using get_node and get_block, helping you verify the network's health.
Determine which specific set of nodes are running for a given application or session with get_session and get_app.
Ask an AI about this
Waiting for input…
What AI agents can do with Pocket Network: 7 Tools for Blockchain Data Access
Use these tools to read the state of accounts, inspect network nodes, or send relay requests across various blockchains through your AI client.
Make your AI actually useful.
Add this MCP to Claude, Cursor, or Windsurf and your AI stops guessing. It gets real tools to look things up, take action, and handle the stuff you keep doing by hand.
Start using Pocket Network (Decentralized RPC Nodes API) on VinkiusGet 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...
Get Node
Gets status and identification data for an individual node running on the Pocket...
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.
Security and governance baked right in.
Pick your AI client below to get set up. Just create a Vinkius account, subscribe, and you're instantly up and running. We handle the entire backend infrastructure, delivering out-of-the-box support for HTTPS Streamable, SSE, and OAuth2—zero messy routing required.
Claude AI
Open Claude Settings
Go to claude.ai, click your profile icon, then navigate to Customize → Connectors.
Add Custom Connector
Click the "+" button and select Add custom connector. Paste your Vinkius endpoint URL:
https://edge.vinkius.com/[YOUR_TOKEN_HERE]/mcp
Replace [YOUR_TOKEN_HERE] with your token
from cloud.vinkius.com. For OAuth-protected servers, expand
Advanced settings to add credentials.
Start a conversation
Open a new chat. The Pocket Network integration is available immediately — no restart needed.
Choose How to Get Started
Build a custom MCP for your own tools, or connect a ready-made integration from our catalog.
Build Your Own
Turn any API into an MCP. Import a spec, define Agent Skills, or deploy with MCPFusion.
- Import from OpenAPI, Swagger, or YAML specs
- Create Agent Skills with progressive disclosure
- Deploy to edge with MCPFusion framework
- Built in DLP, auth, and compliance on every call
- Real time usage dashboard and cost metering
- Publish to catalog or keep private
Make Your AI Do More
Start with Pocket Network (Decentralized RPC Nodes API), then connect any of our 5,100+ other servers whenever your AI needs more. One click, no limits.
- Use this MCP plus 5,100+ others, all in one place
- Add new capabilities to your AI anytime you want
- Every connection is secured and compliant automatically
- Track usage and costs across all your servers
- Works with Claude, ChatGPT, Cursor, and more
- New servers added to the catalog every week
Independent Platform Disclaimer: Vinkius is an independent platform and is not affiliated with, endorsed by, sponsored by, verified by, or otherwise authorized by Pocket Network. All third-party trademarks, logos, and brand names are the property of their respective owners. Their use on this website is strictly for informational purposes to identify service compatibility and interoperability.
VINKIUS INFRASTRUCTURE
Cloud Hosted
Managed infra
V8 Isolated
Sandboxed per request
Zero-Trust Proxy
No stored credentials
DLP Enforced
Policy on every call
GDPR Compliant
EU data residency
Token Compression
~60% cost reduction
Built on the Model Context Protocol (MCP) for Claude, ChatGPT, Cursor, and more
The Model Context Protocol standardizes how applications expose capabilities to LLMs. Instead of operating in isolation, your AI gains direct access to external platforms, live data, and real-world actions through secure, standardized connections.
This connection provides 7 powerful capabilities that interface natively with Claude, ChatGPT, Cursor, and other compatible AI platforms. No middleware. No custom integration required.
Checking blockchain data used to require a dozen different dashboards and API keys., Solved with Vinkius AI Gateway
Today, checking the status of an account means logging into one dashboard for Chain A, another console for Chain B, and then manually compiling a report on gas costs from a third service. If you need to know how many nodes are connected, you're probably opening three separate terminal windows just to compare logs.
With this MCP server, your AI agent handles the sprawl. You ask it one question—for instance, 'What is the current block height across our primary chains?'—and the agent uses tools like `get_block` and `relay_request` to gather all that data and give you a single, clean answer.
The `submit_transaction` tool allows you to finalize complex state changes directly from your chat.
Before this server, submitting any transaction—even just staking POKT—was a multi-step process: get the correct payload structure, sign it locally using dedicated software, and then find the right endpoint URL to submit it. One missed comma meant losing gas.
Now, you tell your agent what you want to do (`submit_transaction`). The agent handles the signing process and submits the final state change through the secure network layer. It’s done.
What your AI can actually do with this
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.
019e5d47-fb83-7358-86da-9aa909b63dd7 
Here's how it actually works
The bottom line is: it lets your AI client talk to multiple blockchains using one standard interface.
First, connect your AI client to the server and provide the required Pocket Node URL (POCKET_NODE_URL).
Next, tell your agent exactly what you need—for example, 'Send a block number request to Ethereum.'
The agent executes the necessary tool (relay_request), sends the payload across the decentralized nodes, and returns the result.
Who is this actually for?
Web3 developers who get stuck when their application needs data from more than one blockchain. Node operators who need a single place to check network health across chains, or DApp builders tired of building complex API wrappers.
Builds multi-chain applications that read account data (get_account) and write transactions (submit_transaction) without depending on a single centralized RPC provider.
Monitors the health of their infrastructure by querying node details (get_node) or checking block heights using get_block directly from an agent chat.
Automates development checks, such as verifying session assignments (get_session) and testing transaction relays (relay_request), minimizing manual deployment steps.
What Changes When You Connect
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.
See it in action
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.
The honest tradeoffs
Treating it like a single-chain API
Writing code that only assumes one endpoint exists for all data, forcing you to use get_account when the actual requirement was cross-chain relay.
Always think decentralized. If your payload needs to hit Chain X or Chain Y, don't just call a single read function. Use relay_request and pass the specific chain identifier in the payload metadata.
Reading data then submitting without validation
Calling submit_transaction immediately after getting an account balance, assuming no other process changed the funds in between.
Always read the current state first. Use get_account to verify the available funds before constructing and calling submit_transaction. The agent needs this check.
Over-relying on basic reads
Only using get_block when you actually need to communicate a specific method, like checking the current state of an external contract.
When you need to run a function on the chain (not just read history), bypass simple getters. Use relay_request and specify the exact RPC method in your payload.
When It Fits, When It Doesn't
Use this server if your primary problem is multi-chain interoperability or state management across different ledgers. If you need to send a request that reads data (like checking a block number) but must hit an external chain, relay_request is the answer.
Don't use this if all you need is basic, single-chain read access and don't care about decentralization; then a dedicated RPC client might be simpler. Also, if your task never involves changing state—only reading cached data—you might get cleaner results from simple getter tools like get_account instead of the generalized power of relay_request.
Remember: this server is for complex interactions. Read first (get_block, get_node), then decide if you need to write/change state (submit_transaction).
Questions you might have
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.
We've already built the connector for Pocket Network. Just plug in your AI agents and start using Vinkius.
No hosting. No infrastructure. No complex setup.
All 7 tools are live and waiting.
You're up and running in seconds.
Gemini Vinkius gives your AI agents access to the full catalog of app connectors, all fully managed, secure, and enterprise-ready. One subscription, every tool you need.
Built, hosted, and secured by Vinkius. You just connect and go.