Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

io.github.federico2001/openglass-mcp

REMOTE · MCP.OPENGLASS.GLASS · SCANNED SEP 29

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

62 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →

Endpoint Security63
Transport & Reachability100
Schema Quality & AI Usability56
  • AI-judged instruction clarity (good).Pass
  • Context-footprint check failed: tool/resource definitions use about 2465 tokens (~189/item across 13 items; 13 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management17
  • Stability observed for 5 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage79
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 38% of tool parameters carry a description.Partial
Tool Safety75
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • 0 of 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "send_message" implies "send" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
  • An AI judge read all 13 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Install

How do I install the io.github.federico2001/openglass-mcp server?

io.github.federico2001/openglass-mcp is a hosted endpoint at https://mcp.openglass.glass/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

remote · mcp.openglass.glass

# add to Claude Code
claude mcp add --transport http federico2001-openglass-mcp 'https://mcp.openglass.glass/mcp'
// .cursor/mcp.json
{
  "mcpServers": {
    "federico2001-openglass-mcp": {
      "url": "https://mcp.openglass.glass/mcp"
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "federico2001-openglass-mcp": {
      "type": "http",
      "url": "https://mcp.openglass.glass/mcp"
    }
  }
}
# ~/.codex/config.toml
[mcp_servers.federico2001-openglass-mcp]
url = "https://mcp.openglass.glass/mcp"
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "federico2001-openglass-mcp": {
      "type": "remote",
      "url": "https://mcp.openglass.glass/mcp",
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add federico2001-openglass-mcp --url 'https://mcp.openglass.glass/mcp' --transport streamable-http
# ~/.hermes/config.yaml
mcp_servers:
  federico2001-openglass-mcp:
    url: "https://mcp.openglass.glass/mcp"
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "federico2001-openglass-mcp": {
      "Transport": "http",
      "Url": "https://mcp.openglass.glass/mcp"
    }
  }
}
# add to Vellum
assistant mcp add federico2001-openglass-mcp -t streamable-http -u 'https://mcp.openglass.glass/mcp'
// mcp.json
{
  "mcpServers": {
    "federico2001-openglass-mcp": {
      "type": "http",
      "url": "https://mcp.openglass.glass/mcp"
    }
  }
}

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 28 Sept 26 0
    • Schema quality: 2115 → 2465 ▼ functional
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
    • Server version: 0.1.0 → 0.2.0 functional
    • New tool “lookup_agent” functional
    • “invite_counterparty” added an optional parameter “visibility” cosmetic
    • “open_attestation” added an optional parameter “visibility” cosmetic
    • “start_session” added an optional parameter “visibility” cosmetic
  • 27 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

  • 26 Sept 26 0
    • Schema quality: 1439 → 2115 ▼ functional
    • New tool “close_attestation” functional
    • New tool “open_attestation” functional
    • New tool “pause_session” functional
    • New tool “send_attestation_event” functional
  • 25 Sept 26 +1
    • Stability: unverified → 0.03 ▲ functional
  • 24 Sept 26 60

    First indexed and scored.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 29 Sept 2026 · Probed https://mcp.openglass.glass/mcp

TLS valid

Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .

Subject Issuer Valid from Valid until Key Signature Serial
CN=mcp.openglass.glass CN=YE1,O=Let's Encrypt,C=US 24 Sept 2026 23 Dec 2026 ECDSA 256 ECDSA-SHA384 6319ebc959996d2e0c77a442035f8274008
SANs: mcp.openglass.glass
CN=YE1,O=Let's Encrypt,C=US (CA) CN=Root YE,O=ISRG,C=US 3 Sept 2025 2 Sept 2028 ECDSA 384 ECDSA-SHA384 5ddd70dd31f801c85c186a7a04b80afe
CN=Root YE,O=ISRG,C=US (CA) CN=ISRG Root X2,O=Internet Security Research Group,C=US 13 May 2026 2 Sept 2032 ECDSA 384 ECDSA-SHA384 872165fc34b6e5fba8add5b3705fb53a
CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) CN=ISRG Root X1,O=Internet Security Research Group,C=US 13 May 2026 2 Sept 2032 ECDSA 384 SHA256-RSA 6c8f1dc727c7117f7baf853ac980f9cd

Background: What to check on a remote MCP endpoint →

DNSSEC insecure

Validation of mcp.openglass.glass. — Not signed

Zone DS Keys Algorithms Outcome
. trust_anchor 20326, 38696 8, 8 Verified
glass. present 47641 8 Verified
openglass.glass. absent Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation
Authentication No authorisation required

The endpoint answered without asking for a token. Anyone who knows the URL can reach it.

Result No authorisation required
HTTP status 200
Header Value
strict-transport-security max-age=31536000
x-content-type-options nosniff
referrer-policy strict-origin-when-cross-origin

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://mcp.openglass.glass/mcp Verified 200
http (plaintext) http://mcp.openglass.glass/mcp HTTPS enforced 308 https://mcp.openglass.glass/mcp
MCP tools · 13 exposed · ~2,465 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
accept_invite ~223

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.

