Skip to content
Extend the platform · Custom MCP servers

Your internal systems, usable by the AI

MCP (Model Context Protocol) is the standard way to present tools to an AI. Plug in an MCP server address — or the OpenAPI spec of an API you already have — and its tools become available in chat, exactly like the ones built into the platform.

What it enables

Two ways to plug in your systems

Depending on what your service already exposes, you pick how to connect it — the rest of the experience is identical.

  • A remote MCP server

    You enter the server address. Its tools are discovered live, every time it is used in chat: when the server adds one, it appears without you touching the configuration.

  • An API you already have

    If your service is not MCP but exposes an OpenAPI spec, paste it: the platform derives the tools and calls the API over HTTPS. You can then rename tools, hide some and fix parameters.

  • Every usual authentication

    None, bearer token, API key, username and password, or full OAuth 2.0. Sensitive values are encrypted at rest.

  • Shared or personal

    Enter credentials once for everyone, or ask each person for their own — useful when the remote system needs to know who is acting.

  • One-click connection where possible

    On a server that follows the standard all the way, there are no credentials to paste: the person clicks Connect and authenticates with the provider.

  • Usable by the AI like any other

    Once published, the connector appears in the chat picker. The assistant can also reach for it mid-conversation when the request calls for it.

Who can do it

Open to your teams, governed by your administrators

Adding a connector is not reserved to administrators — but nothing is visible to the whole organization until somebody decides so.

  1. 01

    Self-serve by default

    Any permitted person can plug in a server for themselves. The connector they create stays private until they share it.

  2. 02

    Administered organization-wide

    Your administrators see and edit every connector, and decide its visibility: admins only, open to all, limited to people or groups, or hidden.

  3. 03

    Nothing is public by accident

    A newly added connector appears for nobody else until its visibility has been chosen. That is a deliberate product decision.

  4. 04

    Traceable

    Creations, edits, deletions and shares are logged, and a panel shows a connector's recent calls so you can diagnose what is happening.

Limits, stated plainly

What to know before plugging in

A connector sends requests out of your instance to a third-party service: here are the exact edges.

  • Only MCP servers reachable over HTTP(S) are supported. A local server launched as a subprocess (stdio) is not — a containerised instance cannot and must not start one.
  • Private, local or internal addresses are refused, both when adding and on every call, so a connector cannot be used to probe your network.
  • Redirects are never followed: a server that answers with one will fail, deliberately, so your credentials are not replayed elsewhere.
  • Only the text returned by tools is passed to the model; returned images and resources are replaced by a placeholder.
  • If the remote server does not answer, the connector simply appears with no tools rather than with an error.
  • The recent-calls log is a diagnostic window (the last 50 calls), not an archive — and it also contains the parameters that were sent.

Plug in your first server

Create your workspace, add your MCP server address and choose who may use it.