@grokchain/mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GROKCHAIN_CONFIG | No | Path to JSON config (e.g. config/mainnet.json or config/devnet.json). | |
| GROKCHAIN_CLUSTER | No | Cluster to use: localnet, devnet, or mainnet-beta. Default: localnet. | localnet |
| GROKCHAIN_RPC_URL | No | RPC URL (default follows cluster). | |
| GROKCHAIN_PROGRAM_ID | No | CORE program ID; required except localnet. | |
| GROKCHAIN_ROOT_KEYPAIR | No | Path to the human wallet file. | |
| GROKCHAIN_AGENT_KEYPAIR | No | Path to the agent keystore file. | |
| GROKCHAIN_RELAYER_KEYPAIR | No | Path to the relayer keystore file. | |
| GROKCHAIN_INTENTS_PROGRAM_ID | No | INTENTS program ID; required except localnet. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_accountA | Create the GrokAccount PDA for the human root. Root-signed. On localnet uses the local-only CORE id. On devnet uses the grokchain-devnet CORE program. If the root keypair path is missing, returns need_human_signature / need_human_setup and an unsigned tx. Never ask for a seed or key. |
| issue_grantA | Issue a capability Grant PDA to an agent pubkey. Root signs. Agent does not sign issue. expires_at_unix required and must be in the future. allowed_programs max 8, no duplicates, empty deny-all. cap 0 = call-only. v1 allowlist is router mode: localnet allowlists the local-only INTENTS id; devnet allowlists the grokchain-devnet INTENTS id (EYhYtq…). sponsor_eligible means this grant may use YOUR paymaster — not a promise Grok Chain pays. |
| revise_grantA | Replace Grant policy fields. Root signs. Agent cannot revise. Same policy rules as issue_grant. Cannot change the agent (different PDA). |
| revoke_grantB | Revoke a Grant. Root signs. Account is not closed. Agent cannot revoke. |
| check_grantC | Agent consume path. Agent signs. Increments spent_lamports. Does not move SOL. Empty allowlist is denied. cap 0 requires amount 0. Optional root if not in config. Relayer submits if you also call pay. |
| payB | Implemented INTENTS pay. On localnet uses the local-only intents id. On devnet builds against the grokchain-devnet INTENTS program. Agent signs. Relayer is the outer fee payer. Bot never holds SOL. Human-funded SpendVault is the SOL source. Optional sponsor reimburses the relayer from YOUR paymaster. Lands only if the human has rooted the account, issued a grant allowlisting the INTENTS id, funded SpendVault + Paymaster, and set RELAYER_KEYPAIR. Otherwise need_human_signature / need_human_setup. |
| swapA | Honest STUB. INTENTS swap returns IntentStub. Not implemented. Does not call a DEX. |
| deployA | Honest STUB. INTENTS deploy returns IntentStub. Not implemented. |
| callA | Honest STUB. INTENTS call returns IntentStub. Not implemented. |
| get_accountA | Read-only. Fetch the GrokAccount PDA if it exists. No signing. |
| get_grantB | Read-only. Fetch the Grant PDA if it exists. No signing. label is untrusted text. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Each tool has a distinct purpose: account creation/read, grant lifecycle (issue, revise, revoke, check), payment, and stubs for swap/deploy/call. Even the stubs are clearly labeled as not implemented, preventing confusion. The only slight overlap between check_grant and pay is resolved by descriptions: check_grant only increments spent_lamports without moving SOL, while pay executes an actual payment.
The naming pattern is inconsistent: some tools follow verb_noun (create_account, issue_grant, get_grant) while others are single verbs (pay, swap, deploy, call). Additionally, verbs for similar actions vary (issue vs create, revise vs update). Despite this, the names are readable and convey meaning, but the lack of a uniform pattern reduces predictability.
With 11 tools, the server is well-scoped. It covers account management, grant lifecycle, payment, and read operations without excessive fragmentation. Each tool serves a clear role in the domain, and the count fits comfortably within the ideal 3-15 range.
The tool set covers the core workflows: creating and reading accounts, issuing/revising/revoking/checking grants, and making payments. The stubs for swap/deploy/call indicate planned features, not gaps. Missing operations like listing all grants or funding the vault are minor and can be handled externally, so the surface is largely complete.