Mindset docs
llms.txt

How it worksConnections and operations

Updated 27 Oct 2026View as Markdown

Connections and operations

A connection links Mindset to one outside system and holds its credential. Operations are the single reads and writes agents make through it.

Skills for your coding agent

See it running: Trip planner

MCP serverSDK and APIYour own cloud:AWSGCPAzureor hosted by MindsetMindset platformAgentScriptVersionRunConnectionOperationFunctionWidgetSecurity and complianceone posture · audit trail · personal data redactionBuilderscoding agentOperatorsAI clientor the StudioYour appthe SDKYour serverthe APIThe Huband schedulesBuilderscoding agentOperatorsAI client or the StudioMCP serverYour own cloud:AWSGCPAzureor hosted by MindsetMindset platformAgentScriptFunctionConnectionOperationWidgetVersionRunSecurity and complianceone posture for the org,audit trail and personal data redactionSDK and APIYour appthe SDKYour serverthe APIThe Huband schedules

A connection links Mindset to one outside system and holds its address and credential. Mindset adds the credential to each call, so it never reaches the agent or the model. There are seven types: HTTP API, MCP server, AI model, Postgres database, Google Sheet, Knowledge base and StackOne. What each asks for is on Connection types.

An operation is a single action on a connection, with fixed parameters, marked read or write. Operations are an agent's only way into a system, so a connection's operations are the complete list of what agents can do there.

Why it matters#

You don't write credential handling, and no prompt can get an agent to reveal a credential it never sees. You can read a connection's operations, and approve its writes, before anything runs.

The invoice exceptions agent uses the finance system (an HTTP API) and the supplier contracts knowledge base. On the finance system:

OperationKindAvailable toAssigned
get_invoiceReadAgents and functionsThe agent
get_purchase_order_for_invoiceReadAgents and functionsThe agent and the comparison function
get_supplierReadFunctionsNobody yet
register_supplier_queryWriteAgentsThe agent

Read or write#

A read needs no consent. A write needs consent once per operation, which your org gives automatically by default. See Security and approval.

An HTTP API operation is a read when its method is GET and a write otherwise, unless its access was stated when it was registered. An MCP tool's access is resolved in this order:

  1. An admin's choice is final. Later discoveries never change it.
  2. The server's own hints. destructiveHint: true makes it a write. Otherwise readOnlyHint: true makes it a read, and readOnlyHint: false makes it a write.
  3. A model's reading of the tool's name and description, kept only when confident.
  4. Anything still unanswered is treated as a write.

An admin can correct any marking with the tool's Access select. When in doubt, mark it a write.

From registered to callable#

An agent can call an operation only when every check passes:

CheckPasses when
ConnectionIt passed its connection test and is enabled
LifecycleThe operation is enabled
ConsentNot required, or granted. A pending write is refused, not queued
ExposureAvailable to agents is ticked, which needs a description on the operation and every parameter
AssignmentThe operation is on the agent's Resources tab, in its active version

The first three are checked on every call, so switching one off stops the operation at once. Assignment changes with the next agent version. Separately, an Untested operation can stop a script or function going live. See Versions, testing and going live.

Limits#

  • Only remote MCP servers can be connected. A local (stdio) MCP server can't.
  • An HTTP API that needs an OAuth sign-in can't be connected yet. MCP servers with OAuth sign-in work.
  • A connection keeps no history. A change applies straight away, and to undo it you change it back.

To connect one, see Connect a system, or Post to Slack or send email.