Add Balancer plugin for Base MCP

[tiago-hansen]

Summary

Adds a native Base MCP plugin for Balancer, authored against skills/base-mcp/references/plugin-spec.md.

• New file: skills/base-mcp/plugins/balancer.md — single file; registry entry left to maintainers.

Integration: hybrid

The Balancer GraphQL API (api-v3.balancer.fi, public / keyless) returns swap paths and pool data — not calldata. Calldata is encoded by the @balancer/sdk TS library (Swap.buildCall() / AddLiquidity.buildCall()), whose query() simulation needs Node + an RPC URL. That splits cleanly across surfaces:

• Reads / quotes (sorGetSwapPaths, poolGetPools) → HTTP, every surface → ## Endpoints
• Writes → SDK script (shell) → ## Commands
• Chat-only, no shell → return the quote, fall back to the Balancer web UI

Submission lands on send_calls (unsigned EIP-5792 batch).

v2 / v3 routing (version-aware)

The SOR routes each pair through Balancer v2 or v3 by liquidity, and the two settle differently — the plugin handles both:

• v3 → v3 Router; tokens pulled via Permit2 (onchain allowance batched ahead of the Router call); msg.sender is sender/recipient.
• v2 → Balancer V2 Vault (0xBA1222…BF2C8); a plain ERC20 approval to the Vault, and buildCall requires sender/recipient (otherwise it throws missing parameter sender/recipient for Balancer v2).

The build script detects v2 from the SOR paths, passes sender/recipient only when needed, and emits protocolVersion so the agent assembles the correct approval batch.

Frontmatter

field	value
integration	hybrid
chains	[base, ethereum, arbitrum, optimism, avalanche] (Balancer V3 ∩ Base MCP send_calls)
requires.shell	optional
auth	none
risk	[slippage, low-liquidity]

Conformance

Self-reviewed against the spec's Authoring Checklist: all required + conditional sections present, canonical heading names and order, shell-less/chat-only behavior stated in ## Surface Routing, and ## Submission names send_calls with the exact { to, value, data } mapping and version-dependent approval batching.

Opening as a draft for maintainer review.

🤖 Generated with Claude Code

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 1 Sum 2

[stephancill]

Thanks for the submission. The frontmatter and structure are spec-conformant and the v3 swap path builds and submits correctly. There is a blocking correctness issue in the build script:

Required

• Revert the SKILL.md plugins-table row. Plugins shouldn't add themselves to the registry — maintainers will register them when the program is ready. Limit the PR to plugins/balancer.md.
• build-swap.mjs omits sender/recipient on the basis that "v3 makes msg.sender the sender/recipient." That is v3-only. The SOR routes through both v2 and v3 depending on liquidity, and v2-routed pairs cause buildCall to throw: Input Validation: Swap input missing parameter sender/recipient for Balancer v2. A significant share of common Base pairs currently route v2 (e.g. WETH->cbETH, USDC->DAI, WETH->BAL), so the headline example fails intermittently. Pass sender/recipient (the wallet from get_wallets) whenever any path has protocolVersion: 2.
• v2 settles through the V2 Vault, so the Permit2 onchain-allowance batch in ## Submission is v3-specific. Document the version-dependent submission (v2 uses Vault approval, not Permit2).