Use it from Claude Code

Unreleased: @yea-protocol/cli isn't on npm yet, so the plugin below and npx @yea-protocol/cli fail until it's published. Until then, install from a clone: run there, install registers the clone itself (this node and cli/bin/yea.js) with each tool.

git clone https://github.com/yea-protocol/yea && cd yea
npm ci && npm run build
node cli/bin/yea.js install          # an agent key, the bridge (this clone) and agent instructions
node cli/bin/yea.js doctor           # starts what each tool would start, to check it

Add services with node cli/bin/yea.js add <url>, and run npm run build again after a git pull.

The bridge exposes YEA services as an MCP server, so every MCP client can use them now. Each capability is its own tool (calendar_reschedule, shop_order, …), plus yea_consent, yea_undo and yea_expand. Tool results are Lens.

Claude Code plugin (bundles the MCP server and a skill that teaches consent etiquette):

/plugin marketplace add yea-protocol/yea
/plugin install yea@yea

Any tool, one command. This creates an agent key and registers the bridge (plus a short agent-instructions block) with every AI tool it finds:

npx @yea-protocol/cli install                    # or --target claude-code,cursor,codex,gemini,vscode,windsurf,claude-desktop
npx @yea-protocol/cli add https://shop.example/yea   # add services; the bridge picks them up on restart
npx @yea-protocol/cli doctor                     # check keys, grants, services, registration

Tools that change things are marked destructiveHint; don't auto-approve them in your tool. The service decides what the agent's grant covers. Anything over it comes back with a consent code: you run yea approve <code> where your principal key is, which shows the exact action and needs an interactive terminal, and paste the printed consent back to the agent. Nothing the model passes to a tool approves anything, and the bridge never signs; a consent is only as safe as the place your principal key is (what an approval proves).

Keep the principal key away from the agent

Your principal key signs your policy and your approvals, so everything rests on it. yea install therefore creates only the agent's key. Create the principal on another device or OS user and send the agent a grant:

# on your phone/laptop/other user (holds the principal key)
yea init && yea grant --to <agent key> --svc shop.example --risk low --each spend=25.00USD --total spend=100.00USD --exp 30d
# on the agent's machine
yea grant-import <token>

To try things quickly on one machine, use yea install --with-principal. Be aware that an agent with shell access (Claude Code has it) could then read the key. Pair --each with --total: a per-action limit alone can be dodged by splitting a purchase, and --total bounds the sum.

On one machine, each consent code also comes with a short id: run yea approve <id> in a terminal outside the chat, and the consent is saved where the bridge reads it, so nothing goes back through the chat. That's part of the trial setup, for the same reason: an agent that runs as you could run yea approve too (what an approval proves). With the principal key on another device, as recommended, run yea approve <code> --to <agent key> there and paste the consent back.

What the model gets

One tool per capability of each service (calendar_reschedule, shop_order, …), with read-only and destructive hints, plus yea_consent, yea_undo and yea_expand. It needs no YEA documentation: in a real session (on the bridge's earlier, generic tools), Claude Sonnet 5 read Lens cold, moved a meeting within policy, stopped at a purchase over its limit, and asked the human to approve it.

Try it without running anything

The hosted demo runs the example calendar and shop for you, with a private copy per agent key. To wrap an API you already have, see Wrap any REST API.