Skip to main content
Connections give CloudThinker agents access to your infrastructure through the Model Context Protocol (MCP), an open standard for giving AI agents tools. Connect a service once and every agent — Alex, Oliver, Tony, Kai, and Anna — can use it without separate setup.

​
Try the demo environment

No credentials to hand over yet? CloudThinker hosts a shared, read-only demo environment so you can watch agents work before connecting anything of your own. On a new workspace, a Home banner offers it and opens Connections with the demo-capable services filtered in.
  • Services that currently offer a demo — Kubernetes, AWS, Google Cloud, and Azure, each when its demo target is available — show Demo available in their connection details, and the demo offer sits above the credential form in the connect dialog.
  • Take the offer and wait about a minute while the demo connects. CloudThinker then opens chat with an editable overview prompt that names the demo target — adjust it or send it as is.
  • Agents can read the demo environment but never change it. The environment is shared, so other people trying the demo see the same resources you do.
  • Demo chats spend credits — the usage units that meter agent work — like any other chat.
  • After you connect your own account for the same service, the Connections page offers to remove the demo.

​
Add a connection

1

Pick a service

Browse the catalog below and open the guide for the service you want to connect.
2

Create credentials

Follow the guide to create least-privilege credentials — read-only wherever possible.
3

Connect

In CloudThinker, navigate to Connections in the sidebar — or open Chat Settings (the gear icon beside the + button in the chat prompt box) and select Connections — then select the service and enter the credentials. CloudThinker tests the credentials in the background, so expect a Testing status first, then Connected.
4

Verify

Ask an agent a question against the new connection. Each guide includes a verification prompt.

​
What happens after you connect

The first time a connection reaches Connected, Anna automatically starts discovery — a one-time, read-only investigation of the newly connected service. The connection’s detail panel gains a Discovery section that fills in as the run progresses; the run’s working conversation stays out of your chat history, so the panel is the durable result. Discovery never changes anything in the connected service. It publishes two things:
  • Evidence — durable observations about how the service is set up, each citing the read that produced it.
  • Opportunities — next-step proposals backed by that evidence. There are two kinds: connect a related service that would make the evidence more useful, or accept a proposed recurring task — with an editable title, prompt, and daily, weekly, or monthly cadence — that is created as an automation when you accept it.
Discovery spends credits like any other agent run. If the workspace balance is too low, the run pauses with a notice instead of starting; top up, then choose Run discovery on the Discovery panel to resume. The same Run discovery control re-runs discovery later — after you widen permissions or scope, say — and requires edit permission on the connection. Each run also saves durable notes about the service to workspace memory, so later agent work on the same connection starts already oriented.

​
When a connection breaks

A connection whose credentials stop working in the background — an expired token, a revoked key, a deleted role — flips from Connected to Error, and workspace admins receive one notification per outage (in-app and email, plus your chat platform when one is set up), not one per failed retry. A failed test you run yourself doesn’t notify anyone — you can already see the result. While a connection shows Error, scheduled background work that depends on it is skipped — Optimize cost refreshes, scheduled automations, and Pulse alert polling all wait. To recover, fix the credential on the provider’s side if needed, then update and re-test the connection from its detail panel. When the status returns to Connected, everything resumes on the next scheduled cycle.

​
Cloud platforms

​
Infrastructure & access

​
Databases

​
Messaging & streaming

​
Observability & monitoring

​
CI/CD & code quality

​
Incident & ticketing

​
Custom MCP

If a service isn’t in the catalog, add it as a custom MCP connection — no connector code required.

​
Git providers and chat platforms

Git providers — GitHub, GitLab, Bitbucket, and Azure DevOps — are in the CI/CD catalog above; connecting one also powers Review. Chat platforms are set up as workspace integrations instead:

​
Security

  • Least privilege — grant only the permissions the agents need for your use case; start read-only and widen later.
  • Read-only by default — use read-only credentials unless you want agents to make changes through this connection.
  • Rotate credentials — rotate keys and tokens on your normal schedule; CloudThinker picks up the new value when you update the connection.
  • Revoke on offboarding — remove the credential at the provider when you delete a connection or a teammate leaves.

Connect AWS

Set up the most common starting connection with an IAM role or access keys.

Custom MCP connections

Extend agents with any tool that speaks the Model Context Protocol.

Meet the agents

See what Alex, Oliver, Tony, Kai, and Anna do with your connections.

Automation & autonomy

Let agents act on connected services in Manual or Auto mode.