Skip to content
Aghata

Connections

Every tool call, one ledger.

Forty-plus app toolkits, plus any MCP server you bring — all feeding one audit spine. Every call the agent makes is classified, recorded, and reviewable, and the defaults are safe before they're convenient.

Gmail
Slack
Notion
Linear
GitHub
Google Drive
Google Calendar
HubSpot
Airtable
Jira
Asana
Stripe
Dropbox
Discord
Trello
Sheets

+ 24 more toolkits · and any MCP server you bring

Two ways in

The apps you use, and the tools only you have.

Off-the-shelf toolkits cover the software everyone runs on. Your own MCP servers cover everything else — internal APIs, custom systems, the tools that make your work yours.

Toolkits

OAuth in, live status, no mirror

Connect Gmail, Slack, Notion, Linear, and forty-odd others with a normal authorization flow. Aghata keeps no shadow copy of your connection state — status is read live, so it can't drift from the truth.

Your MCP servers

Bring your own capabilities

Point Aghata at any remote MCP server. Its tool catalog is fetched and cached, each tool individually toggleable, names cleanly namespaced so your deploy tool never collides with anyone's.

Secured by default

Encrypted tokens, guarded egress

Server tokens are encrypted at rest from day one. Connections are HTTPS-only, private and internal address ranges are blocked, and responses are size- and time-capped.

Lazy and bounded

Nothing runs until it's used

Server connections open only when a tool actually executes, and each session loads at most five relevant toolkits — a deliberate bound that keeps runs focused and reviewable.

The defaults

Off by default where it should be.

A tool platform's real safety story is its defaults — what happens before you've configured anything. These are Aghata's.

Chat-disabled on arrival. A newly connected toolkit works in supervised sessions immediately — and not in plain chat, which has no approval loop. Chat proposes a task instead of acting.

Conservative risk classing. Tools declare their risk where they can; where they don't, Aghata assumes write, not read. Misclassification fails toward asking you.

Per-toolkit allowlists. Trim any toolkit to exactly the tools you want exposed, and override risk classes per tool when you know better.

One approval primitive. Composio toolkit, your MCP server, built-in tool — anything beyond a read stops at the same approval card inside a session.

Five toolkits per run. Sessions select the few toolkits relevant to the goal instead of carrying all forty everywhere — smaller surface, clearer audit.

Typed failures. A missing key or an unreachable server degrades to a disabled control with a reason — never a mystery crash mid-run.

The audit spine

One feed answers 'what did it actually do?'

Every tool execution — every toolkit, every server, every surface — flows through one wrapper into one ledger. The Activity feed is that ledger, made readable.

Nothing is off the books

There is no second code path: chat tools, session tools, scheduled runs, and even connector sign-ins all write to the same ledger. If it executed, it's in the feed.

Readable, filterable, attributable

Filter by source or outcome, and follow any row to the session that made the call. “What has the agent done with my Slack this month” is a query, not an act of faith.

Teams: grant, revoke, audit

Admins share toolkits and servers with the workspace and review the ledger; members work through scoped grants. Nobody's boss sits inside every approval.

Questions

What people ask about connecting tools.

How do I connect an app?+

OAuth, the normal way: pick a toolkit, authorize it, done. Aghata doesn't mirror or cache your account state — live connection status is the source of truth, so what you see is what's actually connected.

Can I bring my own tools?+

Yes — add any remote MCP server by URL. Its tools are namespaced, cataloged, and individually toggleable, and bearer tokens are encrypted from the moment you save them. Your internal APIs become agent tools without waiting on us.

What stops a connected tool from doing something destructive?+

Risk classification. Every tool is classed read, write, external send, or destructive — from its own annotations where available, defaulting to the conservative side where not — and everything beyond a read stops at an approval inside sessions.

Why can't chat use all my tools?+

By design. Plain chat has no approval loop, so tools that write to the outside world aren't registered there — new toolkits arrive enabled for supervised sessions and disabled for chat. When a chat wants to act, it proposes starting a task instead.

What does the Activity feed actually show?+

Every tool execution across every surface — which tool, which toolkit or server, which session, what risk class, whether it succeeded — with arguments previewed and secrets never stored. Ninety days of it, filterable.

How does this work for a team?+

Admins activate shared toolkits and servers for the workspace; members use them through scoped grants. Admins grant, revoke, and audit — they don't sit in the approval path for every action, and per-use approvals stay with the person running the work.

Chapters of one system

Give it the outcome. Keep the control.

Start free in the product, or talk to us about how your team would use it.