Conexi

Conexi is a connection layer between AI agents and the tools they reach through the Model Context Protocol (MCP). It does not train or host an agent. It gives you one place to describe which tool servers an agent may use, which of their tools each agent may call, which calls must wait for a person, and what actually happened.

Today the whole hub runs in your browser at /app and stores its state in this browser only. The one part that lives on Robinhood Chain is ConexiPolicyRegistry, a small contract where you can publish fingerprints of a setup so that others can check it later.

Quickstart

1. Open the hub. Three connectors are there already: the built-in demo tools, web fetch and a filesystem template.
2. Set the filesystem folder to one you are happy to share, add any other template you need, then copy or download the client config file into your MCP client.
3. Open Permissions. The example policy has a research agent and an ops agent. Change their allow, deny and approval rules, then save.
4. Open the routing playground, pick an agent and send a request such as “What's the latest block?” or “Add a note: hello”. Watch what the router decides.
5. Approve or reject the waiting call in Approvals, then read the whole story in Activity.
6. Optional: connect a wallet on Robinhood Chain and publish the fingerprints of your manifest and policy.

Connector Hub

A connector is one tool server your MCP client starts locally (stdio) or reaches over the network (Streamable HTTP). The catalogue holds generic templates; each one knows the command or URL shape, the fields it needs and the tools such a server usually exposes, already sorted by access level.

• Filesystem (stdio): Read and write files inside the folders you list, nowhere else. Source: npm @modelcontextprotocol/server-filesystem (reference server)
• Web fetch (stdio): Fetch a URL and hand the page back as text the model can read. Source: PyPI mcp-server-fetch (reference server)
• Git repository (stdio): Status, diffs, logs and commits for one local repository. Source: PyPI mcp-server-git (reference server)
• Knowledge memory (stdio): A small local knowledge graph the agent can add to and search. Source: npm @modelcontextprotocol/server-memory (reference server)
• Time and time zones (stdio): Current time and conversions between time zones. Source: PyPI mcp-server-time (reference server)
• Database (your server) (stdio): Template for a database MCP server you choose. The connection string stays in your client, never on this site. Source: Any database server you trust; check whether it can be limited to read-only.
• Chain RPC (remote) (http): Template for a remote MCP endpoint that reads an EVM chain such as Robinhood Chain. Source: Any remote MCP server you operate or trust (Streamable HTTP).
• Custom remote server (http): Any MCP server reachable over Streamable HTTP. Source: Yours.
• Custom local server (stdio): Any MCP server your client starts as a local process. Source: Yours.

The generated file uses the common mcpServers layout: command and args for local servers, type: "http" and a url for remote ones. Secret fields (bearer keys, connection strings) are never typed on this site: the file carries a placeholder such as <YOUR_KEY: set in your client> that you replace in your own client.

Tool Registry

Every tool the router knows is written as connector.tool, for example filesystem.write_file. A tool has a description, an access level (read, write or sensitive) and an input schema in a JSON Schema subset: type, properties, required, additionalProperties, enum, const, string length and pattern, number range, items and list length. Unsupported keywords are reported instead of silently ignored.

The router validates every call's arguments against the schema before anything runs, so a malformed call is refused with the exact field that failed. You can import the suggested tools of any connector you added and tighten their schemas afterwards.

Permission Controls

A policy is a list of agents. Each agent has four parts:

• allow: rules that name tools this agent may call. With no allow rule, the agent can call nothing.
• deny: rules that win over allow, for the dangerous corners of a broad allow rule.
• approval: rules for calls that must wait for a person even when allowed.
• limit: at most N calls in M minutes; past that, calls are refused.

Rules match the qualified tool name; * matches any run of characters, so builtin.* covers every built-in tool and *.send_* covers any sending tool on any connector. A policy switch (on by default) makes every tool marked sensitive wait for a person whatever the lists say. The editor shows a live matrix of each agent against each tool before you save.

Tool Call Routing

Every call goes through the same steps, in this order:

1. The tool must exist in the registry and its connector must be on. Otherwise: unknown.
2. The agent's policy is read: deny rules, then allow rules, then the call limit. Otherwise: denied, with the rule that decided it.
3. The arguments must match the input schema. Otherwise: invalid, with the failing fields.
4. If an approval rule or the sensitive switch applies, the call waits. Otherwise it runs.

In the playground you can send a direct call (tool plus JSON arguments) or a plain request. Plain requests are read by a transparent rule set that maps phrases to built-in tools. If the site operator configured an AI key, a model may propose the call instead; its proposal still goes through every step above.

Human Approval

Waiting calls collect in the Approvals tab with the agent, the tool, the reason and the exact arguments. Approve runs the call after routing it once more against the current policy, so a rule you tightened while it waited still applies. Reject records the refusal and nothing runs.

Activity Monitor

Each call becomes one entry: time, agent, tool, arguments, status (ran, waiting, denied, invalid, rejected, error, routed to your client) and the result summary or reason. Filter by agent or status, open an entry for the raw output, export everything as JSON. The last 300 calls stay in this browser.

Built-in tools

These tools really run inside the playground. Chain reads go through this site's read-only relay to Robinhood Chain, then the public RPC; hashing and JSON work happen in your browser; the notebook is stored in your browser.

