RightClick X

Your AI should adapt to software. Not the other way around.

One MCP connection. Thirteen tools. A living map of what your environment can do.

Discover capabilities. Connect APIs that have never met. Turn working workflows into reusable APIs. Keep them working when compatible upstream interfaces change.

Get started · Watch an integration heal · See the evidence · Understand the architecture

Your agent can use tools. But every unfamiliar API, application, protocol, or machine is another integration someone has to build and maintain.

RightClick X turns supported software contracts into capabilities on demand. Give it an OpenAPI spec, GraphQL endpoint, MCP server, web form, peer runtime, or supported platform binding. It reflects the available operations into a semantically typed graph. Your agent keeps using the same 13 context_* MCP tools even as that graph grows, changes, and disappears.

Then comes the interesting part: the runtime can compose operations across providers, execute them, check results, save successful goals as new endpoints, and re-plan when a previously working contract changes. No GitHub-specific or Wikipedia-specific adapter needs to be written for the examples below.

Not an integration marketplace. An integration runtime. It discovers what your environment actually exposes, under the access you already have.

The demo: an API breaks. The capability doesn't.

Two different AI agents. One saved capability. A protocol-breaking change in between.

  CLAUDE CODE · fresh session
  "Build a sourced destination brief for Portugal. Save what works."
       │
       ├─ Countries API (GraphQL) → capital
       ├─ Wikipedia (REST)       → current article extract
       ├─ Formatter              → sourced Markdown
       └─ Separate auditor       → checks the answer against the sources
       │
       └─ ✓ verified → published as goal:destination-brief

             ┌──────────────────────────────────┐
             │  The owned formatter API breaks  │
             │  REST v1 → MCP                   │
             │  Operation and inputs renamed    │
             │  RightClick X process restarted  │
             └──────────────────────────────────┘

  CODEX · new session, no Claude conversation
  "Create the destination brief for Iceland."
       │
       └─ discovers goal:destination-brief
            └─ old route fails → contract re-learned → workflow re-planned
                 └─ auditor checks the NEW answer
                      └─ ✓ verified Iceland brief

  1 saved-goal invocation · 1.67 s recovery · 0 integration-code changes

This ran on 16 October 2026 using real Countries and Wikipedia data, an owned Cloudflare formatter deliberately changed from REST to MCP, a separate read-only auditor, and fresh Claude Code and Codex sessions. The public APIs were not the ones changed. The second agent needed three MCP calls total (find, inspect, invoke); the repair happened inside that one invocation.

Read the actual Iceland brief · Inspect the full trace · Inspect the separate evidence audit

That is the product we're building: capabilities that survive beyond the agent that discovered them.

Related MCP server: MCPBridge

Get started

Requires Node.js 22.18+. No API key is needed for the local demo.

git clone https://github.com/rossbuckley1990-hash/rightclick-x.git
cd rightclick-x
npm install
npm run demo

The seven-act local demo starts services speaking different protocols, discovers their capabilities, builds a multi-provider workflow, saves it, and demonstrates recovery when a provider goes away. It uses controlled fixtures; it does not call a live weather service.

Want to see the capability graph grow in a browser?

npm run serve
# Open http://127.0.0.1:8787

Want to reproduce the complete, checked lifecycle instead?

npm run proof       # isolated local services, outcome witness, drift, restart, receipts
npm test            # regression tests
npm run typecheck   # TypeScript check

Connect your AI

RightClick X is an MCP server over stdio and Streamable HTTP. It works with any client that supports the corresponding transport.

Claude Code, from the cloned repository:

claude mcp add rightclick-x --scope user -- node "$PWD/bin/rcx.ts" mcp

Codex, Cursor, Claude Desktop, VS Code, Windsurf, or another MCP client:

node bin/rcx.ts connect        # prints supported client configurations
node bin/rcx.ts connect codex  # example: copy-ready Codex TOML

For an HTTP MCP client, run node bin/rcx.ts serve locally and connect to http://127.0.0.1:8787/mcp. Non-loopback deployments require authentication; see Security and trust.

Give your agent a task, not a list of preinstalled integrations:

Use RightClick X to discover a public API for Canadian holidays. Find the next holiday in Ontario, show the source, and explain which capability you used. Don't invent an answer if a source is unavailable.

Public-directory discovery requires internet access, and third-party API availability can vary. Start with npm run demo for a deterministic local experience.

Run from the terminal

