Mindset docsBuildersBuildConnect a system
Connect a system
Lets an agent read from or write to one of your systems, through operations you choose.
Skills for your coding agent
Ask your coding agent#
Connect our finance system's HTTP API so the invoice exceptions agent can read invoices and purchase orders. Read only for now.What gets built#
A connection holds the system's address and credential, with one operation for each action an agent may take. The agent reaches the system only through those operations, and the credential never reaches the model.
| Type | Use it for | What it needs |
|---|---|---|
| HTTP API | A system with an HTTP API. Operations come from its OpenAPI description, a documentation page, or your description of each endpoint | A token, up to three headers, or a key in the address. An API that needs OAuth can't be connected yet |
| MCP server | A vendor's remote MCP server. Each tool becomes an operation | A token, headers, or an OAuth sign-in. Only remote servers: a local (stdio) server can't be connected |
| Postgres database | Lookups and joins over more data than a sheet holds. Each query is a fixed, parameterized SQL statement | A connection string |
| Google Sheet | A small table a person also keeps by hand. Two operations: get_range reads and append_row writes | A service-account key, with the sheet shared to the service account's email |
| Knowledge base | Searching your documents. Mindset doesn't store or index them: they stay on your search server | A remote MCP search server with exactly one tool, rag_search |
Connection types lists every type and its fields.
What you decide#
- Which operations exist. Only the ones the agent needs. New MCP tools arrive switched off.
- Which are writes. A
GETis a read and every other method a write. An MCP tool's marking comes from an admin, then the server's own hints, then a model, and anything still unanswered is a write. A database query's boundary is the login's own privileges, so give a read-only job a login that can't write. Correct any marking that's wrong. - Whether a new write needs a person. A read needs no approval. A write is approved once per operation, and with your org's auto-enable setting on (the default) it's enabled with no person involved. See Approve what agents can do.
- Who can use each operation. An operation is offered to agents only when it and each of its parameters have a description, because the model picks tools from them. A database query starts out available to functions only.
Done when#
- One real read came back, and you checked a value in it against what the system's owner sees. Enabling an HTTP API read makes that call, and the operation's output shape is taken from the real response. A database query runs inside a transaction that is rolled back. A knowledge base answers a Sample query.
- You entered the credential on the capture page yourself.
- Every enabled write is one you meant, and you know whether a person approved it or the org setting enabled it.
See it working#
Live demoHelp widget · LedgerlyA billing help agent reads charges over MCP and stops at a refund nobody has approved. Live demoTrip planner · Wayfarer TravelPlan a Lisbon trip that uses every feature, each one lit on the Features tab as it fires.In your repo#
Keep each connection and its operations as one file in agents/connections/, beside your agents. The file never holds the credential: a person enters it on a capture page, once per environment. See Keep your agents in your code.
In the Studio#
Open Connections → + New connection. I will set it up gives the form for an HTTP API or an MCP server: enter the address and credential, press Check this address, then Add it, and set up operations on the Operations or Tools tab. Describe it to the builder hands the job to the Connection Builder, which is the way to add a Postgres database, a Google Sheet or a knowledge base. When a connected system changes, see Change something that's live.