Steps to request access to MCP for your application

Choose “Unsure” for anything your coding agent can send when it calls TwinEthos.

What happens next

1. We email you a link to confirm the request, valid for 24 hours.
2. If approved, you get an email with a one-time link (valid for 72 hours) that shows your API key once. The key itself is never sent by email.

When your request is approved, you get an email with a one-time link (valid for 72 hours) that shows your API key once. The key itself is never sent by email.

The key works with the hosted endpoint:

https://api.twinethos.com/mcp

The server speaks MCP over streamable HTTP. Send the key in either header:

Authorization: Bearer YOUR_API_KEY
X-API-Key: YOUR_API_KEY

Requests without a valid key get 401. Keep the key out of source control: the examples below read it from an environment variable or prompt for it. We store only a hash of each key, so we can't show it again: if it is lost or exposed, email twinethos@floatingkey.com to replace it, and the old key stops working within about a minute.

Claude Code

From your project directory:

claude mcp add --transport http twinethos https://api.twinethos.com/mcp \
  --header "Authorization: Bearer YOUR_API_KEY"

Add --scope user to use it in every project, or --scope project to write a shared .mcp.json. To share the config without the key, commit this .mcp.json and set TWINETHOS_API_KEY in each developer's environment:

.mcp.json

{
  "mcpServers": {
    "twinethos": {
      "type": "http",
      "url": "https://api.twinethos.com/mcp",
      "headers": {
        "Authorization": "Bearer ${TWINETHOS_API_KEY}"
      }
    }
  }
}

Reference: Claude Code — Connect to tools via MCP.

Cursor

Project config in .cursor/mcp.json, or global config in ~/.cursor/mcp.json:

.cursor/mcp.json

{
  "mcpServers": {
    "twinethos": {
      "url": "https://api.twinethos.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:TWINETHOS_API_KEY}"
      }
    }
  }
}

Reference: Cursor — Model Context Protocol.

VS Code with GitHub Copilot (agent mode)

Workspace config in .vscode/mcp.json. VS Code prompts for the key once and stores it securely:

.vscode/mcp.json

{
  "servers": {
    "twinethos": {
      "type": "http",
      "url": "https://api.twinethos.com/mcp",
      "headers": {
        "X-API-Key": "${input:twinethos-api-key}"
      }
    }
  },
  "inputs": [
    {
      "id": "twinethos-api-key",
      "type": "promptString",
      "description": "TwinEthos API key",
      "password": true
    }
  ]
}

References: VS Code — Add and manage MCP servers; MCP configuration reference.

Other MCP clients

Any client that supports remote (streamable HTTP) MCP servers with custom headers can connect. The usual shape is below; check your client's documentation for the exact key names.

{
  "twinethos": {
    "url": "https://api.twinethos.com/mcp",
    "headers": {
      "Authorization": "Bearer YOUR_API_KEY"
    }
  }
}

To check your key outside an editor:

curl -sS https://api.twinethos.com/mcp \
  -H "Authorization: Bearer $TWINETHOS_API_KEY" \
  -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Coding agents read a repository's instruction files. Paste this block into AGENTS.md at the repository root, so every review that touches AI code asks TwinEthos without anyone having to remember. Edit the two lines marked edit: your AI integration patterns and the markets where your users are.

AGENTS.md

## AI-law review (TwinEthos)

This repository ships AI features. When a change touches an AI integration (a model or AI SDK call, a prompt, a
tool an agent can call, model output shown to people, or an automated decision about a person), check it with the
TwinEthos MCP server before you finish the review.

- Integration patterns: chat, agentic
  <!-- edit: any of chat, rag, agentic, decision_pipeline, content_generation, classification, recommendation, embeddings -->
- Markets: EU, US-CA, US-CO
  <!-- edit: where the users are, as codes; US matches every state -->

1. Call `review_checklist` with these patterns and markets. It is paged: while the response has `next_offset`, call
   again with `offset` set to it, and stop only when `next_offset` is absent. Merge the pages, keeping one item per
   `rule_id` and `detector_id`. Inspect the files each detector names, starting with the changed files.
2. Report each item as detected, not_detected or insufficient_evidence, with file:line evidence, the rule id and the
   guard to add. Use `get_rule` for the citation and the official text.
3. Keep the five lanes apart, in this order: law in force; law not yet in force, with its date; standards; best practice; TwinEthos
   recommended guardrails, which are opinion, not law.
4. Name the date of the data (`data_as_of`) from the response in the review. End with three totals that add up to the response's
   `total`: items reviewed, items skipped because `applies_to` rules them out, and items not verifiable from code
   (`evidence_scope` organizational: list them once, never as findings).
5. State that this is informational, not legal advice. Never say that a change or a guard meets a law: a guard
   addresses items.

When planning a new AI feature rather than reviewing code, call `build_plan` (the few guards that address the most
items) and `coming_into_force` (obligations that start applying soon).

Claude Code reads CLAUDE.md and can import other files. A repository that already has the block in AGENTS.md needs one line in CLAUDE.md:

CLAUDE.md

@AGENTS.md

A repository with only a CLAUDE.md pastes the block there instead. Cursor reads AGENTS.md; older setups can put the same text in .cursor/rules/twinethos.mdc. GitHub Copilot code review reads the block from AGENTS.md and calls only MCP tools marked read-only, as every TwinEthos tool is.

All tools are read-only. Every response carries the not-legal-advice notice, the date of the data (data_as_of: name it in your review so a finding can be traced to the data behind it), and each rule's review status.

Ask your agent in plain language, naming what the app does and where its users are:

Use TwinEthos to review this repo. It is an agentic support bot with users in the EU and California.

The agent calls review_checklist with:

• patterns — the repository's AI integration patterns: chat, rag, agentic, decision_pipeline, content_generation, classification, recommendation, embeddings.
• jurisdictions — where users are, as codes such as EU, US-CA, US-CO; US matches every state.
• guardrail_classes (optional) — law_derived, agent_security, and operational_integrity are included by default; add ethical_use to opt in to the advisory ethical-use guardrails.

The checklist is paged: while a response has next_offset, the agent calls again with offset set to it, until next_offset is absent, keeping one item per rule_id and detector_id. It then inspects the files each detector names and reports each finding as detected, not_detected, or insufficient_evidence, with file and line evidence and the rule id. For any finding, get_rule returns the citation, the official URL, and the verbatim government text to check it against. The review ends with three totals that add up to the checklist's total: items reviewed, items skipped because applies_to rules them out, and items not verifiable from code.

• Binding law — in force: take these to whoever owns legal exposure first, with the cited text.
• Not yet in force: plan the fix before the applies-from date; it is not a current violation.
• Standard / soft law: a gap against the named standard or framework; matters when you claim to follow it.
• TwinEthos recommendation: our opinion of good practice, never law. Prioritize by your own risk.

Two more signals travel with each item. evidence_scope: organizational means code cannot show the duty (a document or process is the evidence). requires_human_determination means applicability depends on facts outside the repository — who you are, where your users are, what the system decides.