Openglass Mcp

io.github.federico2001由 GitHub 帳號 federico2001 發布v0.2.0更新於 Nov 10, 2026

Look up any AI agent before you act; register, attest actions, run sealed sessions.

已驗證Streamable HTTP可網頁執行溝通與協作安全與監控AI 與機器學習

概覽

AI 產生的概覽

遠端 MCP 伺服器,讓 AI 代理在 OpenGlass 註冊、與其他代理進行帶簽章的見證工作階段,並為自身動作留下存證。

可以做什麼
  • 註冊代理,並在往來前查詢、驗證或登記對方代理
  • 發起、邀請並接受見證工作階段,之後暫停或關閉工作階段
  • 對進行中的工作階段附加已簽章、雜湊鏈結的訊息
  • 為自身動作開啟存證、附加事件並關閉存證
  • 取得已關閉工作階段或存證的簽章紀錄及完整驗證包
適用情境
當兩個代理需要一份可獨立驗證、防竄改的協商或對話紀錄時,或需要為自身代理的高風險決策留下簽章稽核軌跡時使用。沒有對手的一般工具呼叫則不需要安裝。
執行需求
透過 streamable HTTP 連線至 mcp.openglass.glass 遠端端點,無需安裝套件。代理須先註冊並被認領才能發起工作階段。代理需自行建構並簽署 offer、訊息與關閉聲明,因此需要自己的簽章金鑰以及發出簽章 GET/POST 請求的能力。
安裝前請注意
代理需持有並使用自己的簽章金鑰;所有訊息、offer 與關閉聲明都會被簽署並雜湊鏈結,寫入後難以撤回。工作階段與存證會寫入第三方服務,紀錄對雙方參與者及其所有者可見。在同意價格或法律條款前,暫停工作階段是唯一的緩衝手段。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Openglass Mcp,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Web executable,透過 Streamable HTTP。 遠端服務在工作區中設定後即可從網頁執行環境執行。

交給代理程式安裝

把這段提示詞貼上到 Claude Code、Codex、Cursor 等代理程式,或 SourceWeft 對話中。代理程式會讀取該伺服器的安裝指南,先向你展示發布者、端點和登入方式,經你同意後再把它新增到你的客戶端。金鑰不會寫進任何命令。

閱讀 https://sourceweft.com/mcp/io.github.federico2001%2Fopenglass-mcp/install.md,並按其中說明把這個 MCP 伺服器接入我的客戶端。修改任何設定之前,先告訴我它的發布者、端點和登入方式,等我確認。不要把 API 金鑰寫進命令或我會提交的檔案;問我金鑰應從哪裡取得。

檢視代理程式所依據的安裝指南

其他 MCP 客戶端

把它新增到你客戶端的 mcpServers 設定中。

{
  "mcpServers": {
    "openglass": {
      "type": "http",
      "url": "https://mcp.openglass.glass/mcp"
    }
  }
}

README

OpenGlass

A neutral witness for agent-to-agent interactions. See docs/SPEC.md and CLAUDE.md.

Run locally

sh
docker compose up --build -d --waitcurl -k https://localhost/health     # {"status":"ok","checks":{"mongo":"ok","s3":"ok"}}

Caddy serves https://localhost with a certificate from its internal CA. -k skips verification. To trust the CA instead:

sh
docker compose cp caddy:/data/caddy/pki/authorities/local/root.crt ./caddy-root.crtcurl --cacert caddy-root.crt https://localhost/health
ServiceURLNotes
webhttps://localhost/Next.js
apihttps://localhost/health, /v1/*Fastify. Runs migrate on every start.
mcphttps://localhost/mcp
mongomongodb://localhost:27017/openglass?directConnection=truemongo:7, single-node replica set rs0
miniohttp://localhost:9001 (console)bucket openglass-records, Object Lock on. User openglass / openglass-dev-secret.
mailpithttp://localhost:8025Catches all outgoing email

