pod
Other formats agents might prefer:
markdownjsonllms.txt

Agent? You probably want markdown or json, or Pod over MCP.

Reported issues for mina-mcp-server

Pod holds 17 of 17 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to mina-mcp-server.

Most discussed

get_block: passing height: null trips daemon's 'exactly one of' guard after archive-DB resolve

Summary

Follow-up to #4. The archive-DB resolution path (height → state_hash) works correctly, but the subsequent daemon call now fails with:

Must provide exactly one of state hash, height

Root cause: the variables object sent to the daemon includes height: null alongside the resolved stateHash. The Mina daemon's block resolver treats an explicit null as "provided" for the purpose of its exactly-one-of check, so a request with { stateHash: "3N...", height: null } is rejec

Read the thread · 2026-05-11 · closed · 2 comments

get_best_chain fails: 'coinbaseReceiver' not defined on ConsensusState

Summary

get_best_chain (tutorial mode) errors out against the daemon with:

Field 'coinbaseReceiver' is not defined on type 'ConsensusState'

The daemon exposes coinbaseReceiverAccount { publicKey } on ConsensusState, not a bare coinbaseReceiver field. The bestChain query in the MCP server requests the wrong field name.

Reproduction

Tutorial mode (lightnet from docker-compose.tutorial.yml), daemon synced:

> mcp__mina-sandbox__get_best_chain { "maxLength": 5 }
Er

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/3) · 2026-05-11 · closed · 2 comments

### Adopt Mina + archive-node SDKs as the internal implementation layer

## Why

Today most tools hand-roll GraphQL queries against the daemon and archive node. That's where every bug in #3 / #4 / #5 / #12 originated — we own the GraphQL shape, so when upstream renames a field we don't find out until a user hits it.

The Mina team has now published official SDKs for both the daemon and the archive node. Using those internally as the implementation layer would:

- Push schema-drift discipline onto the SDK team (their CI catches the rename, ours inherits the fix on dep

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/31) · 2026-05-12 · closed · 1 comment

### get_account without 'token' fails: Missing variable `token`

## Summary

`get_account` is documented as having `token` optional (defaulting to MINA), but omitting it returns:

Missing variable `token`


Passing `token: "1"` explicitly works, and the response then shows the canonical MINA token id (`wSHV2S4qX9jFsLjQo8r1BsMLH2ZRKsZx6EJd1sbozGPieEC4Jf`).

## Reproduction

Tutorial mode, daemon synced:

mcp__mina-sandbox__get_account { "publicKey": "B62q..." } Error: Missing variable `token`

mcp__mina-sandbox__get_account { "publicKey": "B

Read the thread · 2026-05-11 · closed · 1 comment

get_block with only 'height' fails: Missing variable stateHash

Summary

Calling get_block with { height: N } and no stateHash returns:

Missing variable \`stateHash\`

The MCP tool schema documents height and stateHash as alternatives, but the underlying daemon resolver appears to require stateHash to be non-null even when height is supplied. The MCP server passes the variables through unchanged, so the failure surfaces to the caller.

Reproduction

Tutorial mode, daemon synced:

> mcp__mina-sandbox__get_block { "height": 128

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/4) · 2026-05-11 · closed · 1 comment

### Live-mode tools overflow MCP token budget on busy networks (get_best_chain, get_block, rosetta_block)

## Symptom

Multiple read tools return responses that exceed the MCP client's per-tool result-size budget on real public networks (devnet at typical traffic), making the tools effectively unusable for LLM consumption without manual workarounds.

Observed against devnet (tip ~519,000, ~60–70 user commands per block):

| Tool | Args | Response size | Outcome |
|---|---|---|---|
| \`get_best_chain\` | \`maxLength: 5\` | 173,650 chars | exceeds budget; spilled to disk |
| \`get_block\` | \`stateHash

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/32) · 2026-05-13 · closed · 0 comments

### Hosted Fly sandbox: rate limiting + /metrics endpoint

## Why

The hosted sandbox at \`mina-mcp-sandbox.fly.dev\` is publicly reachable and currently has no rate limiting. An aggressive (or buggy) agent can hammer the underlying lightnet through MCP tool calls — affecting other users sharing the same Fly machine, and potentially the upstream o1Labs daemon endpoints in live mode.

Separately, we have no visibility into what tools users actually call, latency distributions, or error rates. We're flying blind on the deployed surface.

## Scope

### Rat

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/30) · 2026-05-12 · closed · 0 comments

### Add docs/examples.md prompt cookbook

## Why

The README has exactly one worked example (end-to-end payment in tutorial mode). That undersells what the server can do — and the more curated example prompts a user sees, the faster they can spot the one closest to their use case.

A handful of natural-language prompts that drive multi-tool sequences end-to-end would double as:

1. **Documentation** — concrete starting points for new users.
2. **Regression seed** — feed them through the server periodically and check the LLM still comple

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/29) · 2026-05-12 · open · 0 comments

## Most recent

### Snapshot mode: bundle SQLite snapshot for zero-infra usage

## Why

The README's roadmap already calls this out: snapshot mode currently requires the user to bring up Postgres via docker-compose, which is the single biggest onboarding cliff in the project. Bundling a SQLite snapshot inside the npm package would collapse snapshot mode into the same \`npx\`-and-go story as live mode.

## Scope

- [ ] Build a SQLite version of the archive schema that the snapshot-mode tools can read.
- [ ] Add a CI job that periodically (weekly?) regenerates a fresh devnet 

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/28) · 2026-05-12 · open · 0 comments

### Audit tool descriptions and error messages for LLM-friendliness

## Why

Tool descriptions are the **actual UX surface** of an MCP server: an LLM picks tools by reading their descriptions, and recovers from failures by reading their error messages. The \`hints[]\` array returned by \`describe_state\` is a great example of this pattern done right — but it's not applied consistently across the other 23 tools.

## Scope

- [ ] **Descriptions** — for each tool, confirm it answers:
  - When should the LLM reach for this? (\"Use this when you need…\")
  - What does

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/27) · 2026-05-12 · closed · 0 comments

### Live-write mode: security hardening pass for in-process signer

## Why

#19 landed live-write mode with in-process signing + multi-wallet. The server now holds signing keys and produces signed transactions on behalf of an LLM. That's a meaningfully different threat model from the read-only live mode, and we should do a focused hardening pass before this mode is widely advertised.

## Scope

- [ ] **Key handling**
  - [ ] Enforce strict permissions on \`wallets.json\` (\`0600\`) at startup; refuse to load otherwise.
  - [ ] Document recommended on-disk encryp

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/26) · 2026-05-12 · open · 0 comments

### Add CHANGELOG.md and adopt semver discipline

## Why

We're at \`v0.5.0\` with no \`CHANGELOG.md\`. Users wiring this into agents need to know what changed between versions — especially when a release includes a breaking tool-signature change or a behavioral shift.

Right now \"what's new in 0.5.0?\" is only answerable by reading git log. That's fine for the authors; it's terrible for downstream users pinning a version.

## Scope

- [ ] Add \`CHANGELOG.md\` following [Keep a Changelog](https://keepachangelog.com/).
- [ ] Backfill entries fo

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/25) · 2026-05-12 · closed · 0 comments

### CI: scheduled smoke run of live-mode tools against real devnet/mainnet

## Why

Bugs like #3 (\`coinbaseReceiver\` rename) happen because the upstream Mina daemon GraphQL schema drifts and our unit tests don't talk to a real daemon. By the time a user hits the failure, we've already shipped a broken release.

## Scope

- [ ] Add a GitHub Actions workflow that runs on a daily cron (and on PR to \`main\`).
- [ ] Boots the MCP server in \`--mode live\` against \`devnet\`, then against \`mainnet\` (and \`mesa\`, tolerating preflight failures).
- [ ] Calls every read-onl

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/24) · 2026-05-12 · closed · 0 comments

### Validate GraphQL response shapes with Zod at the daemon/archive boundary

## Why

Every closed bug so far (#3, #4, #5, #12) was a GraphQL response- or argument-shape mismatch that escaped to runtime:

- #3 — \`coinbaseReceiver\` typo in a selection set
- #4 — \`get_block\` required \`stateHash\` but tool didn't pass it
- #5 — \`get_account\` blew up because \`token\` wasn't supplied
- #12 — passing \`height: null\` tripped the daemon's \"exactly one of\" guard

These would all have surfaced at startup (or in a unit test) if we validated GraphQL request args + response

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/23) · 2026-05-12 · closed · 0 comments

### Distribution: improve discoverability, README, and installation guide

## Context

`mina-mcp-server` is functional across snapshot / tutorial / live modes and has a hosted sandbox on Fly.io, but it's effectively undiscoverable today and the README's onboarding path is patchy. To move this from "demo project the authors know how to run" to "MCP server a Mina-curious AI developer can wire up in five minutes," we need a coordinated distribution pass.

## Goals

- A new user can pick the right mode, install, and verify it works in **under 5 minutes**.
- The project sho

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/22) · 2026-05-12 · open · 0 comments

### Live mode: in-process signer + multi-wallet support for write operations

## Motivation

Live mode is currently read-only because public Mina daemons don't hold user keys. To let an AI agent execute write operations (`send_payment`, `send_delegation`) against devnet/mainnet from a pre-funded warm wallet, the MCP server needs to sign payments client-side and submit them as pre-signed.

The matching real-world workflow:

1. A human funds one (or more) wallets once via the devnet faucet (the captcha'd web form).
2. The MCP server is configured with those wallets' keys.
3

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/19) · 2026-05-11 · closed · 0 comments

### Live mode: surface per-network faucet info in describe_state hints

## Proposal

In live mode, an LLM client has no way to fund an account — `faucet` is hidden (correctly), and devnet/mesa faucets are human-facing web forms, not APIs. If a human asks the agent "I need test MINA on devnet to try this zkApp", today the agent has no in-band way to learn where the faucet is.

Add an optional `faucet` field to `NetworkConfig` (the canonical funding URL for each public network) and surface it in `describe_state`'s `hints[]` so any LLM consuming the snapshot sees it be

[Read the thread](https://github.com/MinaProtocol/mina-mcp-server/issues/15) · 2026-05-11 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/MinaProtocol/mina-mcp-server/issues).