On this page

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 -fsSL 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.
`get_cluster_health`	Whether one cluster is OK: agent connection and version, each node's usage against what it can hold, the agent's restarts, the build queue, and findings worst first.
`list_projects`	Projects in the organization.
`get_project`	One project by name, plus how many resources inside it need attention, its cluster's network isolation and the organization's shell access policy.
`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.
`list_service_catalog`	The services that can be installed, with the settings each accepts and the variable names an app receives when it binds.
`get_service`	One service in detail, including the environment variable names an app receives when it binds. Connection values are never returned.
`list_helm_releases`	Helm charts installed in a project, with chart, version and status. Releases Anyport manages for services and the cluster are left out unless asked for.
`get_helm_release`	One Helm release in detail: chart, version, repository, namespace, pods and services. Never its values.
`list_domains`	Custom domains, with their DNS and certificate state.
`list_secrets`	Secrets in a project and the key names inside each. Never a value.
`list_tasks`	Scheduled and one-off tasks, with their schedule and how the last run went.
`list_templates`	Saved templates in the organization, ready to duplicate into a project.
`list_builds`	Builds in a project, newest first: the commit, what triggered it, and whether it succeeded.
`get_build`	One build in detail, with its output. A failed build's reason is usually only here.
`list_build_sources`	What each app builds from: repository, branch, build mode, and whether a push redeploys it.
`get_app_metrics`	CPU and memory for an app's pods, over time where history is kept, otherwise a current snapshot.
`search_app_logs`	An app's retained logs over a time window.
`list_audit_events`	Who changed what in the organization over the last 30 days, newest first.
`get_org_usage`	This month's gateway traffic, whether routing is paused, and on Anyport Cloud the credit balance and usage.
`list_notification_destinations`	Where deploy and health events are sent, what each destination hears, and its last result. Never a URL or a secret.
`list_notification_deliveries`	Recent notification deliveries and what each receiver answered.
`list_github_repos`	GitHub repositories the organization's connected accounts let it build, with each one's default branch.
`list_github_branches`	A GitHub repository's branches.
`list_registries`	Registry credentials by name and host, and which one builds push with by default. Never a username or a password.
`list_previews`	A project's pull-request previews: URLs per app, expiry, and what each service is in the preview.
`list_preview_offers`	Open pull requests that could have a preview, their state, the choices each preview offers, and what one preview reserves on the cluster.
`list_service_backups`	One database's backups: whether they are configured and healthy, the window a restore can reach, and each backup with the operator's error for a failed one.
`list_backup_archives`	Every database that backs up and how its backups last stood, plus the archives deleted databases left in the bucket and whether each can be restored.
`list_backup_destinations`	The buckets databases back up to, and whether each credential was last verified writable. Never a key.

A pull request's preview is a project of its own. list_projects leaves previews out, but once list_previews names one, every project-scoped tool accepts it — so an agent can search a preview's logs or read its apps the same way it does any other project's.

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, or a cluster on Anyport Cloud, where it is included. 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 a project, create an app from an image or from a repository, install a service, duplicate a project, save a project as a template, request a pull request's preview.

operate Changes something that is already running, recoverably: deploy an image, roll back, run a one-off command, set a secret or project variables, pause a project, bind or unbind a service, start or cancel a build, add, verify or bind a domain, resync a cluster, re-apply a project, app, secret or domain route its cluster lost, re-install a Helm release that was deleted from its cluster, take a backup of a database now.

Tier	What it adds
`create`	Makes new things and touches nothing that already exists: create a project, create an app from an image or from a repository, install a service, duplicate a project, save a project as a template, request a pull request's preview.
`operate`	Changes something that is already running, recoverably: deploy an image, roll back, run a one-off command, set a secret or project variables, pause a project, bind or unbind a service, start or cancel a build, add, verify or bind a domain, resync a cluster, re-apply a project, app, secret or domain route its cluster lost, re-install a Helm release that was deleted from its cluster, take a backup of a database now.

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, and no tier withdraws a preview, which deletes its databases. Deleting stays something a person does, in the console or the CLI. The same goes for backups: an agent can take one, but restoring, removing backups, pausing a schedule and changing destinations are anyport service backup and anyport backup commands.
No fork is let in. request_preview cannot approve a pull request from a fork; that runs someone else's code beside the project's credentials, so a person does it with anyport preview approve.
No security settings change. Network isolation and shell access are reported by get_project and changed only by a person, because each one widens what every workload or every member can reach.
No secret values are returned. get_service gives the variable names an app receives and never their values, and set_secret and set_project_variables write without being able to read. The console's own reveal is a separate, recorded permission that the MCP server does not have.
No people, no credentials. No tier invites, removes or re-roles a member, and none stores a registry credential or connects GitHub. An agent can list the repositories and registries it may deploy with; adding one is anyport github connect or anyport registry add, and people are anyport member.
The cluster's agent is left alone. Restarting, upgrading or rolling back the agent takes the cluster out of Anyport's reach until it reconnects, so those stay in the CLI. The one cluster operation a tool can run is a resync, which re-sends what Anyport manages and deletes nothing.
No Helm installs or upgrades. A third-party chart can create anything on the cluster, so installing or changing one stays something a person does, with anyport helm.
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.

Next steps#

CLI — The session the MCP server runs on, and the same actions from a terminal.
API — Script the organization directly with a service token.
Team & roles — The role your account holds, which is all the agent ever gets.