agno connect finds your running AgentOS, configures authentication for each client, writes the client’s MCP configuration, and verifies entries it can authenticate immediately. Token-protected endpoints use service-account tokens. OAuth endpoints use client sign-in. Your coding agents can then run your agents, teams, and workflows through the AgentOS MCP server.
The AgentOS must have its MCP server enabled:
The Execution Flow
- Discover. An interactive run offers a choice across live env-file, localhost, and previously configured AgentOS URLs.
--url, an exportedAGENTOS_URL, and non-interactive runs select one deterministic target. The CLI then reads its version, MCP path, and auth mode fromGET /info. - Choose authentication. OAuth-protected MCP endpoints write tokenless entries for one-time client sign-in. Service-account mode resolves an admin credential from
AGNO_ADMIN_TOKENorOS_SECURITY_KEY, or prompts for it. - Mint when needed. Service-account mode creates one account per client (named
claude-code,cursor, and so on) with the server’s default run and read scopes and a 90-day expiry. An unsecured AgentOS connects without credentials. Pass--patto use service-account tokens with an OAuth-protected endpoint. - Write. Add an MCP server entry, named after your AgentOS (
agentoswhen it has no name), to each client’s own config file. - Verify. Read the entry back the way the client would resolve it. Service-account and unsecured entries complete an MCP
initializeandtools/listcall. OAuth entries reportsign infor the client to complete. - Report. Print per-client results:
connected,sign in,already ok,skipped,action needed, orfailed.
sign in in the report). Pass --pat to mint tokens anyway, for headless clients.
Re-runs are safe. Entries that still verify are left alone, and --skip-existing never touches anything that exists. Broken or stale entries are rotated after a confirmation prompt in interactive runs; non-interactive runs (--json or no TTY) report them as failed instead, so pass --rotate in automation.
Supported Clients
By defaultagno connect configures every client it detects on the machine. Scope the run with --clients:
The Claude Desktop entry written by
agno connect launches the mcp-remote bridge over stdio. Node.js must be installed for that entry to start.claude.ai and ChatGPT
The hosted chat apps add MCP servers from their own cloud, soagno connect cannot write or verify anything for them. It prints the setup steps instead:
- The AgentOS must be on a public HTTPS URL. A local AgentOS is unreachable from the apps’ clouds; deploy it or expose it through a tunnel first.
- The MCP endpoint must either allow unauthenticated access or expose OAuth. These hosted UIs do not accept an Agno service-account bearer token.
- Paste the printed MCP URL into the app’s custom connector or custom app flow. Menu names, plan requirements, and workspace controls vary by provider. Follow the current Claude custom connector guide or ChatGPT MCP app guide.
connect prints these steps automatically, without --clients.
Options
Security
Each client gets its own service account, so if one token leaks or a client is retired, you can revoke just that one without touching the others:Disconnect
agno disconnect removes the AgentOS entry from each client’s config. It edits configs only, so it works with the AgentOS stopped and needs no admin credential. Without --server-name it removes every entry pointing at the target AgentOS; entries pointing at any other server are never touched. Pass --revoke to also revoke the service accounts connect minted (this path needs the running AgentOS and an admin credential).
Scripting
After command-line parsing succeeds,--json prints one JSON document with the discovered OS, per-client results, and the exit code. Exit codes: 0 all connected, 1 nothing connected, 2 usage error, 3 partial success. Typer parse errors write to stderr without JSON. JSON mode never prompts. When a run needs to mint or rotate service accounts, export AGNO_ADMIN_TOKEN or OS_SECURITY_KEY first.