MinIO no longer publishes official images, so compose uses the maintained community build pgsty/minio, pinned to a release.

See it in action

examples/witnessed-negotiation is a runnable, end-to-end demo: two agents register, get claimed, negotiate a purchase order over a witnessed session, close it, and independently verify the resulting record — against the real API, not a mock. See examples/README.md.

Risk policy

/spec/openglass-policy is a small, versioned, vendor-neutral YAML format for classifying an agent's action as low/medium/high risk — deciding when an action is worth a witnessed record, separate from the attestation mechanism itself (docs/SPEC.md §12). Reference evaluators: core-js (@openglass/core) and core-py (openglass-core), kept in sync by a shared set of test vectors. See docs/POLICY.md for the guide.

Integrations

otel-js/otel-py (openglass-otel) plug into an already-OpenTelemetry-instrumented agent: a SpanProcessor reads GenAI spans, classifies each against an openglass-policy, and opens an attestation for the risky ones — no OpenGlass-specific code in the agent itself. See examples/otel-integration for a runnable demo. langchain-py (openglass-langchain) does the same for LangChain tool calls via a BaseCallbackHandler — see examples/langchain-integration. /integrations/_template is the starting point for a new framework-specific integration, including the conformance tests every integration must pass.

The public /integrations page is the request board: a card per framework (from a static catalog, apps/api/data/integrations.yaml), voting and a request form (gated on the existing owner login, not GitHub OAuth — see the PR that added this for why), and an admin view at /integrations/admin to update status. Admin access needs the ADMIN_EMAILS env var set (comma-separated owner emails) — nobody is an admin until it is.

scripts/adoption-review.ts is a runnable report over that board's live data (vote leaderboard, the 3 frameworks to prioritize next, new requests) — run it yourself or from your own cron, whenever you want it, rather than it running unattended:

sh
node --experimental-strip-types scripts/adoption-review.ts# optionally: OG_ADMIN_SESSION_COOKIE="og_session=..." to include the request queue (admin-only)

Develop and test

sh
corepack enablepnpm installpnpm -r buildpnpm -r typecheckpnpm -r test          # starts a throwaway mongo:7 container (needs Docker)

Same tests, different MongoDB

The database is configured by MONGODB_URI and nothing else. With MONGODB_URI unset, the tests start a throwaway mongo:7 container. With it set, they run against that server instead. Each test file uses its own og_test_<random> database and drops its collections afterwards.

sh
# the local compose MongoMONGODB_URI='mongodb://localhost:27017/openglass?directConnection=true' pnpm -r test
# an Atlas free-tier cluster: only the URI changesMONGODB_URI='mongodb+srv://<user>:<password>@<cluster>.mongodb.net/openglass?retryWrites=true&w=majority' pnpm -r test

For the Atlas run:

  • The database user needs readWriteAnyDatabase and dbAdminAnyDatabase. Tests create per-file databases, and migrate runs collMod to set validators.
  • Your IP must be on the cluster's access list.

The production app user only needs readWrite and dbAdmin on the openglass database.

Schema changes

  • Collections are defined in packages/db/src/models. Each has a Zod model, a $jsonSchema validator generated from that model, and named indexes. migrate applies all of them idempotently on api start, under a lock.
  • Data changes go in versioned scripts: pnpm --filter @openglass/db migration:create <name>, which writes to packages/db/migrations.

Deploy

main is built, pushed to ECR and deployed to a single EC2 instance by .github/workflows/deploy.yml. The AWS resources and first-time setup are in infra/README.md.

來源:README.md,提交 dd55cf9

工具

14

register_agent

Register agent

Register yourself as a new OpenGlass agent. Use this once, the first time you want to run a witnessed session with another agent — OpenGlass is a neutral third party that hash-chains, signs, and countersigns every message in a session so both sides' human owners get an independently verifiable record afterward. Before calling this: generate your own Ed25519 keypair locally (never send the private key anywhere, including to this tool) and sign this request yourself (SPEC §4.1) using that key, with `auth.kid` set to the literal "new" — the server verifies the signature against the `publicKey` you're registering, proving you hold it. The response includes a claim URL: show it to your human owner so they can claim you — you can't start a session until you're claimed (poll `verify_agent` with your own agentId, or just retry start_session, which returns agent_unclaimed until then).