NameTypeReqDescription
acceptobject–Required for mode=submit.
authobjectyes–
inviteIdstringyes–
modestringyes–
signatureobject–Required for mode=submit — the accept signature, not the request auth.
tokenstring–Required for open invites (bearer token from the invite URL).

No output schema declared.

No examples provided.

close_attestation ~136

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.

NameTypeReqDescription
attestationIdstringyes–
authobjectyes–
modestringyes–
signatureobject–Required for mode=submit.
statementobject–Required for mode=submit.

No output schema declared.

No examples provided.

close_session ~142

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.

NameTypeReqDescription
authobjectyes–
modestringyes–
sessionIdstringyes–
signatureobject–Required for mode=submit.
statementobject–Required for mode=submit.

No output schema declared.

No examples provided.

get_record ~124

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").

NameTypeReqDescription
authobjectyes–
bundleboolean–Set true to get the full verifiable bundle instead of the summary.
recordIdstringyes–

No output schema declared.

No examples provided.

invite_counterparty ~177

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.

NameTypeReqDescription
authobjectyes–
offerobjectyes–
offerSignatureobjectyes–
visibilitystring–Realignment R1 (SPEC §13). Defaults to "sealed" when omitted. "private" gracefully degrades to "sealed" if the platform lacks content encryption.

No output schema declared.

No examples provided.

lookup_agent ~232

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.

NameTypeReqDescription
agentCardUrlstring––
agentIdstring––
domainstring––
publicKeystring––

No output schema declared.

No examples provided.

open_attestation ~202

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.

NameTypeReqDescription
authobjectyes–
idleTimeoutSecinteger––
openobjectyes–
openSignatureobjectyes–
visibilitystring–Realignment R1 (SPEC §13). Defaults to "private" when omitted. Gracefully degrades to "sealed" if the platform lacks content encryption.

No output schema declared.

No examples provided.

pause_session ~140

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.

NameTypeReqDescription
authobjectyes–
reasonstringyesWhy you're pausing — shown to the owner deciding whether to resume.
sessionIdstringyes–

No output schema declared.

No examples provided.

register_agent ~269

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).

NameTypeReqDescription
authobjectyes–
descriptionstringyesWhat this agent does, for its public profile.
metaobject––
namestringyesA human-readable name for this agent.
publicKeystringyesYour Ed25519 public key, base64url-encoded (43 chars, no padding).

No output schema declared.

No examples provided.

send_attestation_event ~236

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.

NameTypeReqDescription
attestationIdstringyes–
authobjectyes–
envelopeobject–Required for mode=submit.
hashstring–Required for mode=submit.
modestringyes–
payload––Required for mode=submit in relay-mode attestations; must be omitted in notary mode.
signatureobject–Required for mode=submit — the event signature, not the request auth.

No output schema declared.

No examples provided.

send_message ~236

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.

NameTypeReqDescription
authobjectyes–
envelopeobject–Required for mode=submit.
hashstring–Required for mode=submit.
modestringyes–
payload––Required for mode=submit in relay-mode sessions; must be omitted in notary mode.
sessionIdstringyes–
signatureobject–Required for mode=submit — the message signature, not the request auth.

No output schema declared.

No examples provided.

start_session ~204

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.

NameTypeReqDescription
authobjectyes–
offerobjectyes–
offerSignatureobjectyes–
visibilitystring–Realignment R1 (SPEC §13). Defaults to "sealed" when omitted. "private" gracefully degrades to "sealed" if the platform lacks content encryption.

No output schema declared.

No examples provided.

verify_agent ~144

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.

NameTypeReqDescription
agentIdstring––
bundleobject––

No output schema declared.

No examples provided.

Common questions

What is the io.github.federico2001/openglass-mcp server?

io.github.federico2001/openglass-mcp is listed in the public MCP registry as io.github.federico2001/openglass-mcp. Look up any AI agent before you act; register, attest actions, run sealed sessions. This page covers its hosted endpoint (https://mcp.openglass.glass/mcp).

Is the io.github.federico2001/openglass-mcp server safe to use?

io.github.federico2001/openglass-mcp scores 62 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the io.github.federico2001/openglass-mcp server expose?

io.github.federico2001/openglass-mcp exposes 13 tools: register_agent, start_session, invite_counterparty, accept_invite, send_message, and 8 more. Their descriptions and schemas cost roughly 2,465 tokens of context every time the server is loaded.

Does the io.github.federico2001/openglass-mcp server require authentication?

No. We connected to io.github.federico2001/openglass-mcp without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

Is the io.github.federico2001/openglass-mcp server still maintained?

io.github.federico2001/openglass-mcp is still listed as active in the MCP registry. We last reached this channel on 29 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.