How to connect your own systems to Tindre

For the organization that wants an Agent to read from, or act in, a system of its own: a ticketing tool, an ERP, an internal database behind an API. Tindre reaches such a system through an MCP server, a small service that lists the actions the system offers and carries them out. Either the system's vendor provides one or you run your own.

That makes three links in the chain, and every problem sits in exactly one of them: your system, the MCP server in front of it, and Tindre. Most of this page is about keeping them apart, because the usual way to lose a day is to debug the wrong one.

Before you start

• An MCP server that answers at an address Tindre can reach over the internet. See Limits.
• Administrator access in Tindre, to install the Connector and grant access to it.
• Someone who can answer for the system: what it holds, who may see which part, and what must never change without a person agreeing.
• If people will sign in individually, access to register an app in your identity provider, for example Microsoft Entra ID.

1. Decide what the Agent should do in the system

Start from the questions and tasks, not from the tool list. Write down three things the Agent should be able to do, and mark each as a read or a write.

Reads run when the Agent needs them. Writes are different: a tool that changes something waits for a person to approve it before it runs, and that approval is checked again at the moment the person confirms. How this works is described under Writes and proposals.

One consequence is worth acting on at the server. Tindre treats a tool that its server does not mark as read-only as one that changes something. If your server leaves that marking out, its tools ask for confirmation by default, including plain lookups. Have whoever runs the server mark the read-only tools as such. You can still set each tool to run immediately or ask first when you attach the Connector.

2. Decide whom Tindre acts as

There are two choices, and they decide what the system sees and what it can refuse.

Choose per person when the system has per-person permissions. With a shared credential, the Agent can fetch anything that account can see and hand it to whoever is asking, whether or not that person could open it in your system. Access roles in Tindre narrow who may use the Connector, but they cannot reproduce the permissions your system already has. Choosing per person keeps those permissions where they already live.

Choose one shared credential when the system holds nothing person-specific: a public price list, a status service, a catalog.

A Connector that signs people in individually does not exist for visitors on a public widget, because there is no person to sign in as. Do not plan an Agent on a public widget around one. See The website widget.

3. Set up sign-in

Sign-in works as follows today.

A token or header on the organization connection. The administrator enters a token, or a set of headers, when installing the Connector. Tindre sends it with every request to the server and stores it for the organization, not in an Agent's instructions. Use a dedicated account or key for this, with only the access the Agent needs, and one you can revoke without affecting anyone else.

Per-person sign-in with OAuth. Each person signs in once, and Tindre then acts with their account. It uses the authorization code flow, and it works against two kinds of authorization server:

• The MCP server's own. Many servers publish where people sign in and which scopes they accept. Tindre finds that automatically from the server's address and, if the server allows, registers itself as a client. When you would rather present a client you registered yourself, enter its client id and secret and that client is used instead.
• Your identity provider, such as Microsoft Entra ID. Register an app there, then give Tindre the client id, the client secret, the sign-in and token addresses and the scopes the tools need. Both addresses must be https. Register Tindre's callback address in the app registration, or the provider refuses the sign-in. Your Tindre contact gives you the address for your environment.

A person's connection stays alive without asking them again: Tindre renews it for them before it expires. A person can connect more than one account to the same Connector. One of them is the default, and a write runs as the default unless the person names another account.

Per-person sign-in for an organization Connector is set up through the Tindre API today. The Integrations page in Administration offers the address and a token. Ask your Tindre contact if you need the setup request written out.

Certificates and organization-wide OAuth, where Tindre signs in once as itself without a token, are not supported yet.

4. Install, grant access and attach

Three separate steps, and each can block the one after it.

1. Install. Under Administration → Integrations, add a custom MCP server: a name, the server address, and the credential from the previous step. Tindre then asks the server what it offers and lists the tools.
2. Grant access. Access roles decide who may use the Connector, and each grant can be narrowed to some of its tools. A Connector with no grants is open to everyone who has the Connectors permissions. Narrow it before anyone attaches it.
3. Attach. A Connector does nothing until it is attached to an Agent, directly or through an Area, and the tools you want are switched on. See Attach Knowledge and Connectors. Start with the reads from step 1. Add the writes once the reads behave.

Turning on a Connector can add an external recipient of your data. The administrator should write down the purpose and the data sent before attaching it to an Agent in production. The Integrations page covers this.

5. Test each link

Test in this order, and stop at the first link that fails.

1. Tindre to the server: discover the tools. On the Connector's page, use Refresh tools. If the tools list fills, Tindre reached the server and was let in. If it fails, the problem is the address, the credential or the server being down. Nothing in your system matters yet.
2. The server to your system: call a tool. Ask the Agent to do one of the reads from step 1 in a test conversation, as a person who holds the access role. If the tool is found but returns an error, the failure is behind the server, in your system or in what the server is allowed to do there.
3. What the person asked and what came back. Open the conversation in Tindre and read it: which tool was called and with what. A wrong answer with a correct call points at the system's data. A wrong call points at the tool's description on the server, which is what the Agent reads to choose it. See Conversations and review status.
4. The server's own log. Read what the server recorded for the same moment. A request that is in Tindre's conversation but not in the server's log never arrived: check the address and the limits below. A request that arrived and was refused names its reason there, which is usually more specific than anything shown to the person.

For a per-person Connector, run steps 1 and 2 as two different people, one who should see something and one who should not, and confirm the system treats them differently. That is the whole point of choosing it.

6. Run it

A sign-in expires. If a person's connection can no longer be renewed, because they were removed in your identity provider, revoked the access or changed their password, the Agent's answer still completes and that tool reports that a connection is needed. The person sees a prompt to connect again and signs in. Nothing else the Agent does is affected.

A token on the organization connection is rotated or revoked. Every person loses the tools at once. Replace the credential on the Connector and use Reconnect.

Access changes. Change who may use the Connector under its access grants. What a person may see inside your system is changed in your system. With per-person sign-in the two stay independent, so review both when someone changes role.

The server changes its tools. Tindre keeps the list it last saw. When the server adds, renames or removes tools, use Refresh tools. A tool that was switched on for an Agent and no longer exists is flagged as unavailable on the attachment. Check the Agents that used it.

Something stops answering. Go back to step 5 and test the links in order. Most failures turn out to be the first one that was never retested after a change.

Limits

• Protocol. Streamable HTTP is used by default. The older HTTP with server-sent events can be selected for servers that have not moved. MCP protocol versions are supported up to 2025-11-25.
• Response time. A server must start answering within 30 seconds.
• Response size. A single response may be at most 16 MB.
• Address. The server must be reachable at a public internet address. Private and internal addresses are refused. Use https.
• Redirects. Redirects are not followed. Give Tindre the final address.
• Sign-in. Certificates and organization-wide OAuth are not supported yet.
• Public widgets. A Connector that signs people in individually is not available to anonymous visitors.