Reader
概要
作者による説明(英語の原文)
Read NablaZ's open record: agent actions under permission, cited onchain. Evidence, not a verdict.
PopNx MCPの3つの柱
この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。
- 利用者の声iレビューはまだありませんレビューは今後のステップで、アカウント機能と一緒に始まります
- 私たちの基本チェックi3項目中3項目に合格公開情報からチェック。コードはまだスキャンしていません
- 利用状況i初期★ –
できること
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
- 接続方法: クラウドで動く
- トランスポート: Streamable HTTP
- カテゴリ: 暗号資産・ブロックチェーン
インストール
使っているAIアプリを選んで、設定をコピーしてください。
インストールの前に
- 基本チェック:3項目中3項目に合格
- 作者のサーバーで動きます。あなたが頼んだ内容は、作者のサーバーを通ります。
- できること:1件(ツール) read_subject
- レジストリには、入力が必要なキーは載っていません。
必要なもの
- クラウドで動くインストール不要。インターネット経由でつながります
どのアプリを使っていますか?
上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。
ウェブ、デスクトップ、モバイルのClaudeで使えます:
- Settings → Connectors を開く
- Add custom connector を押す
- 下のアドレスを貼り付けて Add を押す
- サインインを求められたら、作者のサービスにサインインする
https://read.nablaz.io/mcpターミナルでこれを実行します
claude mcp add --transport http reader https://read.nablaz.io/mcpまたは、設定を自分でコピーする
プロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます
{
"mcpServers": {
"reader": {
"url": "https://read.nablaz.io/mcp"
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
または、設定を自分でコピーする
プロジェクトの .vscode/mcp.json に貼り付けます
{
"servers": {
"reader": {
"type": "http",
"url": "https://read.nablaz.io/mcp"
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
ChatGPTがつなげるのは、インターネット上のサーバーだけです:
- ウェブ版のChatGPTを開き → Settings → Connectors (Apps)
- Create または Add を押す(プランによっては、先に Advanced で Developer mode をオンにする必要があります)
- 下のアドレスを貼り付け、名前を付けて保存する
- サインインを求められたら、作者のサービスにサインインする
https://read.nablaz.io/mcpメニューの名前は、プランや時期によって少し違うことがあります。
選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。
この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。
できること
ツールの名前と説明は、サーバーが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
基本チェックi
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月9日にチェック
- ✓ 合格
作者とリポジトリが一致
レジストリ名はドメイン nablaz.io で確認済みです(レジストリがドメインの所有を確認しています)
- … 未チェック
今もメンテナンスされている
このリポジトリはまだGitHubから読み取っていません
- … 未チェック
ライセンスがある
このリポジトリはまだGitHubから読み取っていません
- ✓ 合格
エンドポイントが応答する
122ミリ秒で応答(HTTP 200)
- – 対象外
OAuthでサインイン
サインイン不要
- ✓ 合格
ツールの説明に隠れた指示がない
1件のツールの説明を読み、AIへの隠れた指示は見つかりませんでした
暗号資産・ブロックチェーンのほかのサーバーとの比較i
- このカテゴリのほかの1619件のうち0%よりスターが多い
- このカテゴリのほかの1619件のうち97%より最近レジストリに公開
- 基本チェックの結果が、このカテゴリのほかの1619件のうち100%と同じかそれ以上
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
よくある質問
Readerは安全ですか?
当てはまる基本チェック3項目のうち3項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
どんなキーやコードが必要ですか?
レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。
パソコンで動きますか、それともクラウドですか?
作者のクラウドで動きます。インストール不要でインターネット経由でつながりますが、送った内容は作者のサーバーを通ります。
今もメンテナンスされていますか?
GitHubリポジトリの最終更新は–、最新バージョン(0.1.0)がレジストリに届いたのは一昨日です。
どのアプリで使えますか?
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。URLでつながるので、リモートMCPサーバーに対応したアプリ(開発者モードのChatGPTなど)でも使えます。
代わりに使えるものは?
同じカテゴリには:Agentwallet, Highwire, Lucky x402
代わりの候補
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:↓ 週あたりのダウンロードi★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i
Highwire
Trade, launch and research higher.fun coins on Solana, from any AI agent. Unsigned or policy-signed.
Lucky x402
Pre-trade crypto checks for agents: token/memecoin verdict (EVM+Solana), wallet risk, CEX ops. x402.
作者のREADME
READMEを開く
作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。
nablaz-sdk
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.
What it reads
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:
- Coinbase
SpendPermissionManager:SpendPermissionApproved,SpendPermissionUsed,SpendPermissionRevoked. - MetaMask
DelegationManager(delegation framework v1.3.0):RedeemedDelegation, with every caveat decoded. For each redemption the reader reads the transaction receipt and keeps the ERC-20Transfers sent by the delegator. A redemption alone is not a payment; only such aTransferis. - Agent Credit Lines (
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. - ERC-8004:
NewFeedbackfrom 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'sMetadataSetand ERC-721Transfer. Addresses fromsrc/generated/erc8004.json(vendor commit pinned there).
NablaZ sources, where deployed:
RecordEntryfromNablaRecord, every field.AccountCreatedfromNablaAccountFactoryPermanentandAccountRegistryV6, to discover accounts.- ERC-1967
Upgradedon every discovered account proxy. - USDC
AuthorizationUsedandTransferwhere the authorizer or sender is a grantee vault. Vaults are discovered from logs alone: thePAY_AUTHORIZEDentry names the vault, and the fundingTransferin the same transaction confirms it.
What it writes
| 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.
Citation rule
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.
Read
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)" ] }
- facts: one per record entry, vault payment, spend permission, delegation, payment, redemption and credit-line event. Each names its source and carries a permission label, the block, transaction and log index, and the one-line command that returns the same log from any RPC.
- selfDealing (NablaZ accounts only): distinct counterparties paid, share of value paid to accounts under the same controller, share paid to counterparties with no record, and the sentence "A payee controlled by the same person under another key cannot be detected from chain data."
- exposure (NablaZ accounts only): per grant and token, the least remaining allowance across windows plus the vault balance, with the limit that outstanding authorizations are not observable onchain.
- cShare: per token, the count and value of this read's payment facts labelled (c), over all of them; never summed across tokens.
- notes: every source that returned nothing ("nothing indexed (blocks X..Y)", or "indexed up to X; source starts at Y" while the indexer is below the source's start), and every fact that is not determinable, stated as text.
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.
Feedback grounding
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.
Hosted read
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 localGET /readreturns.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
冒頭だけを表示しています。続きはリポジトリで読めます