Get started with Peers

Peers matches the people in your space and auto-delivers introductions to your best matches, you're always in control. Pick how you drive it, talk to it through your AI assistant, or call the REST API. Most people connect through Claude and never touch the API.

Overview

A space is any group you want to make introductions within, an event, a community, a cohort, a network. People join and share what they need and offer. Peers looks for complementarity, scores candidate pairs, and auto-introduces your best matches directly: you're always in control (switch to approve-first or opt out anytime).

Connect, two ways

Both paths reach the same Peers. Start with your assistant; drop to the API only if you're building something custom.

The flow

However you connect, the lifecycle of a space is the same:

Try it free in 3 calls

You do not need a plan, real members, or real email addresses to see what Peers would do. Ask your assistant for these three, in order:

Calling a tool: payload and response

Normally your assistant does this for you. If you are driving MCP directly, every call is JSON-RPC over POST /mcp with your API key in the Authorization header. Tool arguments are the parameters listed for each tool below.

# Request
POST /mcp
Authorization: Bearer mm_sk_...
Accept: application/json, text/event-stream

{
  "jsonrpc": "2.0", "id": 1, "method": "tools/call",
  "params": {
    "name": "dry_run_matching",
    "arguments": { "slug": "founders-2026", "refresh": true }
  }
}

Every tool replies in the same envelope: a content array whose first entry is text. Most tools return prose written for an assistant to relay. A few return JSON inside that text so it can be reasoned over rather than read aloud, and dry_run_matching is one of them.

# Response envelope (all tools)
{
  "jsonrpc": "2.0", "id": 1,
  "result": { "content": [ { "type": "text", "text": "..." } ] }
}

# The text of a finished dry_run_matching, parsed
{
  "status": "ready",
  "policyVersion": 3,
  "counts": { "candidates": 45, "judged": 12, "accepted": 3, "rejected": 9 },
  "accepted": [
    { "a": "Rhiannon Beck", "b": "Noor Haddad", "score": 0.88,
      "aGains": "...", "bGains": "...", "nextStep": "...", "risk": "low" }
  ],
  "declined": [
    { "a": "Noor Haddad", "b": "Gustav Lindqvist", "why": "not_useful",
      "explanation": "Judge found no useful exchange: a judge/policy decision", "note": "..." }
  ],
  "changedSinceLastRun": { "added": [], "removed": [], "policyChanged": true }
}

A first call returns {"status":"started"} instead: matching is asynchronous, so wait ten to thirty seconds and call again to read the finished report. Other statuses you may get back are rate_limited, in_flight, and a plan or member-floor refusal, each with a message explaining what to do about it. Two declined categories are not policy rejections and say so in their explanation: lost_to_cap (approved, but over the space's pace) and not_judged (outranked by stronger candidates).

Mutating tools are marked Mut. Read-only API keys are rejected on those. Errors come back as a JSON-RPC error with a message written to be shown to the user.

Organizer tools

For the person who runs the space. MUT marks a tool that changes data (blocked for read-only access).

Question-generation cost: if you do not provide questions, Peers generates them once when the space is created. Owner-authored questions skip that call and stay unchanged when goals change. Switching back to generated questions requires an explicit regenerateIntakeQuestions: true, which queues one generation call.

Participant tools

For everyone in a space: including the organizer, who is also a participant. A member never needs the website: their assistant can join, build a profile, browse the room, ask for an introduction and accept one, entirely through these tools.

REST API, authentication

Every request carries an API key in the Authorization header. Create one by requesting a one-time code by email, then exchanging it. Read-only keys are rejected on any write (non-GET) request. Paths are versioned under /v1.

# 1. Request a one-time code
POST /v1/keys/request
{ "email": "you@example.com" }

# 2. Exchange the emailed code for a key
POST /v1/keys/exchange
{ "email": "you@example.com", "code": "1234", "name": "my-app" }
→ { "apiKey": "mm_sk_…", "keyPrefix": "mm_sk_…", "permissionLevel": "read_write" }

# 3. Use it on every request
Authorization: Bearer mm_sk_…

Spaces

matchPolicy accepts objective, mustHave[], prefer[], avoid[], and organizerReview[]. Matching configuration is private to the organizer.

Chat & profile

Import

Import a CSV directly, or presign an S3 upload for larger files.

Introductions

Consent and feedback are token-authenticated links delivered by email: no API key needed. They render a confirmation page and are idempotent.

Keys & sign-in