原型 · 预览版:收录官方注册中心里的全部服务器,每 30 分钟同步一次。评价和账户功能将在后续阶段推出。
PopNx MCP为使用 AI 的人准备的 MCP 服务器 · 用大白话讲清楚

Reader

作者:cyninzf版本 0.1.0i★ –i在云端运行
注册名称io.nablaz/reader

安装

概览

作者提供的说明(英文原文)

Read NablaZ's open record: agent actions under permission, cited onchain. Evidence, not a verdict.

PopNx MCP 的三大支柱

这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。

它能帮你做什么

我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。

安装

选择你使用的 AI 应用,然后复制设置。

安装之前

你需要

你用的是哪个应用?

在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。

适用于网页版、桌面版和手机版 Claude:

  1. 打开 Settings → Connectors
  2. 点击 Add custom connector
  3. 粘贴下面的地址,然后点击 Add
  4. 如果要求登录,请登录作者的服务
SettingsConnectors1+ Add2https://…3
https://read.nablaz.io/mcp

在终端中运行这条命令

claude mcp add --transport http reader https://read.nablaz.io/mcp

在 Cursor 中打开

或者自己复制设置

粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json

{
  "mcpServers": {
    "reader": {
      "url": "https://read.nablaz.io/mcp"
    }
  }
}

浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。

在 VS Code 中打开

或者自己复制设置

粘贴到项目中的 .vscode/mcp.json

{
  "servers": {
    "reader": {
      "type": "http",
      "url": "https://read.nablaz.io/mcp"
    }
  }
}

浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。

ChatGPT 只能连接互联网上的服务器:

  1. 打开网页版 ChatGPT → Settings → Connectors (Apps)
  2. 点击 Create 或 Add(部分套餐需要先在 Advanced 中开启 Developer mode)
  3. 粘贴下面的地址,起个名字,然后保存
  4. 如果要求登录,请登录作者的服务
SettingsConnectors1+ Create2https://…3
https://read.nablaz.io/mcp

菜单名称可能因套餐和版本不同而略有差异。

你的选择通过 Cookie 保存在这台设备上,无需账户。

这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。

它能做什么

工具名称和描述与服务器在 2026年11月6日 报告的完全一致。这些内容由作者撰写,不是我们写的;我们以纯文本形式显示。

  • read_subject

    Returns 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月7日

  • ✓ 通过

    作者与仓库一致

    注册名称已通过域名 nablaz.io 验证(注册中心会核实域名所有权)

  • … 尚未检查

    仍在维护

    我们还没有从 GitHub 读取这个仓库

  • … 尚未检查

    有许可证

    我们还没有从 GitHub 读取这个仓库

  • ✓ 通过

    端点有响应

    在 121 毫秒内响应(HTTP 200)

  • – 不适用

    使用 OAuth 登录

    无需登录

  • ✓ 通过

    工具描述中没有隐藏指令

    已读取 1 个工具描述,未发现针对 AI 的隐藏指令

与“其他”中的其他服务器比较i

  • 星标数多于此分类中其他 32545 个服务器的 0%
  • 发布到注册中心的时间比此分类中其他 32545 个服务器的 99% 更新
  • 基础检查结果等于或优于此分类中其他 32545 个服务器的 100%

与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。

常见问题

Reader 安全吗?

它在 3 项适用的基础检查中通过了 3 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。

它需要哪些密钥或代码?

注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。

它在我的电脑上运行还是在云端?

它在作者的云端运行。通过互联网连接,无需安装,但你发送的内容会经过作者的服务器。

它还在维护吗?

GitHub 仓库最后更新于–,最新版本(0.1.0)于今天进入注册中心。

哪些应用可以使用它?

支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。它通过 URL 连接,所以接受远程 MCP 服务器的应用也可以使用,例如开启开发者模式的 ChatGPT。

有什么可以替代它?

同一分类中有:Spec Driven Development, Remote Desktop Commander, Python MCP

替代选择

同一分类中其他作者的服务器,按星标数排序。

如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i

Spec Driven Development

作者:formulahendry

MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.

在你的电脑上运行★ 440MIT14个月前更新
安装

Remote Desktop Commander

作者:desktop-commander

Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.

在云端运行★ 211昨天更新
安装

Python MCP

作者:Files-com

Local-only Python MCP server for the Files.com API.

在你的电脑上运行今天更新
安装

作者的 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-20 Transfers sent by the delegator. A redemption alone is not a payment; only such a Transfer is.
  • 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: 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.
  • ERC-1967 Upgraded on every discovered account proxy.
  • USDC 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.

What it writes

TableOne row per
record_entriesRecordEntry, raw
obligation_pairsOBLIGATION_OPENED / REPAY / OBLIGATION_CLOSED entry, grouped by obligationRef
vault_paymentssettlement: a vault's AuthorizationUsed paired with its Transfer, and the grant and envelope it drew against
implementation_historyUpgraded log or IMPLEMENTATION_CHANGED entry, per account
counterpartiesdistinct (subject, counterparty) pair, with first evidence and counts
accounts, grants, vaults, vault_fundingsdiscovery and pairing state the tables above are built from
factory_accountsaccount created on the permanent factory, with the owner from the factory's own event
external_permissionsspend permission or redeemed delegation, with its shape, label and decoded terms
external_paymentsSpendPermissionUsed, or an ERC-20 Transfer from the delegator in a redemption's transaction
external_redemptionsRedeemedDelegation, whether or not it moved value
credit_line_eventsBorrowed / Repaid / Defaulted at a configured lender
feedbacksERC-8004 NewFeedback: agentId, rater, feedback index; no value, tags or URIs
agent_walletsERC-8004 MetadataSet for the agentWallet key: agentId and wallet (null when cleared)
agent_ownersERC-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:

ShapeLabelWhere it comes from
(a)allowance, per period / total / per call / per execution / streamedCoinbase 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 unboundedMetaMask exact-call enforcers; the count from LimitedCallsEnforcer or a single-use enforcer
(c)not determinablean enforcer in no vendor list, terms that do not decode, a non-canonical NablaZ account
(d)no limit on amount or calla delegation whose caveats only restrict the call or the redeemer
(e)third-party attestation, writer namedAgent 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 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

只显示了开头部分;其余内容请在仓库中阅读

问 PopNx