프로토타입 · 미리 보기: 공식 레지스트리의 모든 서버를 담고 있으며 30분마다 동기화해요. 리뷰와 계정 기능은 다음 단계에서 열려요.
PopNx MCPAI를 쓰는 사람을 위한 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의 세 기둥

이 세 가지는 절대 하나의 점수로 합치지 않아요. 의견, 측정, 인기는 서로 다른 것이니까요.

할 수 있는 일

이 서버는 아직 쉬운 말로 된 요약을 쓰지 못했어요. 아래는 레지스트리에서 읽어 온 사실이에요.

  • 연결 방식: 클라우드에서 실행
  • 전송 방식: Streamable HTTP
  • 카테고리: 기타

설치

쓰고 있는 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

메뉴 이름은 요금제나 시기에 따라 조금 다를 수 있어요.

선택한 앱은 이 기기의 쿠키에만 저장돼요. 계정은 필요 없어요.

이 설정은 제작자의 레지스트리 정보로 만들었어요. 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에서 이 저장소를 읽어 오지 않았어요

  • ✓ 통과

    엔드포인트 응답

    121ms 만에 응답(HTTP 200)

  • – 해당 없음

    OAuth로 로그인

    로그인 필요 없음

  • ✓ 통과

    도구 설명에 숨겨진 지시 없음

    도구 설명 1개를 읽었고, AI에게 보내는 숨겨진 지시는 없었어요

기타 카테고리의 다른 서버와 비교i

  • 이 카테고리의 다른 서버 32545개 중 0%보다 스타가 많아요
  • 이 카테고리의 다른 서버 32545개 중 99%보다 최근에 레지스트리에 공개됐어요
  • 기본 점검 결과가 이 카테고리의 다른 서버 32545개 중 100%와 같거나 더 좋아요

레지스트리에서 이 카테고리의 활성 서버 전체와 비교했어요. 스타는 게시자가 저장소를 소유한 경우에만 세요.

자주 묻는 질문

Reader, 안전한가요?

해당하는 기본 점검 3개 중 3개를 통과했어요. 코드는 읽지 않았어요. 키나 토큰을 넣기 전에 서버가 어떤 권한을 요구하는지 확인하고, 꼭 필요한 권한만 있는 키를 쓰세요.

어떤 키나 코드가 필요한가요?

레지스트리에 필수 키가 나와 있지 않아요. 다만 처음 쓸 때 로그인을 요구하는 서버도 있어요.

내 컴퓨터에서 실행되나요, 클라우드에서 실행되나요?

제작자의 클라우드에서 실행돼요. 설치 없이 인터넷으로 연결하지만, 보내는 내용은 제작자의 서버를 거쳐요.

아직 관리되고 있나요?

GitHub 저장소는 마지막으로 – 변경됐고, 최신 버전(0.1.0)은 오늘 레지스트리에 올라왔어요.

어떤 앱에서 쓸 수 있나요?

Claude Desktop, Claude Code, Cursor, VS Code처럼 MCP를 지원하는 앱에서 쓸 수 있어요. 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에게 묻기