{
  "type": "object",
  "properties": {},
  "additionalProperties": false
}

{
  "type": "object",
  "properties": {},
  "additionalProperties": false
}

{
  "type": "object",
  "properties": {},
  "additionalProperties": false
}

{
  "type": "object",
  "properties": {
    "address": {
      "type": "string",
      "pattern": "^0x[0-9a-fA-F]{40}$",
      "description": "0x address on Robinhood Chain"
    }
  },
  "required": [
    "address"
  ],
  "additionalProperties": false
}

{
  "type": "object",
  "properties": {
    "address": {
      "type": "string",
      "pattern": "^0x[0-9a-fA-F]{40}$",
      "description": "0x address on Robinhood Chain"
    }
  },
  "required": [
    "address"
  ],
  "additionalProperties": false
}

{
  "type": "object",
  "properties": {
    "hash": {
      "type": "string",
      "pattern": "^0x[0-9a-fA-F]{64}$"
    }
  },
  "required": [
    "hash"
  ],
  "additionalProperties": false
}

{
  "type": "object",
  "properties": {
    "text": {
      "type": "string",
      "maxLength": 20000
    },
    "algorithm": {
      "type": "string",
      "enum": [
        "sha256",
        "keccak256"
      ]
    }
  },
  "required": [
    "text"
  ],
  "additionalProperties": false
}

{
  "type": "object",
  "properties": {
    "schema": {
      "type": "object"
    },
    "value": {}
  },
  "required": [
    "schema",
    "value"
  ],
  "additionalProperties": false
}

{
  "type": "object",
  "properties": {
    "json": {},
    "path": {
      "type": "string",
      "maxLength": 200
    }
  },
  "required": [
    "json",
    "path"
  ],
  "additionalProperties": false
}

{
  "type": "object",
  "properties": {},
  "additionalProperties": false
}

{
  "type": "object",
  "properties": {
    "text": {
      "type": "string",
      "minLength": 1,
      "maxLength": 500
    }
  },
  "required": [
    "text"
  ],
  "additionalProperties": false
}

{
  "type": "object",
  "properties": {},
  "additionalProperties": false
}

Policy registry

ConexiPolicyRegistry lives on Robinhood Chain, network 4663. Not deployed yet: until it is, Publish in the hub runs in practice mode (a wallet signature kept in your browser).

• publish(name, manifestHash, policyHash) adds the next version of the caller's entry. Names are 1 to 40 characters of a-z, 0-9 and “-”, and live in the publisher's own namespace.
• Publishing exactly the same pair as the newest version is refused, so versions always mean a change.
• Reads: release(id), versionsOf(entryKey), latestId(entryKey), findRelease(entryKey, manifestHash, policyHash), entriesOf(publisher), releaseCount().
• Events: EntryOpened for a new name, Published for every version, with the chain's own block number.
• No owner, no admin, no fee, no pause, no proxy, no constructor arguments; nothing is payable. Gas in tests: about 304,000 for a new name and 225,000 for a later version.

The manifest is canonical JSON (sorted keys) of the enabled connectors (name, template, transport) and their tools (name, access, description, input schema). Folders, URLs and keys are left out on purpose. The policy is hashed after sorting agents and rules, so reordering lines in the editor does not change it.

Verify a release

Someone sends you their manifest and policy files plus their address and the name. Paste them into the Verify tab: your browser recomputes both hashes and asks the registry for every version of that name. A match shows the release number, version and block, and tells you whether a newer version exists.

$CONEXI

$CONEXI is the project token on Robinhood Chain, launching on Pons. Its planned uses are service credits, integration capacity and premium monitoring for the hosted parts that do not exist yet. Nothing in the hub needs it. Details on the token page.

Security model

• The hub has no account and no server-side copy of your setup. Clearing this browser's site data clears the hub.
• Secrets never pass through the site: connector templates write placeholders.
• The relay that reads Robinhood Chain for the playground only forwards read methods, with per-network budgets; it never forwards a signed transaction.
• The policy here governs calls routed through the hub. Your MCP client and the servers it starts still run on your machine with your permissions; use the generated config to keep that set small.
• The registry stores hashes, not files. A hash proves a file is unchanged; it does not prove the file is safe.
• The contract is new and has not had an independent review. It holds no funds; the cost of a mistake is the gas of a publish.

Run it yourself

The site is a Next.js app. Install with npm install, build with npm run build and start with npm start. No environment variable is required. Optional ones: ROBINHOOD_RPC_URL for your own RPC, NEXT_PUBLIC_WALLETCONNECT_PROJECT_ID for WalletConnect, OPENROUTER_API_KEY (and OPENROUTER_MODEL, AI_HOURLY_LIMIT) for the optional AI reader, and KV_REST_API_URL with KV_REST_API_TOKEN to share rate-limit counters between server instances.

Contracts are in contracts/ (Foundry): ./setup.sh && forge test. npm run verify-deployment checks that a deployed address runs exactly this build.

Planned

• Developer API: connect AI apps to the hub programmatically.
• Hosted connectors: servers that run for you, reachable as remote MCP endpoints.
• Shared, synced hubs for teams.
• $CONEXI utility: service credits, integration capacity, premium monitoring.

None of these exist yet. They are listed so you know where the project is heading, not as promises.

FAQ