X-EGO
REMOTE · MCP.X-EGO.COM · SCANNED OCT 6
Human approval for irreversible AI agent actions, bound to the exact tool call by a passkey tap
Available components
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 Security66
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one. See how to fix → View diagnostics → Partial
- HTTPS check failed: the endpoint is reachable over plaintext HTTP. See how to fix → View diagnostics → Fail
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC is configured correctly; the domain's records validate against the full chain to the root. View diagnostics → Pass
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability74
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 5401 tokens (~1350/item across 4 items; 4 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 Management73
- Stability observed for 22 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 4 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 5 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
How do I install the X-EGO MCP server?
X-EGO is a hosted endpoint at https://mcp.x-ego.com/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.x-ego.com
claude mcp add --transport http com-x-ego-x-ego 'https://mcp.x-ego.com/mcp'
{
"mcpServers": {
"com-x-ego-x-ego": {
"url": "https://mcp.x-ego.com/mcp"
}
}
} {
"servers": {
"com-x-ego-x-ego": {
"type": "http",
"url": "https://mcp.x-ego.com/mcp"
}
}
} [mcp_servers.com-x-ego-x-ego] url = "https://mcp.x-ego.com/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"com-x-ego-x-ego": {
"type": "remote",
"url": "https://mcp.x-ego.com/mcp",
"enabled": true
}
}
} openclaw mcp add com-x-ego-x-ego --url 'https://mcp.x-ego.com/mcp' --transport streamable-http
mcp_servers:
com-x-ego-x-ego:
url: "https://mcp.x-ego.com/mcp" {
"McpServers": {
"com-x-ego-x-ego": {
"Transport": "http",
"Url": "https://mcp.x-ego.com/mcp"
}
}
} assistant mcp add com-x-ego-x-ego -t streamable-http -u 'https://mcp.x-ego.com/mcp'
{
"mcpServers": {
"com-x-ego-x-ego": {
"type": "http",
"url": "https://mcp.x-ego.com/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
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.
- 6 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 67 to 73. That category is still filling its 30-day observation window: 20 days of observed history at the previous scan, 22 at this one. The score rises as the window fills, whether or not the server changes.
- 3 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.
- 1 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.
- 29 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes.
- 28 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 27 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 40 to 43. That category is still filling its 30-day observation window: 12 days of observed history at the previous scan, 13 at this one. The score rises as the window fills, whether or not the server changes.
- 25 Sept 26 +1
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 22 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.
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 6 Oct 2026 · Probed https://mcp.x-ego.com/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=x-ego.com | CN=WE1,O=Google Trust Services,C=US | 17 Aug 2026 | 15 Nov 2026 | ECDSA 256 | ECDSA-SHA256 | 1d7592495a9961310e1901e6e0850b60 |
| SANs: x-ego.com, mcp.x-ego.com, *.mcp.x-ego.com | ||||||
| CN=WE1,O=Google Trust Services,C=US (CA) | CN=GTS Root R4,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | ECDSA 256 | ECDSA-SHA384 | 7ff31977972c224a76155d13b6d685e3 |
| CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 15 Nov 2023 | 28 Jan 2028 | ECDSA 384 | SHA256-RSA | 7fe530bf331343bedd821610493d8a1b |
Background: What to check on a remote MCP endpoint →
DNSSEC secure
Validation of mcp.x-ego.com. — Secure
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| x-ego.com. | present | 2371 | 13 | Verified |
| mcp.x-ego.com. | Verified address RRset verified with the apex keys |
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 |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.x-ego.com/mcp | Verified | 200 | |
| http (plaintext) | http://mcp.x-ego.com/mcp | Served over HTTP | 200 |
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 →
xego_check_pairwise_seen_before Check whether this user was seen before ~539
Checks whether a given pairwise ID has already been seen within this audience. It protects against one person acting as several different users (multiple accounts, repeat voting, and similar). WHEN TO USE: returning-user checks and one-human-one-vote. Requires a pairwise_id previously obtained from a verify call for YOUR audience. Only the pair (audience, pairwise_id) and the time of first occurrence are recorded. No personal data. The ledger is PERMANENT and shared across every instance and session of the server (Postgres) — it survives restarts and new MCP sessions. record_if_new=true writes atomically (no window for a concurrent write). Args: - audience (string): the service domain or URL. Normalized to a bare lowercase hostname — the same key the proof was issued under, so a domain and its URL form are the same audience. - pairwise_id (string): the identifier from xego_verify_proof. - record_if_new (boolean): record the user if they are new. Returns (JSON): { "seen_before": boolean, // true = already on record "first_seen": number|null, // Unix time of first occurrence "recorded_now": boolean // true = recorded just now } Errors (free, no sybil check performed): invalid_audience (the audience cannot be normalized to a domain), dedup_store_unavailable (temporary — retry). Neither ever means 'not seen before'. PAID TOOL (x402): this call costs $0.01 USD in USDC per execution, unless you send a valid X-EGO pilot operator key as an 'Authorization: Bearer <key>' HTTP header (operator calls are free). Calling without payment returns an x402 error whose _meta["x402/error"] contains payment requirements (accepts) and step-by-step instructions how to pay and retry. Invalid input is rejected for free before any payment is taken.
| Name | Type | Req | Description |
|---|---|---|---|
| audience | string | yes | The service being asked about. Domain (forum.example.com) or full URL (https://forum.example.com/...) — both are normalized to a bare lowercase hostname, exactly like the token's aud. |
| pairwise_id | string | yes | The user's pairwise identifier (from the xego_verify_proof result). |
| record_if_new | boolean | – | If true and the user has not been seen yet, they are recorded immediately — an atomic 'is new? then mark' in one call. |
No output schema declared.
No examples provided.
xego_request_proof_url Get an X-EGO verification link ~1,842
REQUIRES a one-time EUR 3 Planetary ID held by YOUR END USER - without it every call returns valid:false. Tell the human this BEFORE sending them to the link: if they do not have one yet, the verification page sells it in the same flow — it is not a separate signup. Returns the URL the agent sends a human user to, so they can prove they are human. On that page the user verifies with a passkey (fingerprint / Face ID) and receives a short-lived signed token (JWT). The agent then verifies it with `xego_verify_proof` (no action) or `xego_verify_action` (with action). ASK FIRST what is being approved, then bind it. Two ways, and the choice matters more than anything else on this tool: - `call` — USE THIS WHENEVER A TOOL WILL RUN. Pass the exact call { v:1, tool, target, args, policy? } you are about to execute. The human approves the call itself, field by field. - `action` — a sentence, for approvals where nothing executes (a consent, a statement). It seals what the human READ, and a well-written sentence can hide what actually happens. Both may be passed together: the sentence is what the human reads, the call is what gets compared. Either one means the token MUST be verified with xego_verify_action; with neither, use xego_verify_proof. The returned `binding` field says which. For emails: recipient and content; compose the final wording and get the user's OK before calling. This tool performs NO verification itself — it only prepares the link. No personal data is transferred. THE USER DOES NOT HAVE TO COPY THE TOKEN. Pass redirect_uri (or return_origin) and the page delivers the token to you after the passkey tap — the human part (fingerprint / Face ID) is unchanged. redirect_uri is the recommended channel: it is the only one that survives a user who is still buying a Planetary ID in the same pass. The returned token_delivery field tells you what to expect. With neither parameter the current behaviour stays: the token is shown on the page an…
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | – | FALLBACK binding, for approvals where nothing is executed (a statement, a consent, a message being sent). A human-readable description of what the user is approving (e.g. 'Transfer EUR 500 to account… |
| audience | string | yes | The domain of the service requesting verification (e.g. 'forum.example.com'). A URL is accepted too ('https://forum.example.com/path') — it is always normalized to a bare lowercase hostname (max 253… |
| call | object | – | RECOMMENDED whenever a tool will actually run. The exact call the human is approving: { v: 1, tool, target, args, policy? }. The verification page renders it field by field, the human taps the passke… |
| redirect_uri | string | – | OPTIONAL automatic token hand-off. An absolute URL the verification page navigates to on success, with the token in the URL FRAGMENT (#token=...). The user copies nothing. Only https on x-ego.com/*.x… |
| return_origin | string | – | OPTIONAL automatic token hand-off into the window that opened the verification page: postMessage({type:'xego_token', token, audience, pairwise_id, state}) at the EXACT origin (never '*'). Same allowl… |
| state | string | – | OPTIONAL. An opaque correlation value that lets you recognize your own request; it is echoed back verbatim (as a state field in postMessage, as &state= in the redirect fragment). Character set [A-Za-… |
No output schema declared.
No examples provided.
xego_verify_action Verify an X-EGO proof bound to an action ~1,223
REQUIRES a one-time EUR 3 Planetary ID held by YOUR END USER - without it every call returns valid:false. Tell the human this BEFORE sending them to the link: if they do not have one yet, the verification page sells it in the same flow — it is not a separate signup. Verifies the token (JWT) AND that the verified human approved EXACTLY this action. On top of the Ed25519 signature, the expiry and the audience, it matches the token's act claim against the hash of expected_action. WHEN TO USE: proving a human approved one specific action. Use the exact same action text that was shown to the human. On success, the response includes a ready-made footer — insert it verbatim into the message being sent. Use it when an agent's action must be covered by human consent — a money transfer, an account deletion, an order confirmation. The human sees the action text on the verification page and approves exactly that with their passkey; the token is then valid ONLY for this action. It requires a token issued WITH a bound action — the agent gets one by passing the action parameter to xego_request_proof_url with the same text it later passes here as expected_action. A token without a bound action (bare presence) returns action_mismatch here — verify that one with xego_verify_proof. Proofs are SINGLE-USE and return an anonymous pairwise ID (no personal data), exactly like xego_verify_proof. On success the response already carries receipt_url (https://x-ego.com/receipt?r=<jti> — a public receipt anyone can open with no tools) and READY-MADE footers: footer_en (plain text) and footer_html_en (a visual badge for HTML mail; no images, no tracking). Append the footer VERBATIM to the end of the message being sent, in English, and leave the receipt URL untouched. Args: - token (string): the JWT from the user (issued with a bound action). - expected_audience (string, REQUIRED): pins the audience. - expected_action (string, REQUIRED): the exact approved action string (bit…
| Name | Type | Req | Description |
|---|---|---|---|
| expected_action | string | – | REQUIRED. The exact action string the user approved — the same one passed to xego_request_proof_url as action, bit for bit (leading and trailing whitespace aside). The token must have been issued wit… |
| expected_audience | string | yes | REQUIRED. Your own service's domain the token must have been issued for. Normalized to a bare lowercase hostname exactly like in xego_verify_proof. |
| expected_call | object | – | The call you are ABOUT TO EXECUTE, built from YOUR OWN parsed parameters — never from what another party claims the call is. If the token is call-bound, this is REQUIRED and must match exactly; tool,… |
| mark_as_seen | boolean | – | If true and the token is valid, the pairwise ID is PERMANENTLY recorded as seen for that audience (see xego_verify_proof). |
| token | string | yes | The JWT the user obtained after X-EGO verification with a bound action. Three dot-separated parts. |
No output schema declared.
No examples provided.
xego_verify_proof Verify an X-EGO proof (JWT) — human presence ~955
REQUIRES a one-time EUR 3 Planetary ID held by YOUR END USER - without it every call returns valid:false. Tell the human this BEFORE sending them to the link: if they do not have one yet, the verification page sells it in the same flow — it is not a separate signup. Verifies the token (JWT) the user brought back after X-EGO verification. Cryptographically checks the Ed25519 signature against the X-EGO public keys, the expiry and the audience. WHEN TO USE: bare presence only. If the token carries an action (act claim), this tool refuses with action_binding_required — use xego_verify_action instead. This verifies ONLY bare human presence. If you need proof that the human approved a SPECIFIC action, use xego_verify_action. A token issued with a bound action (via xego_request_proof_url with the action parameter) fails here with action_binding_required — the binding cannot be confirmed by this cheaper tool. A valid result means: there is a verified human on the other end who holds the passkey. The token is short-lived — once it expires the user must verify again. Proofs are SINGLE-USE: each token verifies exactly once. A second attempt on the same token returns token_replayed. Returns an anonymous 'pairwise' identifier — different for every audience. It carries no name and no personal data. Args: - token (string): the JWT from the user. - expected_audience (string, REQUIRED): pins the audience (domain or URL — normalized to a bare hostname). - mark_as_seen (boolean): record the pairwise ID as seen. Returns (JSON) — on success: { "valid": true, "pairwise_id": string, // anonymous ID, stable per (user, audience) "audience": string, "expires_at": number, // Unix time the token expires "human_verified": true, "xego_verified": true, // always true — uncovered tokens never reach here "rarity": string | null, // rarity of the backing ID (low entropy) "marked_seen": boolean, // only with mark_as_seen=true: whether…
| Name | Type | Req | Description |
|---|---|---|---|
| expected_audience | string | yes | REQUIRED. Your own service's domain the token must have been issued for. Domain or URL — normalized to a bare lowercase hostname exactly like audience in xego_request_proof_url. A token issued for a… |
| mark_as_seen | boolean | – | If true and the token is valid, the pairwise ID is PERMANENTLY recorded as seen for that audience (Postgres ledger — survives restarts and new sessions). Useful when you want to guard against repeat… |
| token | string | yes | The JWT the user obtained after X-EGO verification. Three dot-separated parts. |
No output schema declared.
No examples provided.
What is the X-EGO MCP server?
X-EGO is an MCP server listed in the public MCP registry as com.x-ego/x-ego. Human approval for irreversible AI agent actions, bound to the exact tool call by a passkey tap. This page covers its hosted endpoint (https://mcp.x-ego.com/mcp).
Is the X-EGO MCP server safe to use?
X-EGO scores 78 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 X-EGO MCP server expose?
X-EGO exposes 4 tools: xego_request_proof_url, xego_verify_proof, xego_verify_action, xego_check_pairwise_seen_before. Their descriptions and schemas cost roughly 4,559 tokens of context every time the server is loaded.
Does the X-EGO MCP server require authentication?
No. We connected to X-EGO without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the X-EGO MCP server still maintained?
X-EGO is still listed as active in the MCP registry. We last reached this channel on 6 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.