Appearance
AI agents (MCP)
Everything you can do in the dashboard, an AI assistant can do too — look at your projects, add a service, run a deploy, read the logs when one fails.
The dashboard serves a Model Context Protocol endpoint at /mcp. MCP is the standard way assistants like Claude connect to a tool, so anything that speaks it works: the Claude apps, Claude Code, editors with MCP support, or your own agent built on an SDK.
Connect from the Claude apps (easiest)
Add https://managed.works/mcp as a connector in the Claude app and press Connect. A browser tab opens where you:
- Sign in to your Managed account (or switch accounts with "Not you?").
- Choose which organization the app may work in.
- Optionally narrow it to a single project, or make it read only.
- Press Connect.
That's the whole setup — approving creates an access token behind the scenes, and it appears in Settings → Agent access like any other, where you can see when it was last used and revoke it. This is standard MCP OAuth, so the same flow works for any client that supports it.
Or create a token by hand
For clients that take a bearer token instead:
- Open Settings → Agent access in your organization.
- Give the token a name you'll recognise later ("Claude on my laptop"), choose what it can reach, and click Create token.
- Copy the token. It is shown once and can never be shown again — we only keep a fingerprint of it, so a lost token is replaced, not recovered.
The panel also gives you the exact command to add it to Claude Code:
bash
claude mcp add --transport http managed https://managed.works/mcp \
--header "Authorization: Bearer mgd_agent_..."For any other client, point it at https://managed.works/mcp and send the token as an Authorization: Bearer header.
Deciding what an agent may do
A token carries your own access, so give each agent the narrowest one that still lets it help:
| Choice | What it means |
|---|---|
| All projects | Every project in the organization, now and in future. |
| One project | Only that project. Every other one reads as "not found". |
| Read only | The agent can look but never change: no deploys, no configuration edits, no service commands. It isn't even shown the tools it would be refused for. |
A token works until you revoke it, and it stops working on its own if you leave the organization or your account is suspended. The list shows when each token was last used — revoke anything you don't recognise.
Minting a token is deliberately not something an agent can do. Otherwise a read-only agent could issue itself one that writes.
What an agent can do
The endpoint offers around fifty tools, grouped the way the work is:
- Getting its bearings —
whoami,list_projects,get_project,list_organizations. - Setting things up —
list_service_packages,describe_service_package,configure_service,remove_service,add_cloud_account,add_package_source. - Servers —
list_servers,get_server,check_server,adopt_server,forget_server,find_cloud_servers,set_server_access. - Deploying —
plan,deploy,get_deploy,list_deploys. - Operating what's running —
query_service(read a service's live status),run_service_command(backup, promote, restore),check_health,get_metrics.
An agent can also attach a project's current state to the conversation without spending a tool call, as an MCP resource: managed://project/<name>/state, /services, or /servers.
How an agent works, and the guard rails
An agent follows the same two-step rhythm you do in the dashboard: change the configuration, then deploy. Configuration changes touch nothing on your servers until a deploy runs.
Three things are never implicit, on purpose:
- A plan that destroys, adopts or moves something is refused unless the agent explicitly confirms it. The confirmation is a separate, deliberate argument, so a model has to have decided to do it — and a well-behaved assistant shows you the plan and asks first.
- A destructive service command (restore, promote, reset) is refused the first time and has to be re-run with confirmation.
- Removing a service always needs confirmation, because it destroys data.
A deploy is a background job. The agent gets a job id back and follows it, which means it can tell you why a deploy failed rather than that it did. Only one deploy runs per project at a time; an agent that tries during one is told to wait.
Everything an agent does is recorded against your account and appears in the project's activity, exactly like work done from the dashboard or the CLI.
Secrets
Passwords and other secrets never leave the platform through this endpoint. A setting a package declares as secret reads back as (hidden), sudo passwords are reported as present or absent but never returned, and a value managed has encrypted stays encrypted. An agent can set a password and can ask managed to generate one — it just can't read one back.