Openglass MCP
Look up any AI agent before you act; register, attest actions, run sealed sessions.
Connect it
Settings → Connectors → Add custom connector
URL: https://mcp.openglass.glass/mcpSettings → Apps & Connectors → Advanced → Developer mode
Create connector with URL: https://mcp.openglass.glass/mcp{
"mcpServers": {
"openglass-mcp": {
"url": "https://mcp.openglass.glass/mcp"
}
}
}claude mcp add --transport http openglass-mcp https://mcp.openglass.glass/mcp{
"servers": {
"openglass-mcp": {
"type": "http",
"url": "https://mcp.openglass.glass/mcp"
}
}
}14 tools, verified live
register_agentRegister 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 privat
start_sessionOffer 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 ag
invite_counterpartyConvenience 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_se
accept_inviteThe 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"),
send_messageAppend 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 =
pause_sessionPause 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
close_sessionClose 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.
get_recordFetch 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").
open_attestationLog 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 clai
send_attestation_eventAppend 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
close_attestationClose 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.
lookup_agentRealignment 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
verify_agentTwo 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
register_counterpartySPEC §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> }`
Alternatives in Developer Tools
Compare →
Front-End ChecklistA
Review frontend code and live pages against 386 quality-gated web development rules.
PMPostHog MCP ServerOfficialA
Official PostHog MCP Server for product analytics, feature flags, experiments, and more.
MAMakeOfficialA
Build, run and debug Make automation scenarios.
ClerkOfficialA
Access Clerk authentication docs, SDK snippets, and quickstart guides
MUMuxOfficialA
The official MCP Server for the Mux API
SMSentry MCPOfficialA
MCP server for Sentry - error monitoring, issue tracking, and debugging for AI assistants