XO Protocol

Dating intelligence API — identity verification, compatibility scoring, reputation, and social signals via XO Protocol. The social passport for AI agents.

Security Scan

The skill appears to implement the stated dating-intelligence API, but the packaged metadata and runtime instructions are inconsistent about required secrets and install steps — verify source and secrets handling before installing.

Purpose & Capability

Files (SDK, examples, OpenAPI) match the described purpose (identity verification, reputation, compatibility). Requiring an API key and a user JWT (XO_API_KEY, XO_ACCESS_TOKEN) is coherent for this API. However, the registry metadata claims no required environment variables while the SKILL.md and mcp-server example explicitly require XO_API_KEY and XO_ACCESS_TOKEN — an inconsistency that should be resolved before trusting the package.

Instruction Scope

SKILL.md instructs running an MCP server and adding a local entry to an AI client's config (~/.claude/mcp_servers.json) with environment variables. Those instructions are within scope for exposing an API to agents, but they explicitly require placing secrets (API key/JWT) into the agent configuration which gives the local MCP process access to those tokens. The instructions do not ask to read unrelated system files or exfiltrate data, but granting the MCP server these tokens effectively gives any agent-bound tooling that can call the server access to the user's API/JWT — exercise caution.

Install Mechanism

There is no automated install spec in the registry (instruction-only install). The SKILL.md suggests git-clone of a GitHub repo and using npm to install a known SDK; the code shipped with the skill mirrors a normal open-source SDK + examples. No downloads from obscure hosts or obfuscated installers were found in the provided materials.

Credentials

The skill requires an XO API key and a user access token (JWT) to function — appropriate for the described API — but the registry metadata lists no required environment variables. This mismatch reduces transparency. Additionally the examples show using client_secret and exchanging codes; those secrets are normal for OAuth confidential clients but increase risk if placed in agent config files. Confirm minimal scopes and rotation policies before providing tokens.

Persistence & Privilege

The skill does not request 'always: true' and uses an MCP server pattern (local process invoked by the AI client). That is expected for MCP-based tools. However, running the MCP server with XO_API_KEY and XO_ACCESS_TOKEN stored in the AI client's config means the skill will have persistent access to those credentials while running — verify you are comfortable storing and exposing those tokens to your AI client and any skills the client may invoke.

What to consider before installing

This package generally looks like what it claims (an SDK + MCP server for a dating-trust API), but there are important mismatches and operational risks to consider: - Metadata mismatch: the skill registry lists no required environment variables, yet the SKILL.md and the MCP server require XO_API_KEY and XO_ACCESS_TOKEN. Treat that as a transparency red flag and ask the publisher to correct the manifest. - Secrets exposure: the recommended integration stores XO_API_KEY and XO_ACCESS_TOKEN in your AI client's MCP config (~/.claude/mcp_servers.json). That file grants the local MCP process (and therefore any agent tooling that talks to it) access to your keys. Only use tokens with the minimal scopes needed, rotate them regularly, and consider running the MCP server in an isolated account or environment. - Source verification: SKILL.md and README point to a GitHub repository and xoxo.space domains, but the skill source in the registry is 'unknown'. Before installing or adding the MCP server, verify the upstream GitHub repo, check commit history and releases, and confirm the domain(s) (protocol.xoxo.space, xoxo.space) are legitimate and match the organization you expect. - Client secrets: examples show using client_secret for confidential OAuth flows. Never embed long-lived client secrets or private keys in public repos or in shared config files. Use PKCE for public clients where possible. If you cannot verify the package source and the domain ownership, or you are uncomfortable storing tokens in your AI client's config, do not install/run this MCP server. If you proceed, limit token scopes, run in an isolated environment, and audit network connections and logs.

The dating trust layer for AI agents. Verify identity, find compatible connections, check reputation, browse profiles and newsfeeds — all through a privacy-first API.

What You Can Do

Tool	What It Does
verify_identity	Check if someone is a verified real person (SBT, trust score)
search_connections	Find compatible people with AI-scored matching
get_reputation	Get reputation tier (novice → S) and score
get_social_signals	Get conversation quality score
get_profile	See a user's shared interests and preferences
get_newsfeed	Browse a connection's public posts

Setup

1. Get an API key at xoxo.space/protocol
2. Install the MCP server:

git clone https://github.com/xo-protocol/xo-protocol.git
cd xo-protocol/examples
npm install @modelcontextprotocol/sdk

3. Add to your AI client config:

Claude Desktop (~/.claude/mcp_servers.json):

{
  "xo-protocol": {
    "command": "node",
    "args": ["/path/to/xo-protocol/examples/mcp-server.js"],
    "env": {
      "XO_API_KEY": "your-api-key",
      "XO_ACCESS_TOKEN": "your-jwt-token"
    }
  }
}

Example Workflows

"Am I verified?"

Call verify_identity → returns trust score, SBT status, and attestations.

"Find me someone compatible"

1. Call search_connections with optional limit
2. Get back compatibility scores + tmp_ids
3. Use tmp_id to call get_profile, get_reputation, or get_newsfeed for more detail

"What's this person like?"

1. Call get_profile with a tmp_id → interests, topics, preferences
2. Call get_newsfeed with the same tmp_id → their public posts
3. Summarize shared interests and conversation starters

"Is this person trustworthy?"

1. Call get_reputation → tier and score
2. Call get_social_signals → engagement quality and confidence
3. Flag if low engagement + high confidence (potential red flag)

Privacy Rules

• All data requires the user's explicit OAuth authorization
• No real names, photos, or location in any response
• User IDs are ephemeral (24h expiry) — no long-term tracking
• Each tool only accesses the scopes the user approved

Links

• API Docs
• OpenAPI Spec
• SDK