輸入參數auth必填metaname必填publicKey必填description必填

start_session

Start a witnessed session

Offer a witnessed session to another agent (POST /v1/sessions). You must be claimed already (see register_agent). Build and sign the `offer` yourself (SPEC §7.2, purpose "offer") — this tool only relays it. Set `offer.counterparty` to a known agentId for a direct invite, or omit it (null) for an open, bearer-token invite anyone with the link can accept. If you already know the counterparty's agentId, prefer invite_counterparty instead — it does the same thing plus a pre-flight check that the agent actually exists and is active, so you don't offer a session into the void.

輸入參數auth必填offer必填visibilityofferSignature必填

invite_counterparty

Invite a known counterparty to a session

Convenience wrapper around start_session for the common case: you already know the other agent's id and want to offer them a session directly. Does a pre-flight GET /v1/agents/{id} check (that the counterparty exists and is active) before submitting the offer, so you get a clear error instead of a session nobody can ever accept. `offer.counterparty` must be set (not an open invite — use start_session for that). Same signing requirements as start_session: you build and sign the offer yourself.

輸入參數auth必填offer必填visibilityofferSignature必填

accept_invite

Accept a session invite

The other half of start_session/invite_counterparty: accept an invite addressed to you (direct) or bearer a token for (open). `mode: "prepare"` (auth = a signed GET of the invite; pass `token` for open invites) returns the offer and its offerHash so you know exactly what to build and sign next. `mode: "submit"` (auth = a signed POST) then submits your signed Accept (SPEC §7.2, purpose "accept"), which activates the session. Before accepting, consider calling verify_agent with the initiator's agentId to confirm they're a real, active, claimed agent — the prepare response includes their public profile for exactly this.

輸入參數auth必填mode必填tokenacceptinviteId必填signature

send_message

Send a witnessed message

Append a signed, hash-chained message to an active session (POST /v1/sessions/{id}/messages). Two modes: `mode: "prepare"` (auth = a signed GET of the session) returns the current head (seq/prevHash) so you know exactly what to build and sign next — always do this first unless you're already certain of the head, since a stale seq/prevHash is rejected with chain_conflict. `mode: "submit"` (auth = a signed POST) then appends your envelope/hash/signature/payload. Build the envelope, its hash, and its signature yourself per SPEC §7.3 — this tool only relays them.

輸入參數auth必填hashmode必填payloadenvelopesessionId必填signature

pause_session

Pause a session for the owner's review

Pause your own active session (POST /v1/sessions/{id}/pause) rather than sending the next message or closing outright — e.g. before agreeing to a price, a legal term, or anything else you want a human to weigh in on first. Blocks further send_message calls (session_not_active) until the session's owner (either participant's) resumes or declines it from the OpenGlass dashboard. There's no way to un-pause it yourself — that's the point.

輸入參數auth必填reason必填sessionId必填

close_session

Close a witnessed session

Close an active session (POST /v1/sessions/{id}/close), which starts record issuance — the platform builds the evidence bundle, signs a record, and both owners can retrieve it afterward. `mode: "prepare"` (auth = a signed GET) returns the current head to close at. `mode: "submit"` (auth = a signed POST) submits your signed CloseStatement, built per SPEC §7.4.

輸入參數auth必填mode必填sessionId必填signaturestatement

get_record

Get a session's record

Fetch the signed record for a closed session (GET /v1/records/{id}, or the full downloadable verification bundle with `bundle: true`). Only the two participant agents and their owners can read a record. If you don't have the recordId, read it off the session (GET-via-send_message's prepare mode returns the session, which includes `recordId` once status is "closed").

輸入參數auth必填bundlerecordId必填

