Docs / Connecting systems
Connection types
For working out how to reach a particular system, and what to do when it is not in the list.
What this is
When you create a connection you pick a system, not a protocol. What you pick decides what the login step asks you for and what Discover is able to do afterwards.
| System | What it reaches | What it asks you for |
|---|---|---|
| HTTP | Anything with an API | An API key, a token, a username and password, an OAuth sign-in, or a service account, depending on what the system expects |
| MCP server | A ready-made bridge that exposes another product's tools | Whatever that server asks for |
| Google Sheet | Rows in one spreadsheet: read a range, append a row | Google authorisation for that sheet |
| Postgres | A database directly, through queries you enable one at a time | A database user and password |
| Knowledge | Content you have loaded, searched by meaning rather than by keyword | Nothing. It is held inside your org |
| Model | A model, under a policy an admin has set | The platform's own access, or your own account |
What each one is for
- HTTP is the general case and where most connections end up. The finance system in the invoice workflow is an HTTP connection: you point it at the API, press Discover, and the reads and the one write become operations on it.
- MCP server is how you reach things Mindset does not do itself, and how you bring across a server your team already runs on somebody's laptop. Reading the text out of a scanned invoice, producing a Word or Excel document, talking to a product whose vendor ships an MCP server. Each tool on the server becomes an operation, and from then on it behaves like any other operation: enabled, given to an agent, and approved if it changes something.
- Google Sheet is for the small operational tables a person also maintains by hand. For the invoice workflow: the list of who approves supplier queries, or a table of how much variance each supplier is allowed before anyone cares. Also somewhere to drop the month's exceptions so finance can look at them in a spreadsheet.
- Postgres is for structured lookups and joins over more data than a sheet holds. Supplier payment terms and two years of invoice history, queried directly. Each query is enabled one at a time, and each is test-run against the live database inside a transaction that is rolled back, so enabling one cannot change anything.
- Knowledge is for grounding judgement in your own material. The supplier contracts knowledge base is one: stage three of the invoice agent searches it for the clause covering a price difference, and the judgement on that stage only passes if the answer names a specific clause.
- Model connections are how model access works here. An admin sanctions one model under a policy: which model, a ceiling on tokens, how PII is handled, a cost cap, and where the data may sit. Everything that calls a model calls a connection. That is why a stage in a script, or a step in a function, names a connection rather than a model name: the policy travels with it, and there is no way for the caller to pick a different model than the one it was given.
How the login details are handled
Whatever system you picked, the login details are held by us and looked up for each individual call. The agent never holds them and they never reach the model. Two things follow from that.
A call aimed at a different host than the connection declares is refused before the login details are even looked up. The host is checked first. So a call that gets redirected or rewritten on its way out cannot turn into a way of sending your finance system key somewhere else: it is stopped at the point of "this is not the host this connection is for", with nothing to leak.
Where an agent needs a credential from you during a conversation, it names the field it needs and you type the value into a form the model cannot read. The agent gets back a reference it can use and never holds the text.
When the system you need is not in the picker
Three questions, in this order.
- Does it have an API? Most systems do, including plenty whose vendor sells you an integration and never mentions the API underneath. If it has one, pick HTTP and let Discover do the work.
- Is there an MCP server for it? Vendors and communities publish them for a lot of products, and it is also the route to anything Mindset does not do natively. If somebody on your team has already built one and is running it on their laptop, that is the thing to bring across.
- Is it only reachable by logging into a website and clicking through its screens? Then it is out of reach, and that is deliberate. Clicking through screens leaves nothing behind that anyone can review afterwards, which is the opposite of the reason you are here. Ask the vendor whether there is an API behind those screens; there usually is, and it is usually not advertised.
You're done when
- You know which system each thing in your workflow maps to.
- You have login details for each one, scoped to what those operations actually need and pointed at the right account.
- For anything that did not map, you know whether it has an API or an MCP server, or that it genuinely has neither.