Guides

Connect to Recued

Client-by-client — MCP agents, OpenAI-compatible chat apps, and chat platforms, all through doors at the same boundary.

Everything that reaches your server from outside connects through a door, and every door leads to the same enforcement boundary — attribution, grants, audit. This page is the client-by-client view: pick what you are connecting, follow its shape.

#MCP agents

Claude Desktop, Cursor, a custom agent, or a peer Recued connect over MCP:

  1. Open the MCP door and choose the tools it exposes; the door manages its own credential.
  2. Configure the agent with your server's MCP endpoint and that credential.
  3. The agent's calls arrive attributed to it, pass your grants, and land in the audit log.

The agent sees exactly what the door grants — warehouse reads, timelines, recipes as tools — and closing the door revokes its credential.

A peer Recued is the same shape with one addition: its owner can put a question to you and hold their own run until you answer. See Ask a peer.

#OpenAI-compatible chat clients

Any chat app that accepts a custom base URL and an API key can talk to a Recued server it has been granted access to — no MCP support required. This is the surface a seller's customers use for "ask my operated knowledge" products, and it speaks the standard shape:

  • Base URL — your server's gateway endpoint.
  • API key — the door credential, sent as a normal bearer key. Customers collect theirs through a claim link.
  • GET /v1/models — returns one model: an alias the server owner names (recued-seller by default). The alias is a label, not a choice — which underlying model actually answers is the server's routing decision, set by its owner.
  • POST /v1/chat/completions — one request is one governed chat turn.

A turn runs on the server's chat engine: answers ground in what the connected contract grants, granted recipes can be called as tools with the same approval rules as everything else, and the privacy alias boundary applies to what leaves for the model. Your conversation history stays in your client — the server does not merge it into the owner's chat history.

Two practical notes: set the client to non-streaming (streamed completions are not supported yet, and the gateway says so rather than hanging), and expect chat completions only — this is a chat surface, not a full OpenAI-platform replica.

#Chat platforms

Slack and Telegram connect as messenger doors. Messages and slash commands POST directly to your server — never through Recued's cloud — and replies, notifications, and approvals can reach you in the same channel.

#Your own devices are different

The webclient and the Browser Bridge do not connect through doors — they pair, which is a narrower and more trusted relationship reserved for machines you own. See Pairing and devices.

#What every connection shares

Whatever the client, the same things hold: the caller is a named actor, its access is exactly what its door or contract grants, every call is audited, rate and usage limits apply where the door sets them, and revocation is one action — close the door or reissue the credential.

Recued is local first; your server remains the authority.

Recued Docs

Search documentation

Start typing to search the documentation.