MCP server

anyport mcp serves your Anyport organization to an MCP client over stdin and stdout. Clients that speak the Model Context Protocol — Claude Code, Claude Desktop, and others — can then answer questions about what you have deployed without you pasting console output into a chat.

It is read-only by default. Writes exist, but only if you ask for them when you register the server, and no tier can delete anything — see Writes are opt-in.

Requirements

The CLI, signed in:

curl -sfL https://anyport.dev/cli.sh | sh
anyport auth login

The MCP server reuses that session. It does not hold its own credential, which also means it inherits the session's 24-hour expiry — see Sessions and limits below.

Register it with a client

With Claude Code:

claude mcp add anyport -- anyport mcp

Any other client takes the same two pieces: the command is anyport, the argument is mcp. A client that wants JSON configuration usually expects something of this shape:

{
  "mcpServers": {
    "anyport": {
      "command": "anyport",
      "args": ["mcp"]
    }
  }
}

Use an absolute path to the binary if the client does not inherit your shell's PATH. which anyport will tell you where the install script put it.

Nothing listens on a port. The client starts the process and talks to it over stdin and stdout, so there is no endpoint to expose and nothing to firewall.

What the agent can see

Tool	What it returns
`whoami`	The account the server is authenticated as, and the console it talks to.
`list_organizations`	Organizations this account belongs to, with the ids other tools accept as `orgId`.
`list_clusters`	The clusters in the organization, and whether each one's agent is connected.
`list_projects`	Projects in the organization.
`get_project`	One project by name, plus how many resources inside it need attention.
`list_apps`	Container apps in a project, with the image and status of each.
`get_app`	One app in detail: image, replicas, ports and resources.
`list_deployments`	An app's published revisions, newest first — what image each shipped, when, and who published it.
`list_services`	Managed services installed in a project.
`get_service`	One service in detail, including the environment variable names an app receives when it binds. Connection values are never returned.
`list_domains`	Custom domains, with their DNS and certificate state.
`search_app_logs`	An app's retained logs over a time window.

Most tools are scoped by project name, so a conversation usually starts with list_projects. Calls use the organization the CLI is logged into unless the agent passes orgId.

list_clusters is worth knowing about when something looks wrong: an agent that is not connected is the usual reason resources sit in Applying or Unknown, because no change reaches that cluster until it reconnects.

search_app_logs reads retained history, which requires the Observability service to be installed on the cluster. Without it there is no store to search — see Logs & metrics.

Writes are opt-in

Registered as above, the server offers the read tools and nothing else. Write tools appear only when --allow names a tier:

Tier	What it adds
`create`	Makes new things and touches nothing that already exists: create an app, install a service, duplicate a project, save a project as a template.
`operate`	Changes something that is already running, recoverably: deploy an image, roll back, run a one-off command, set a secret, pause a project, add a domain.

anyport mcp --allow=create,operate

Take either on its own. create is the easier one to reason about, because nothing it does can disturb something already serving.

What is true at every tier

Nothing is deleted. No tier removes a project, an app, a service, a domain or a secret. Deleting stays something a person does, in the console or the CLI.
No secret values are returned. get_service gives the variable names an app receives and never their values, and set_secret writes without being able to read. The console's own reveal is a separate, recorded permission that the MCP server does not have.
No interactive shell. There is no terminal tool. operate does include run_command, which runs one command to completion on the cluster and returns its output — a migration or a backfill. It is kept as a task, so the run stays in the project's history afterwards, attributed to the account this server is signed in as.

An agent reading your infrastructure is a far easier thing to reason about than an agent changing it, which is why the default did not move. What changed is that the two useful write cases — build me an environment, and run this migration — no longer require you to leave the conversation and do it by hand.

Sessions and limits

Authentication is the CLI's session from anyport auth login, which the console expires after 24 hours. When it lapses, the tools start failing and you refresh it by running anyport auth login again. That is workable for a session you started and are sitting next to. It is not suitable for an unattended agent, and long-lived credentials for that case do not exist yet.

The agent sees exactly what your account sees. If your role is limited to one project, so is the agent. Registering the MCP server does not widen your access, and it does not narrow it either — so if you want an agent to see less, sign in as an account that can see less.

Troubleshooting

The client shows the server as failed. Run anyport mcp in a terminal. It prints the console it is serving on stderr and then waits. If it exits complaining about login, run anyport auth login.

The client cannot find the command. Give it the absolute path from which anyport. GUI clients frequently do not inherit the PATH your shell has.

Tools return nothing for a project you can see in the console. Check the organization with whoami, and that the project name is the one in the URL rather than its display name.