Skip to main content
Glama
Sign In
BlockRun MCP

BlockRun MCP

Official
by BlockRunAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

blockrun_wallet

Manage wallet balances and spending budgets: check USDC, switch active chains, set global or per-agent caps, and fund wallets before running paid tools.

Instructions

Call this tool to manage the BlockRun payment wallet and control agent spending budgets.

Call this FIRST if any other blockrun_* tool returns a payment/balance error. Call this to check your current USDC balance before expensive operations. Call this to set spending limits before spawning child agents.

If this server is running on a BlockRun API key (BLOCKRUN_API_KEY), there is no wallet and no chain: status reports the account, and setup/qr/deposit/chain do not apply. Credit is managed at https://user.blockrun.ai/dashboard/credits.

In wallet mode the server holds TWO wallets — one on Solana, one on Base — but pays on ONE active chain at a time. status shows both addresses/balances and which is active. New installs default to Solana; an existing Base wallet keeps Base until you switch.

To switch chain (no env vars, no file editing, no restart):

  1. action:"chain" chain:"solana" → provisions + activates the Solana wallet

  2. action:"setup" → address + funding QR for the active chain Switch back with action:"chain" chain:"base". Almost everything now settles on either chain; only blockrun_defi (DefiLlama) and blockrun_modal are Base-only, plus native Anthropic (claude-*) in blockrun_chat.

Arc (Circle's chain) is a third option: action:"chain" chain:"arc". It pays from the SAME address as Base (one EVM key), funded with USDC on Arc, and serves everything Base does.

Actions:

  • status (default): Both wallet addresses + USDC balances, active chain, session spending

  • deposit: Buy USDC with a card — mints a one-time Coinbase Onramp link and opens it in the browser (Base only; funds settle into your own wallet). Paid tools auto-open this on an out-of-funds failure; call it directly to fund up front.

  • setup: Get funding instructions + QR code for the ACTIVE chain (call this when balance is 0)

  • qr: Open QR code (active chain) in system viewer

  • chain + chain:"base"|"solana"|"arc": Switch the active payment chain (omit chain: to just see the current one)

Budget controls:

  • budget + budget_action:"set" + budget_amount:1.00 → Set global spend cap

  • budget + budget_action:"check" (the default) → Report the cap, spend and remaining

  • budget + budget_action:"clear" → Remove a cap set here If the operator started the server with BLOCKRUN_BUDGET_LIMIT, that value is a ceiling this tool can only lower: set above it is clamped, clear restores it, and agent_limit is clamped to it. Only a restart with a new env raises it.

Multi-agent orchestration:

  • delegate + agent_id:"research" + agent_limit:2.00 → Allocate $2 to a child agent

  • revoke + agent_id:"research" → Remove a child agent's cap (its spend is kept; re-delegating the id carries it)

  • report → See per-agent spending breakdown

Usage pattern for multi-agent systems:

  1. blockrun_wallet action:"delegate" agent_id:"worker-1" agent_limit:1.00

  2. Pass agent_id:"worker-1" to all blockrun_chat/search/etc calls for that agent

  3. blockrun_wallet action:"report" to audit spending

Do NOT call this for actual AI queries — use blockrun_chat for that.

Input Schema

NameRequiredDescriptionDefault
chainNoTarget chain for action='chain'. Omit to view the current active chain.
actionNoWhat to dostatus
agent_idNoAgent identifier for delegate/revoke/report actions
agent_limitNoBudget limit in USD for this agent (required for delegate action)
budget_actionNoBudget action (for action='budget'). Defaults to 'check', which only reports.
budget_amountNoBudget limit in USD (for budget_action='set')

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.55.0
    • changedInput schema / properties / chain / enum
      Previous value: -[
-  "base",
-  "solana"
-]New value: +[
+  "base",
+  "solana",
+  "arc"
+]
  2. Changed1 schema field changedv0.51.1
    • changedInput schema / properties / budget_action / description
      Previous value: -"Budget action (for action='budget')"New value: +"Budget action (for action='budget'). Defaults to 'check', which only reports."
  3. Changed1 schema field changedv0.45.1
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  4. Changed1 schema field changedv0.31.6
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "status",
-  "setup",
-  "qr",
-  "chain",
-  "budget",
-  "delegate",
-  "revoke",
-  "report"
-]New value: +[
+  "status",
+  "deposit",
+  "setup",
+  "qr",
+  "chain",
+  "budget",
+  "delegate",
+  "revoke",
+  "report"
+]
  5. First observedv0.16.2

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare the safety profile (not read-only, not destructive, closed-world), so the description carries real weight and delivers: API-key mode vs wallet mode, two wallets on one active chain, defaults for new installs, the BLOCKRUN_BUDGET_LIMIT ceiling that clamps set/clear, and that deposit opens a browser and mints a one-time onramp link. It stops short of stating return shapes or error behavior for each action, but the operational context is unusually rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the highest-value guidance (error recovery, pre-flight balance check) and organized under clear headings for actions, budgets, and delegation. It is long for a tool description and the multi-agent "usage pattern" restates delegation guidance already given above, so there is some redundancy against an otherwise tight structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nine-action tool with no output schema, the description covers every action, the two deployment modes, chain-switching procedure, budget ceiling semantics, and delegation lifecycle. Nothing an agent needs to call any action correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond it: chain only applies to action:"chain" and omission views the current chain, budget_action defaults to a read-only check, agent_limit is required for delegate, and agent_id must be threaded into other blockrun_* calls. That cross-tool semantics for agent_id is not in the schema at all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: manage the BlockRun payment wallet and control agent spending budgets. It explicitly excludes the sibling it is most likely to be confused with ("Do NOT call this for actual AI queries — use blockrun_chat"), so an agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit triggers ("Call this FIRST if any other blockrun_* tool returns a payment/balance error", "check balance before expensive operations", "set spending limits before spawning child agents") and names alternatives for the out-of-scope case. It also supplies a step-by-step multi-agent workflow that ties this tool to the rest of the blockrun_* family.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools