Solana MCP by Vybe
Solana MCP developer toolkit: wallets, trades, markets, PnL, transfers, onchain, swaps & API tools.
作者提供的说明(英文原文)
Read NablaZ's open record: agent actions under permission, cited onchain. Evidence, not a verdict.
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
通过 4/4 项检查 · 你的提问会经过开发者的服务器(read.nablaz.io)
第一步:你用哪个 AI?
选择你用的应用,步骤会显示在下方。
可连接 Claude · 约 2 分钟
不需要密钥,不用安装程序 · 在 claude.ai 或桌面应用设置一次,即可在聊天中使用 · 免费账户可添加 1 个
CustomizeConnectors
把这里的内容复制到 Claude 中同名的输入框,然后点击 Continue
Readerhttps://read.nablaz.io/mcpAuthentication 保持 Claude 检测到的设置,然后点击 Add
+ConnectorsReader
用 Reader 告诉我你能帮我做什么,然后做一件给我看✓ 如果 Claude 说正在使用 Reader,或回答中出现 Reader 的工具名称,就表示连接成功
菜单名称已于 2026年11月11日 对照 Anthropic 帮助页面核实 · 你的界面可能因版本略有不同
仅企业版 ChatGPT 可连接
适用于网页版 ChatGPT Business、Enterprise 或 Edu,需由工作区管理员或所有者添加 · 使用 Free、Plus 或 Pro:你的 ChatGPT 方案暂时无法自行连接 MCP
Plugins+Add custom MCP server
输入名称,在 Connection 下粘贴地址,勾选风险提示,然后点击 Create as a plugin
Readerhttps://read.nablaz.io/mcp开启新聊天,输入前先从插件列表中选择 Reader
用 Reader 告诉我你能帮我做什么,然后做一件给我看✓ 如果 ChatGPT 说正在使用 Reader,或回答中出现 Reader 的工具名称,就表示连接成功
菜单名称已于 2026年11月11日 对照 OpenAI 帮助页面核实 · 你的界面可能因版本略有不同
可连接 Claude Code · 约 2 分钟
不需要密钥,不用安装程序
Mac:按 Command+空格,输入 Terminal · Windows:打开 PowerShell
claude mcp add --transport http reader https://read.nablaz.io/mcp应能看到 Reader 在列表中并显示已连接
用 Reader 告诉我你能帮我做什么,然后做一件给我看✓ 如果 Claude Code 说正在使用 Reader,或回答中出现 Reader 的工具名称,就表示连接成功
菜单名称已于 2026年11月11日 对照 Anthropic 帮助页面核实 · 你的界面可能因版本略有不同
可连接 Cursor · 约 2 分钟
不需要密钥,不用安装程序
用 Reader 告诉我你能帮我做什么,然后做一件给我看✓ 如果 Cursor 说正在使用 Reader,或回答中出现 Reader 的工具名称,就表示连接成功
菜单名称已于 2026年11月11日 对照 Cursor 帮助页面核实 · 你的界面可能因版本略有不同
可连接 VS Code · 约 2 分钟
不需要密钥,不用安装程序
用 Reader 告诉我你能帮我做什么,然后做一件给我看✓ 如果 VS Code 说正在使用 Reader,或回答中出现 Reader 的工具名称,就表示连接成功
菜单名称已于 2026年11月11日 对照 VS Code 帮助页面核实 · 你的界面可能因版本略有不同
其他支持 MCP 的应用(如 Windsurf、Zed、Gemini CLI)添加方式各不相同,请在应用列表中查看
通过网页连接的应用使用的地址
https://read.nablaz.io/mcpJSON 设置在下方“开发者专用”中
Claude Code
claude mcp add --transport http reader https://read.nablaz.io/mcpCursor (~/.cursor/mcp.json)
{
"mcpServers": {
"reader": {
"url": "https://read.nablaz.io/mcp"
}
}
}VS Code (mcp.json)
{
"servers": {
"reader": {
"type": "http",
"url": "https://read.nablaz.io/mcp"
}
}
}这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
依据这个服务器的连接方式和各应用自己的文档,检查于 2026年11月10日。
通过互联网连接,适用于
ClaudeChatGPTGooseLM StudioMsty StudioCherry StudioCursorVS Code + GitHub CopilotVisual StudioWindsurf (Devin Desktop)ZedKiroClineContinueJetBrains AI AssistantClaude CodeCodex CLIGemini CLIOpenCodenodecodeWarpLibreChatOpen WebUIRaycast
工具名称和描述与服务器在 2026年11月7日 报告的完全一致。这些内容由作者撰写,不是我们写的;我们以纯文本形式显示。
read_subjectReturns every fact the reader has indexed about an address on one chain, as GET /read/:chainId/:address JSON: each fact names its source, carries a permission label of shape (a) to (e), and cites the block, transaction and log index with a command that returns the same log from a
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月11日
注册名称已通过域名 nablaz.io 验证(注册中心会核实域名所有权)
代码最后更新于前天
我们还没有从 GitHub 读取这个仓库
在 122 毫秒内响应(HTTP 200)
无需登录
已读取 1 个工具描述,未发现针对 AI 的隐藏指令
提问、分享技巧或报告无法使用。按“有帮助”数量排序。
还没有评价
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 4 项适用的基础检查中通过了 4 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在作者的云端运行。通过互联网连接,无需安装,但你发送的内容会经过作者的服务器。
GitHub 仓库最后更新于前天,最新版本(0.1.0)于5天前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。它通过 URL 连接,因此也能用于支持远程 MCP 的应用,例如 ChatGPT Business 及以上方案。
同一分类中有:Solana MCP by Vybe, Oracle3 prediction-market arbitrage checks, Polymarket Paper Trader
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:↓ 每周下载量i★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
Solana MCP developer toolkit: wallets, trades, markets, PnL, transfers, onchain, swaps & API tools.
Kalshi and Polymarket data, venue fees, no-arbitrage checks and paper execution for AI agents.
Polymarket paper trading for AI agents: $10k paper money, real order books, official fees.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
An open-source reader for agent payment permissions. It rebuilds, from public chain data, what an address was allowed to spend, what it spent, and under which terms, and keeps every fact next to the command that reproduces it. It reads the NablaZ record and grantee vaults, Coinbase spend permissions, MetaMask delegations and Agent Credit Lines.
It holds no keys, needs no account or API key, and runs anywhere you have an RPC endpoint.
Arbitrum One and Base are both enabled. The NablaZ contracts are live on Arbitrum One only, so on Base the reader indexes the third-party sources alone.
Third-party sources, on both chains:
SpendPermissionManager: SpendPermissionApproved, SpendPermissionUsed, SpendPermissionRevoked.DelegationManager (delegation framework v1.3.0): RedeemedDelegation, with every caveat decoded. For each redemption the reader reads the transaction receipt and keeps the ERC-20 Transfers sent by the delegator. A redemption alone is not a payment; only such a Transfer is.Borrowed, Repaid, Defaulted) at a configured lender. No lender is known on either chain today, so no lender is registered. The decoder ships with tests, and a read with nothing indexed says "nothing indexed" with its block range.NewFeedback from the "Reputation Registry" (who rated which agentId, and where; never the feedback's value, decimals, tags, endpoint or URIs), and the agentWallet and owner histories from the Identity Registry's MetadataSet and ERC-721 Transfer. Addresses from src/generated/erc8004.json (vendor commit pinned there).NablaZ sources, where deployed:
RecordEntry from NablaRecord, every field.AccountCreated from NablaAccountFactoryPermanent and AccountRegistryV6, to discover accounts.Upgraded on every discovered account proxy.AuthorizationUsed and Transfer where the authorizer or sender is a grantee vault. Vaults are discovered from logs alone: the PAY_AUTHORIZED entry names the vault, and the funding Transfer in the same transaction confirms it.| Table | One row per |
|---|---|
record_entries | RecordEntry, raw |
obligation_pairs | OBLIGATION_OPENED / REPAY / OBLIGATION_CLOSED entry, grouped by obligationRef |
vault_payments | settlement: a vault's AuthorizationUsed paired with its Transfer, and the grant and envelope it drew against |
implementation_history | Upgraded log or IMPLEMENTATION_CHANGED entry, per account |
counterparties | distinct (subject, counterparty) pair, with first evidence and counts |
accounts, grants, vaults, vault_fundings | discovery and pairing state the tables above are built from |
factory_accounts | account created on the permanent factory, with the owner from the factory's own event |
external_permissions | spend permission or redeemed delegation, with its shape, label and decoded terms |
external_payments | SpendPermissionUsed, or an ERC-20 Transfer from the delegator in a redemption's transaction |
external_redemptions | RedeemedDelegation, whether or not it moved value |
credit_line_events | Borrowed / Repaid / Defaulted at a configured lender |
feedbacks | ERC-8004 NewFeedback: agentId, rater, feedback index; no value, tags or URIs |
agent_wallets | ERC-8004 MetadataSet for the agentWallet key: agentId and wallet (null when cleared) |
agent_owners | ERC-8004 identity Transfer (ERC-721): agentId and new owner |
Rows hold facts and counts. The reader states facts and passes no judgement on any subject.
In vault_payments, the party that submitted the settlement transaction (tx.from) is recorded as submitter. It is never treated as the counterparty; the counterparty is the Transfer recipient.
A settlement writes no NablaRecord entry. A payment's record is two parts, paired by the reader: the PAY_AUTHORIZED entry the account wrote when it reserved funds into the grantee vault (the reservation, in record_entries), and USDC's own AuthorizationUsed and Transfer events (the settlement, one vault_payments row). A citation of a payment cites both: the PAY_AUTHORIZED log (block, transaction hash, log index) and the USDC settlement transaction and its block.
The logs are the ground truth; this reader is a convenience over them. Every row carries the chain id, block number, transaction hash and log index of its evidence, plus a cast logs command and the equivalent raw eth_getLogs request that return that log from any RPC. A row you cannot reproduce from its command is a bug.
One field is a state read, not a log: the envelope expiry in vault_payments. It is labelled "state read — needs archive RPC". The reader calls envelopeOf(account, granteeKey, token) on the account's mandate at block N−1 and at the settlement block N, and stores both calls as cast call --block commands. If the two reads agree, the value is stored. If they differ, the envelope changed within block N, and the field is stored as "not determinable" with both reads cited. On 2026-10-23, the same historical eth_call at 50,000 blocks below head answered 6 of 10 times through https://arb1.arbitrum.io/rpc, and the other 4 returned "historical state … is not available", so a public endpoint cannot be relied on for this field. Everything else rebuilds from logs on any RPC.
GET /read/:chainId/:address returns every indexed fact about an address. No key is needed: the endpoint is a read over public logs.
{ "subject": "0x…", "chainId": 8453, "asOfBlock": "53160200",
"facts": [ { "source": "metamask:delegation_payment", "label": "(b) exact execution, once", "shape": "b", "terms": { "payer": "0x…", "payee": "0x…", "token": "0x…", "amount": "…" }, "cite": { "chainId": 8453, "block": "…", "tx": "0x…", "logIndex": 0 }, "reproduce": "cast receipt 0x… --rpc-url \"$BASE_RPC_URL\" --json | jq …" } ], "selfDealing": null, "exposure": null, "cShare": { "chainId": 8453, "asOfBlock": "53160200", "byToken": { "0x…": { "count": { "c": 0, "total": 1 }, "value": { "c": "0", "total": "…" } } } }, "notes": [ "no Agent Credit Lines lender registered on this chain", "SpendPermissionManager permissions and spends for this address: nothing indexed (blocks 53160000..53160200)" ] }
Every permission label has one of five shapes:
| Shape | Label | Where it comes from |
|---|---|---|
| (a) | allowance, per period / total / per call / per execution / streamed | Coinbase spend permissions; MetaMask amount enforcers; NablaZ CAM V4 windows ("within mandate by construction" for a canonical NablaZ account) |
| (b) | exact execution, once / N times / count unbounded | MetaMask exact-call enforcers; the count from LimitedCallsEnforcer or a single-use enforcer |
| (c) | not determinable | an enforcer in no vendor list, terms that do not decode, a non-canonical NablaZ account |
| (d) | no limit on amount or call | a delegation whose caveats only restrict the call or the redeemer |
| (e) | third-party attestation, writer named | Agent Credit Lines; record entries another writer placed; ERC-8004 feedback, the rater named |
The MetaMask enforcer table is generated from the vendor's Deployments.md at a pinned commit (scripts/gen-enforcers.ts, src/generated/enforcers.json). A test fails when the vendor's main branch lists an enforcer the table lacks.
One-liners are the ground truth. The reader is a convenience over the logs. Each reproduce field is a cast command you can run yourself with an RPC URL in $ARB_ONE_RPC_URL or $BASE_RPC_URL.
When the subject has been the agentWallet or the owner of an ERC-8004 agentId, every NewFeedback about that agentId becomes an erc8004:feedback_grounding fact (R-D2B-2). A feedback is grounded when an ERC-20 Transfer from the rater to the identity's payment address settled before it (by block, then by log index within a block), whatever the token or route (R-S191-11). The payment address is resolved at the transfer's block, never later: getAgentWallet there, else ownerOf there, and the fact says which binding applied (R-S191-16). A transfer made before the identity existed does not ground ("identity did not exist at the payment block"). The wallet at the feedback block is reported beside the grounding ("wallet at feedback: " or "wallet at feedback: cleared") and is never the test (R-S191-12).
Plain transfers are not indexed. At read time the reader calls eth_getLogs with topic0 = Transfer and topic1 = the rater, any token address, from the Identity Registry's start block (or the instance's start) to the feedback block, and states that range in the fact. Candidates are the addresses in the identity's agentWallet history (MetadataSet) and owner history (ERC-721 Transfer), each confirmed at the transfer's block. A settlement from the rater's own grantee vault is a payment from the rater (R-S191-17). Native-token transfers are not read ("native-token transfers not read", R-S191-18). A transfer that is one of the reader's payment facts keeps its permission label; any other is labelled (c) with reason "direct transfer, no permission object". The fact also says whether the rater is the subject, and whether the two share a controller when both are NablaZ accounts. It carries no value, decimals, tags or URIs, and the feedback file is not fetched ("feedbackURI not read").
test/fork/afg.fork.test.ts runs this grounding on the 816 grounded feedback entries in Agentic Finance Graph's Base fixture (CC BY 4.0, see NOTICE) and writes the comparison to docs/reader/afg-agreement-2026-10-20.csv. docs/reader/retroactive-binding-2026-10.md describes the remaining disagreements.
https://read.nablaz.io runs the reader and the MCP server below as one instance, on both home chains (chain IDs 42161 and 8453), with every source indexed from its deployment block. It is keyless and reads only. It has two doors:
GET https://read.nablaz.io/read/:chainId/:address: the JSON a local GET /read returns.POST https://read.nablaz.io/mcp: the MCP server's Streamable HTTP transport, with its one tool, read_subject. For an MCP client that takes a URL: { "type": "http", "url": "https://read.nablaz.io/mcp" }.Both doors are rate-limited per client IP; a request over the limit gets 429 with a plain-text body. Beside them, GET /live (the process is up) answers with a status code and a short text, and GET /ready (the index has caught up) answers HTTP 200 with an empty body when ready, and 503 with {"ready":false} when not; nothing else is s