Use rcx explain <capability-id> to see a discovered operation's inputs and restrictions. Simple k=v inputs stay strings. For arrays, objects, booleans or numbers, pass one JSON object:

node bin/rcx.ts run builtin:list.first-url --args '{"urls":["https://example.com/a","https://example.com/b"]}'
node bin/rcx.ts run <capability-id> --args-file inputs.json
cat inputs.json | node bin/rcx.ts run <capability-id> --args-file -
node bin/rcx.ts compose --args '{"text":"hello"}' --want hash --run

Choose either k=v, --args or --args-file; mixed inputs are rejected. Files and stdin use UTF-8, up to 16 MiB. Duplicate keys and numbers that cannot survive JSON conversion are refused; keep exact numeric identifiers or raw documents as strings. Operator permissions still apply. Failed runs, refuted checks and unsuccessful executed compositions return a nonzero exit status with their JSON result. Once installed, use rcx in place of node bin/rcx.ts.

Why this is different

Most agent integrations expose a fixed list of tools somebody already wrote. RightClick X exposes a fixed way to discover and use capabilities — while the capabilities themselves change with the environment.

    Claude  ·  Codex  ·  Cursor  ·  any MCP-compatible AI
                            │
                      ONE MCP CONNECTION
                            │
                     13 context_* tools
                            │
                      RIGHTCLICK X
                            │
            discover  →  type  →  plan  →  execute
                 ↑                       │
                 └──── re-plan ← check ←─┘
                            │
                  persist / publish goals
                            │
      ┌──────────────┬──────────────┬──────────────┐
      │              │              │              │
   OpenAPI         GraphQL         MCP           Peers
   / Swagger       endpoints       servers       / runtime
      │              │              │              │
      └─────── web forms · supported platforms ──────┘

The graph contains operations and their input/output semantic types — for example, a place, geo.lat, id.release, or account, not merely a string. A planner searches for useful routes between what you have and what you need. It can learn missing public sources, execute a compatible route, and retain a successful workflow as another capability.

A published goal is available through MCP, REST (/x/... and /openapi.json), and GraphQL (/graphql). Other RightClick X instances can discover that new API in turn. This does not mean arbitrary protocols or business semantics can be translated losslessly.

Things we've actually run

These are recorded experiments, not illustrations of features we intend to build someday.

One more: RightClick X used GitHub operations learned from GitHub's own spec to create its own repository and upload its source. The remote Git tree hash matched the local checkout. See E8.

What about scale?

On one Apple Silicon laptop, synthetic stress tests recorded 20,014 capabilities, 156.7 million typed links, and 197 ms planning on the generated graph. Another controlled test completed 1,500/1,500 calls while 50 simulated providers produced 373 breaking releases. A 1,000-call concurrency test had zero errors. These are local/synthetic workload measurements, not production uptime or a guarantee of useful routes. Methods and limitations.

The thirteen tools

The agent's interface does not grow when the environment does.

One powerful pattern is context_compose with publish: "<name>": an outcome becomes goal:<slug>, exposed through MCP and as a generated HTTP API. Saved goals can be found and used by another agent after restart; they retain their declared checks and re-plan when compatible implementations change.

For bounded recovery of flat compositions, start the host with RCX_WORKFLOW_RECOVERY=1 (SDK: workflowRecovery: true plus a Store). Pending results expose a resume:<run-id> selector for the same chosen execution. Use it with context_run, without replacement inputs or checks; current authority still applies. This opt-in stores bounded business inputs/outputs locally. See the recovery evidence and limits, including process-kill tests, unsupported shapes and same-revision scope.

Persisted state now uses a versioned envelope. The file store reads known legacy snapshots and upgrades them on save, after keeping the original bytes as a backup beside the state file; incompatible or unreadable state stops startup without a reset. Workers KV state is read-only: KV cannot give one writer to a Worker's many isolates, so persistent state on Cloudflare goes through the Durable Object entry (src/entry/durable.ts). The tested older readers refuse the new encoding. Custom state adapters and raw-file consumers should use the exported encodeState / decodeState helpers. See compatibility results and scope.

Show me the evidence

Don't take a demo transcript on faith. The repository keeps scripts, manifests, source snapshots, independent truth checks, and failures next to the results.

For the full cross-vendor reproduction you need authenticated Claude/Codex CLIs and an authenticated Cloudflare account; see the proof instructions.

Security and trust

