Connect your own MCP agent
To use your own MCP agent, choose Use your own agent in the room and create a pairing code. Choose Claude Code, Codex CLI, or another MCP client. Run the room’s command, paste the code at its private prompt, then follow the setup printed for your selected client. The room supplies a separate configuration path for every connection and purpose.
npx --yes protect-mcp@0.30.0 coordination pair
This pins the published protect-mcp 0.30.0 release. The pair command accepts --client claude-code, --client codex, or --client json. It prints registration instructions; it does not edit your client settings. Generic MCP clients receive a JSON entry to merge into their existing configuration.
The agent can inspect the shared room, submit sandbox payments, wait for decisions, and deliver a result. It cannot approve its own exceptions or accept its own work. The owner can revoke its connection from the room. A requested revision keeps prior results and completed payments in the same shared budget.
After setup, copy the room’s “begin or resume” instruction into your agent. Its first inspection verifies the signed context and acknowledges that exact digest. The room shows the last instruction check separately from current permission. Neither pairing nor a past check establishes that an agent is running now.
To return, use “Reconnect this agent” with the original private config file, reopen your agent client, and give it the resume instruction. Existing operations and proposals keep their identities. Missing files, expired or revoked access, or a changed negotiation mandate require a fresh pairing. Bounded waiting runs only while your agent session is active.
The hosted trial uses fictional USD and a sandbox ledger. Hosted jobs allow 40 model steps across all attempts; waiting uses no model calls. Your own agent’s model usage is separate. Keep pairing codes and configuration files private. ScopeBlind checks actions through this room’s payment tool; connecting it does not govern the agent’s other tools.
Bring your personal agent (Muse and others)
A personal agent such as Meta’s Muse can prepare shared work here and read what happened, without ever holding an approval. The agent prepares; each person decides on their own device; the receiver applies only the version both approved; and the record leaves with whoever wants it. Any agent that can read an MCP server address can do this, in one of two ways. Use a local profile when the agent can run a command in its own computer. Use the hosted connector when the agent’s platform can only add a remote MCP address. The tools, the limits and the human steps are the same either way.
Give the agent its ScopeBlind profile
In the agent’s own environment (for Muse, its cloud computer), create a profile once and serve it as a local MCP address. The profile is an agent identity only; it carries no authority until a person grants a scoped connection.
npx --yes protect-mcp@0.30.0 coordination agent setup \
--client json \
--profile ~/.scopeblind/agent.json \
--endpoint https://scopeblind.com/api/coordination \
--authority-key PINNED_64_HEX_AUTHORITY_KEY
npx --yes protect-mcp@0.30.0 --http --port 8811 -- \
npx --yes protect-mcp@0.30.0 coordination agent --profile ~/.scopeblind/agent.json
Then add http://127.0.0.1:8811/mcp to the agent as a custom connector or MCP server. In Muse, ask it to create a custom connector from that address; Meta does not review custom connectors, so check the authority key against a trusted source yourself. For project work the agent uses coordination.connections, which returns its public agent_key, and the same five tools every registered agent gets: coordination.inspect_workspace, coordination.prepare_repository_review, coordination.inspect_repository_review, coordination.report_repository_criteria and coordination.request_repository_changes.
Use the hosted connector
Some agent platforms cannot run a command or keep a local profile. For those, ScopeBlind hosts the connector at this address:
https://scopeblind.com/mcp
Connect in one step. If the platform supports signing in to an MCP server (OAuth), add the address and choose its connect button. The platform opens scopeblind.com in your browser. Use the browser that holds your project, the one where you created it as its organizer. The page lists the projects that browser organizes and shows the address the platform will return to. Pick the project, check the label and choose Connect. Your browser signs that approval with your own project key, and the platform then collects its token straight from ScopeBlind, so nobody copies a token. If the page opens on a device that does not hold your project, close it and connect from the device that does; there is no approval by link.
No project yet? On the same page, choose A new trial on ScopeBlind’s demo repository, then Connect and start a trial. When you ask your agent to start a trial, it gives you a link. Open it in the same browser: the link carries no secret, and no other browser can open it. There you start the trial and invite the person who reviews with you, and your agent never sees that invitation. When the trial’s project exists, the agent’s connector joins it. It can prepare and read work once you propose limits naming it and your reviewer agrees them, as for any connector. The trial is fixed: ScopeBlind’s small studio site whose contact button goes nowhere, one limited AI coding job and 24 hours. Each person can have three trials started by agents a day, and each still counts toward the two trials a day for your browser and for your network.
Or create a token by hand. In your project, open Preparation, find Hosted connector for cloud agents, give the connector a label and choose Create hosted connector. The page shows a token once. It looks like sbc_<connector id>_<secret>. Save it straight away and treat it like a password. In the agent’s platform, add the address above as an MCP connector and give it the token as its API key or bearer token.
Either way the result is the same kind of connector: it appears on the project page, where the organizer can revoke it, and a project can have up to five active connectors. Signing in uses OAuth 2.1 with PKCE, for public clients only. A platform finds it from the reply /mcp gives without a token and from /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server, and identifies itself with a client ID metadata document or by registering at /register. It may return only to an https address, its own computer’s loopback address, or an app address in reverse-domain form. The one-time code lasts five minutes and works once; presenting it again revokes the connector it created. The token does not expire and there is no refresh token, because the connector’s key is derived from its token: a new token would be a different key and would void the limits both people agreed. A platform that loses its token connects again.
The address uses the Model Context Protocol over streamable HTTP. Each request carries Authorization: Bearer followed by the token, each reply is JSON, and no session is kept between requests. It serves eight tools: coordination.connections, the same five project tools listed above, coordination.summarize_repository_review, which says who is waiting and what is left, and coordination.verify_record, which checks a record someone was sent. Neither of the last two changes anything. The hosted connector writes each tool name with an underscore in place of the dot, for example coordination_inspect_workspace, because some agent platforms refuse a dot in a tool name; it accepts either form. A connector made for a trial also has coordination.start_trial, which leaves the trial link described above, and coordination.inspect_trial_start, which says whether the person has opened it yet.
The connector’s Ed25519 signing key is derived from the token on each request and is never stored. Of the credential, ScopeBlind keeps only a SHA-256 hash of the token and the connector’s public key, so it cannot sign as the connector when the token is not presented. Beside that it keeps the connector’s label, the organizer’s public key, the times it was created, last used and revoked, the drafts and findings the connector signed, and a saved copy of the project record and limits it read. The organizer can revoke a connector on the project page at any time, and a revoked token stops working immediately; the service and its database refuse that connector’s key from then on. A project can have up to five active connectors.
A connector belongs to one project and has no authority by itself. When it is created, the page puts its public key into the preparation limits form. The organizer still proposes the limits naming that key and the reviewer still agrees the same limits, exactly as for a local profile. Once both have agreed, ask the agent to start: the hosted connector finds its project and the agreed limits by itself when it calls coordination.inspect_workspace with no arguments, so nobody pastes IDs. That call also lists every review in the project the agreed limits cover, including ones the organizer created directly, so the agent can say where any of them stands. A local profile still takes the workspace_id and mandate_id from the active permission’s instruction on the project page. Approvals, acceptance and withdrawals stay with people on their own devices.
What the agent can do, and what stays with people
- Prepare shared work. With a local profile, ask the agent to call
coordination.connections and return its public agent_key, then paste that key into Preparation in your project. With a hosted connector, the page fills the key in for you. Either way the organizer proposes the limits and the reviewer agrees the same limits. The agent then inspects the workspace and prepares a review draft: a brief, success criteria and what each relies on, and the exact source version. - Propose a revision. When feedback or a resolution names a change, the agent calls
coordination.request_repository_changes against the exact packet it read. It cannot change the agreed terms silently; a new version needs a fresh inspection and both approvals. - Read status and the next action.
coordination.inspect_repository_review returns the review’s status, its signed approvals, and the feedback and findings recorded so far, including a Resolve this choice once a person has made it. Through the hosted connector, coordination.summarize_repository_review gives the short answer instead: who is waiting on whom, what is left, how agents assessed each criterion, and the open Resolve this options with the one decision each needs. The agent can read those options; only the person an option names can choose it, on their own device. - Retrieve the result. The same read returns the recorded outcome and the evidence; either person downloads the signed evidence or the review package from the page.
- Check a record someone sent you. Through the hosted connector,
coordination.verify_record takes a ScopeBlind record exactly as it was received and uses the same parser and verifiers as Verify and also requires scopeblind.com’s own service key; on the Verify page, paste that key into the Authority key field for the same answer. It says whether the record verified and what its signed content says. A record that checks out only against a key it names itself, or that carries text outside its signatures, is never reported as verified. It needs no agreed limits and changes nothing.
Approvals, acceptance and withdrawals are signed by people on their own devices, never by the agent and never through an approval an agent’s browser clicked. The receiver holds the only credential that can change the destination. Only briefs, artifacts and disclosures enter the shared record; the agent’s private context stays with the agent.
With a local profile, the MCP address is local to the agent’s computer and ScopeBlind hosts nothing for it. The hosted connector is served by ScopeBlind, and its requests pass through ScopeBlind: the agent’s platform sends its tool calls (draft briefs, criteria, findings and requested changes) to ScopeBlind over HTTPS. For a hosted connector ScopeBlind stores the signed drafts and findings the connector authored, because they are part of the project record, together with the token hash, the public key, the label, and the times the connector was created, last used and revoked. Its request rate limits are keyed by connector. When a platform connects by signing in, ScopeBlind also keeps the connection request: the platform’s identifier, the name it gives itself, the address it returns to, the organizer’s signed approval and a hash of the one-time code, never the token. To read a platform’s client ID metadata document, ScopeBlind fetches it from the platform’s own address. Either way, draft text goes to ScopeBlind, and the agent’s model provider may see the tool records it reads. A skill that describes the local profile steps in the agent’s own terms is published at ScopeBlind/skills.