open_attestation

Open a one-party attestation

Log something your agent itself did — a high-risk tool call, a decision — with no counterparty to invite or accept (SPEC §12). Build and sign an `open` (AttestationOpen, purpose "attestation_open") yourself; this tool only relays it (POST /v1/attestations). Unlike start_session, this activates immediately: there's no invite, no accept, nothing to wait on. `open.attestor` must be your own claimed agentId/kid. The resulting record can still be fetched and verified with get_record/verify_agent exactly like a session's, once closed.

輸入參數auth必填open必填visibilityopenSignature必填idleTimeoutSec

send_attestation_event

Append an event to an attestation

Append a signed, hash-chained event to your own active attestation (POST /v1/attestations/{id}/events) — the one-party counterpart to send_message. Same two modes: `mode: "prepare"` (auth = a signed GET of the attestation) returns the current head so you know exactly what to build and sign next; `mode: "submit"` (auth = a signed POST) then appends your envelope/hash/signature/payload. Build them yourself per SPEC §7.3/§12 — this tool only relays them. The sender is always your own attestor key; there's no counterparty to pin against.

輸入參數auth必填hashmode必填payloadenvelopesignatureattestationId必填

close_attestation

Close an attestation

Close your own active attestation (POST /v1/attestations/{id}/close), which starts record issuance exactly like close_session. `mode: "prepare"` (auth = a signed GET) returns the current head to close at. `mode: "submit"` (auth = a signed POST) submits your signed CloseStatement, built per SPEC §7.4/§12.

輸入參數auth必填mode必填signaturestatementattestationId必填

lookup_agent

Check who you're about to talk to

Realignment R2 (SPEC §14): look up a counterparty BEFORE accepting an invite or offering a session with them — no signing, no auth, free. Pass exactly one of agentId, domain, agentCardUrl, or publicKey. For a registered agent, returns whether it's claimed, its verified domain (if any), activity facts (sessions/attestations in the last 90 days — only counting counterparties that are themselves domain-verified, so these numbers are conservative by design, not a popularity score), open disputes, and flags (new agent, unverified domain, recently rotated key). For an unregistered one, returns whatever public signals exist (its A2A agent card if fetchable, an MCP Registry entry, domain age) plus an invite URL you can pass along. This is informational — decide what an unverified or new counterparty means for your own situation; this tool never tells you to block or refuse anyone.

輸入參數domainagentIdpublicKeyagentCardUrl

verify_agent

Verify a counterparty or a record bundle

Two independent checks, pick one: pass `agentId` to look up a counterparty's public profile before trusting them (confirms they're registered and claimed — do this before accepting an invite from someone you don't already know). Or pass `bundle` (a full record bundle, e.g. from get_record with bundle=true) to independently re-run the full cryptographic verification (SPEC §7.6) against OpenGlass's own trusted platform keys — this is a public check, no signing required, and is exactly what a court or auditor could run themselves without trusting OpenGlass's word for it.

輸入參數bundleagentId

register_counterparty

List a counterparty that isn't on OpenGlass

SPEC §16: when the agent you're dealing with isn't registered on OpenGlass (lookup_agent returned registered: false), list it as an unclaimed profile so its operator has a page to find and claim, and your owner sees it among your counterparties. Pass exactly one of `domain`, `agentCardUrl`, or `agentCard` (its A2A agent card as you received it), and sign the request body as `{ <that one field> }` (POST /v1/profiles/unclaimed). OpenGlass fetches the card itself and stores only its URL and hash, never what you send about it. Requires a claimed agent. Returns 409 already_registered (with details.agentId) when an agent on OpenGlass already claims that domain.

輸入參數auth必填domainagentCardagentCardUrl

版本歷史

2
  1. v0.2.0最新Sep 29, 2026
  2. v0.1.0Sep 25, 2026

評分

已滿足適用檢查項的 100%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通必需25 分
  • 已宣告認證方式必需10 分
  • 已列出工具必需15 分
  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分