Discovering an operation does not grant permission to use it. RightClick X operates with the credentials and capabilities made available to its runtime; it does not bypass an application's authentication or operating-system controls.

• Execution risk: read, write, external, and destructive labels can constrain planning. By default a destructive operation needs an operator approval set in configuration (RCX_APPROVE) as well as the caller's confirm: true; an agent cannot approve its own call (RCX_DESTRUCTIVE=agent-confirm restores confirm-only). MCP tools without annotations are treated as destructive, following the MCP specification's defaults. Published goals that can write answer only POST. Repair never re-sends a state-changing call that may have taken effect unless the operator declares it side-effect-free (RCX_RETRY). Ordinary writes can execute when invoked. See the security record.

• Credentials: origin-pinned headers are not reflected into the graph or forwarded to a different origin on redirects. Cloud peers can keep their credentials local.

• Network boundaries: exposed servers block private, loopback, link-local, and cloud-metadata targets, including checks around DNS and redirects; intentional local deployments can use explicitly configured exceptions.

• Verification: user-defined predicates and optional separate read-only witnesses can reject incorrect results. A receipt proves what was executed and checked — not that every unverified result is true.

• Saved goals: their risk constraints and required checks are retained during replanning; changed or missing outcome-checker contracts fail closed in the recorded workflow.

This is v0.1.0, experimental infrastructure, not a transactional write-recovery engine or a comprehensive enterprise policy system. See current limits.

• Contracts are required. Discovery uses exposed descriptions, public registries, known URLs, gateway catalogs, and supported platform bindings. It does not magically understand arbitrary software or scan private networks.

• Semantic compatibility is hard. Two operations can share types and names but have different meanings. Contract matching and checks reduce risk; they do not establish arbitrary business equivalence. Treat high-impact changes as needing independent verification.

• Large results and identifier schemes can require additional tooling or more precise semantics. An exploratory life-science exercise exposed both limitations.

• A recovered response is not automatically a correct business outcome. Use independent checks, especially for payments, data writes, and decisions with real-world consequences.

• Destructive confirmation is not human identity verification. Deploy your own authorisation and approval boundary around sensitive uses.

• Transactions, rollback of external writes, and exactly-once execution are not established by the current read-workflow proofs.

• Not yet verified in the recorded README baseline: Deno Deploy, YAML-only OpenAPI descriptions, OAuth-protected remote MCP servers, and npm publishing.

Run it your way

Reproduce the cross-agent proof

This creates two disposable owned Cloudflare Workers, uses authenticated AI CLI sessions (consuming model quota), and deletes the test Workers afterwards. No credentials belong in the repository.

node proof/real-environment.ts --deploy --manifest .rcx-deploy/real-current.json
node proof/real-environment.ts --preflight --manifest .rcx-deploy/real-current.json
npm run proof:real -- --deployment .rcx-deploy/real-current.json --clients claude,codex
node proof/real-environment.ts --cleanup --manifest .rcx-deploy/real-current.json

Build with us

We're exploring a simple question with big consequences:

What if every AI agent could discover the capabilities available in its environment — and pass on working, checked capabilities to the next agent — without everyone maintaining a separate integration for every system?

Try the demo. Run a proof. Break something we thought worked and open an issue with a reproducible case. Failures that teach the runtime to generalise are as valuable as new features.

If this is the layer you want AI agents to have, star the repository and help test it against software we've never seen.

Apache-2.0 · Source · Experiments · Issues

Saved goals and storage consistency

Saved-goal execution requires an authoritative lease that covers the complete invocation and coordinates all publishers and revocations. A generic Store that only implements load and save can retain state, but cannot authorize a saved goal: execution refuses with a freshness error. The host implementing a custom lease is responsible for enforcing the contract across every writer.

For Node applications, ProcessMemoryStore is available from rightclick-x/node. Sharing one instance across runtimes provides independent per-runtime compare-and-swap views and a shared execution lease, within that single process and backend object only. It is volatile and cannot coordinate other processes or survive restarts. FileStore in the same entry coordinates cooperating local processes through its file lock; its trusted-directory and cooperating-writer limitations still apply.

Workers KV remains a read-only state source, but its eventual consistency means saved goals loaded from it cannot be executed under this contract. Remote and read-only stores without an authoritative lease also refuse; read-only alone is not evidence of immutability. Legacy saved goals without an immutable revision must be explicitly republished before execution; loading them does not silently mint an identity.