How do I use amp-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@amp-mcp-server list all my game server instances" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

amp-mcp-server

by eddinsw

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

amp-mcp-server

An MCP server that wraps CubeCoders AMP so MCP clients (Claude Desktop, Claude Code, others) can list, inspect, and control AMP-managed game-server instances.

This project is a client of AMP's public REST API — no AMP source or binaries are redistributed. Bring your own licensed AMP install.

Tools exposed

Read-only (always enabled):

amp_list_instances — enumerate all AMP-managed instances
amp_get_instance_status — state, uptime, CPU/RAM/players for one instance
amp_get_active_users — connected users for one instance
amp_get_console_output — recent console lines for one instance
amp_get_host_status — state, uptime, CPU/RAM for the AMP controller host itself
amp_get_running_tasks — currently-running tasks on one instance (with progress %)
amp_get_update_info — pending game-server updates for one instance
amp_list_backups — local backups for one instance

Write tools (gated by AMP_ALLOW_WRITES=true):

amp_start_instance / amp_stop_instance / amp_restart_instance — instance lifecycle
amp_sleep_instance — soft shutdown (resumable faster than Stop; module-dependent)
amp_send_console_command — send a command to one instance's console
amp_take_backup — trigger a backup (poll completion via amp_get_running_tasks)
amp_update_application — apply a pending game-server update (long-running)
amp_end_user_session — disconnect a user session (universal kick across modules)

Default-off prevents accidental destructive calls.

Related MCP server: forgejo-mcp

Environment

Var	Required	Default	Purpose
`AMP_URL`	yes	—	Base URL of your AMP install, e.g. `https://amp.example.local`
`AMP_USERNAME`	yes	—	AMP admin username
`AMP_PASSWORD`	yes	—	AMP password (or remembered-token)
`AMP_ALLOW_WRITES`	no	`false`	Set `true` to enable mutating tools
`MCP_TRANSPORT`	no	`stdio`	`stdio` (subprocess use) or `http` (Docker / remote)
`MCP_PORT`	no	`3000`	HTTP listen port (HTTP transport only)
`MCP_HOST`	no	`127.0.0.1`	HTTP bind host (HTTP transport only). Docker image overrides to `0.0.0.0`.
`MCP_ALLOWED_HOSTS`	no	—	Comma-separated `Host` header allow-list (DNS rebinding protection). Required when `MCP_HOST` is `0.0.0.0`/`::` and `MCP_AUTH_MODE=none`.
`MCP_ALLOWED_ORIGINS`	no	—	Comma-separated `Origin` allow-list. Requests with a mismatching `Origin` get 403; requests with no `Origin` (server-to-server) are allowed.
`MCP_TRUST_PROXY`	no	—	Forwarded to Express `trust proxy`. Set when behind nginx/Caddy so `req.ip` is the real client.
`MCP_ALLOW_INSECURE`	no	`false`	Override the startup guard that refuses `0.0.0.0` + `none` auth + no host allow-list.
`MCP_RATE_LIMIT`	no	`120`	Max requests per window on `/mcp`. Set `0` to disable.
`MCP_RATE_WINDOW_MS`	no	`60000`	Rate-limit window length in milliseconds.
`MCP_AUTH_MODE`	no	`none`	`none` / `bearer` / `oauth` — see Authentication
`MCP_PUBLIC_URL`	when `oauth`	—	Canonical external URL of this server (resource id + JWT audience)
`MCP_AUTH_TOKEN`	when `bearer`	—	Comma-separated list of accepted bearer tokens
`MCP_OAUTH_ISSUER`	when `oauth`	—	OAuth 2.1 authorization server issuer URL
`MCP_OAUTH_AUDIENCE`	no	`MCP_PUBLIC_URL`	Override expected JWT `aud` claim
`MCP_OAUTH_JWKS_URL`	no	OIDC-discovered	Override JWKS URL (skips OIDC discovery)
`MCP_OAUTH_REQUIRED_SCOPES`	no	—	Comma-separated scopes required on every request
`LOG_LEVEL`	no	`info`	pino log level: `trace` / `debug` / `info` / `warn` / `error` / `fatal`. All logs go to stderr.

Copy .env.example to .env and fill in real values. Never commit .env.

Quick start — Docker (HTTP)

cp .env.example .env
# edit .env with your AMP credentials
docker compose up -d --build
docker compose logs -f

The server listens on http://127.0.0.1:3000/mcp (stateless Streamable HTTP transport). The compose file publishes the port to host loopback only; to expose it externally, set MCP_BIND=0.0.0.0 in .env and enable auth (MCP_AUTH_MODE=bearer/oauth) or set MCP_ALLOWED_HOSTS — the server refuses to start in 0.0.0.0 + no-auth + no-allowlist mode unless MCP_ALLOW_INSECURE=true.

Smoke check:

curl -X POST http://127.0.0.1:3000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

The HTTP transport also exposes GET /health (returns {"status":"ok"}) for Docker/k8s liveness probes — bypasses auth, rate limiting, and origin checks. The Dockerfile has a built-in HEALTHCHECK that hits this endpoint.

Quick start — local Node (stdio or HTTP)

Requires Node 20+.

npm install
npm run build

# stdio (for an MCP client to spawn as a subprocess)
AMP_URL=... AMP_USERNAME=... AMP_PASSWORD=... npm start

# HTTP (local)
MCP_TRANSPORT=http AMP_URL=... AMP_USERNAME=... AMP_PASSWORD=... npm start

Inspect tools interactively:

npx @modelcontextprotocol/inspector node dist/index.js

Authentication

The HTTP transport supports three auth modes, selected by MCP_AUTH_MODE. stdio transport ignores all of these — its trust boundary is the OS process, and your MCP client passes credentials via the env block in its config.

Mode	When to use	What it does
`none` (default)	stdio, or HTTP bound to `127.0.0.1` / private network only (Tailscale, WireGuard, LAN)	No auth at all. Network-layer trust is the only thing keeping callers out.
`bearer`	Exposing HTTP to one or two clients you control (e.g. a personal cloud VM)	Static `Authorization: Bearer <token>` check. Constant-time compare.
`oauth`	Public/multi-user deployments, or any client that expects spec-compliant MCP auth (e.g. Claude.ai connecting to a remote MCP server)	OAuth 2.1 resource server. Validates JWTs issued by your authorization server. Publishes RFC 9728 Protected Resource Metadata.

These modes are mutually exclusive — pick one. None of them replace AMP_ALLOW_WRITES; that flag still controls whether the write tools are registered at all.

Bearer mode

MCP_AUTH_MODE=bearer
MCP_AUTH_TOKEN=$(openssl rand -hex 32)

Clients call /mcp with Authorization: Bearer <token>. Multiple tokens are accepted as a comma-separated list (one per client, easy revocation by removing the entry and restarting). Missing/invalid tokens get 401 with WWW-Authenticate: Bearer realm="mcp".

curl -X POST http://localhost:3000/mcp \
  -H 'Authorization: Bearer <token>' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

OAuth 2.1 mode

This server acts as an OAuth 2.1 resource server — it validates access tokens but does not issue them. You bring your own authorization server (Keycloak, Auth0, Authentik, Duende, Okta, etc.).

How the pieces fit together

OAuth involves three roles. amp-mcp-server is only one of them:

Resource server — amp-mcp-server itself. Validates incoming JWTs, serves tools. Has no callback URL and never participates in the redirect flow. Lives at MCP_PUBLIC_URL.
Authorization server (AS) — something else you run (Keycloak, Duende, Auth0, Authentik, …). Issues tokens after a user logs in. Lives at MCP_OAUTH_ISSUER.
MCP client — Claude.ai, Claude Desktop, a custom CLI tool, etc. Drives the user-login flow against the AS, receives a token, sends it to the resource server. Each client owns its own redirect/callback URL.

The flow when a user adds your MCP server to a client like Claude.ai:

user
 │
 ▼
MCP client ── (1) fetch PRM ─────► amp-mcp-server   (resource server)
   │           (says "use AS_X")
   │
   │ (2) Auth Code + PKCE ──────► AS   (Keycloak / Duende / etc.)
   │     user logs in + consents
   │     AS redirects to the *client's* callback
   │
   └── (3) bearer JWT ─────────► amp-mcp-server

So the redirect URI you configure at your AS is not https://your-mcp-server/callback — it's whatever URL the client needs. For Claude.ai it's something on claude.ai; for a desktop or CLI tool it's typically a loopback URL like http://127.0.0.1:8765/callback (RFC 8252).

This means a deployment decision:

A few known clients → pre-register each in your AS admin UI (one client entry per consumer, with that consumer's callback URL). Fine if it's just you adding one or two MCP clients.
Many or unknown clients → enable Dynamic Client Registration (RFC 7591) on your AS so clients register themselves at runtime. The MCP Authorization spec recommends DCR for public deployments. Keycloak, Duende, Auth0, and Authentik all support it as an opt-in feature.

amp-mcp-server itself doesn't care which path you pick — it only sees the resulting bearer JWT.

Required env

MCP_AUTH_MODE=oauth
MCP_PUBLIC_URL=https://amp-mcp.example.com   # exact URL clients hit; used as JWT audience
MCP_OAUTH_ISSUER=https://auth.example.com/realms/amp
# Optional:
MCP_OAUTH_REQUIRED_SCOPES=mcp:read,mcp:write

The exact shape of MCP_OAUTH_ISSUER depends on which authorization server you're using — it must match the iss claim that the AS puts in tokens it issues:

AS	Typical issuer URL
Keycloak	`https://auth.example.com/realms/<realm>` (a realm is a Keycloak tenant — its own users/clients/roles)
Duende IdentityServer	`https://auth.example.com` (bare, no path)
Auth0	`https://<tenant>.auth0.com/`
Authentik	`https://authentik.example.com/application/o/<slug>/`
Okta	`https://<org>.okta.com/oauth2/<server-id>`

When in doubt, fetch <issuer>/.well-known/openid-configuration and check the issuer field — that's the canonical value to use here.

The server publishes a Protected Resource Metadata document at:

GET /.well-known/oauth-protected-resource

so that compliant MCP clients can discover the authorization server automatically. On /mcp calls without a valid token, the server returns 401 with:

WWW-Authenticate: Bearer realm="mcp", resource_metadata="https://amp-mcp.example.com/.well-known/oauth-protected-resource"

JWT validation requires:

valid signature (JWKS fetched from the AS)
iss matches MCP_OAUTH_ISSUER
aud includes MCP_OAUTH_AUDIENCE (default: MCP_PUBLIC_URL)
exp is in the future
all MCP_OAUTH_REQUIRED_SCOPES (if set) are present in the scope or scp claim

Important: MCP_PUBLIC_URL must match exactly what clients call. Audience-mismatch is the most common misconfig — if clients get 401s after appearing to authenticate successfully, check that the AS issued the token for this URL.

Quickstart with Keycloak

docker run -d --name kc -p 8080:8080 \
  -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:latest start-dev

In the Keycloak admin UI:

Create a realm (e.g. amp).
Create a client amp-mcp-test, client type OpenID Connect, public, with PKCE; standard flow enabled.
Create a user, set a password.
Add a client scope mcp:read, mapped as a default scope.
Set the client's "Valid post logout redirect URIs" / "Valid redirect URIs" to whatever your MCP client expects (e.g. Claude.ai's callback).

Run amp-mcp-server with:

MCP_TRANSPORT=http \
MCP_AUTH_MODE=oauth \
MCP_PUBLIC_URL=http://localhost:3000 \
MCP_OAUTH_ISSUER=http://localhost:8080/realms/amp \
MCP_OAUTH_AUDIENCE=http://localhost:3000 \
AMP_URL=... AMP_USERNAME=... AMP_PASSWORD=... \
npm start

Verify the PRM endpoint:

curl http://localhost:3000/.well-known/oauth-protected-resource

Verify the 401 challenge:

curl -i -X POST http://localhost:3000/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
# expect: 401 + WWW-Authenticate: Bearer realm="mcp", resource_metadata="..."

For end-to-end testing with the real Auth Code + PKCE browser-login flow (the same flow Claude.ai and other compliant MCP clients use), this repo ships a one-shot helper at scripts/oauth-token.mjs:

# Configure a public client at your AS with redirect_uri http://127.0.0.1:8765/callback,
# PKCE required, and the scope(s) you want. Then:
TOKEN=$(node scripts/oauth-token.mjs \
  --issuer http://localhost:8080/realms/amp \
  --client-id amp-mcp-test \
  --scope "openid mcp:read")
# Open the printed URL in your browser, log in, and the script captures the
# token and prints it to stdout.

curl -X POST http://localhost:3000/mcp \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

For quicker non-interactive checks against a Machine-to-Machine client, you can also use the client_credentials grant directly:

TOKEN=$(curl -s -X POST http://localhost:8080/realms/amp/protocol/openid-connect/token \
  -d 'grant_type=client_credentials' \
  -d 'client_id=<m2m-client-id>' \
  -d 'client_secret=<secret>' \
  -d 'scope=mcp:read' | jq -r .access_token)

Wiring into Claude Desktop

stdio (local Node):

{
  "mcpServers": {
    "amp": {
      "command": "node",
      "args": ["/absolute/path/to/amp-mcp-server/dist/index.js"],
      "env": {
        "AMP_URL": "https://amp.example.local",
        "AMP_USERNAME": "admin",
        "AMP_PASSWORD": "..."
      }
    }
  }
}

HTTP (Docker / remote):

{
  "mcpServers": {
    "amp": { "url": "http://localhost:3000/mcp" }
  }
}

Install as a CubeCoders AMP instance

CubeCoders AMP custom application templates for amp-mcp-server live in a dedicated repo: eddinsw/amp-templates. Two variants are available — host-process (any AMP tier) and Docker (AMP Enterprise + Docker-instances).

Quick install: in the AMP web UI go to Configuration → Instance Deployment → Configuration Repositories, add eddinsw/amp-templates:main, click Fetch Latest. Both amp-mcp-server and amp-mcp-server (Docker) then appear in the New Instance wizard.

The Docker variant pulls ghcr.io/eddinsw/amp-mcp-server:latest, published from this repo by .github/workflows/publish-image.yml on every tag and main push.

Full walkthrough, variant comparison, configuration reference, and troubleshooting: see the amp-templates README.

Production deployment

For exposure beyond your local machine:

Reverse proxy with TLS. Don't put plain HTTP on the public internet. Caddy is the easiest path:
```
amp-mcp.example.com {
    reverse_proxy 127.0.0.1:3000
}
```
Caddy auto-provisions Let's Encrypt. nginx and Traefik work the same way.
Set MCP_TRUST_PROXY. Without it, the rate limiter sees every request as coming from the proxy and locks legitimate clients out at the threshold:
```
MCP_TRUST_PROXY=loopback        # proxy on same host
# or
MCP_TRUST_PROXY=10.0.0.5/32     # CIDR for a specific upstream
```
Pick an auth mode. bearer for one or two known clients; oauth for multi-user or any client that expects spec-compliant MCP auth (e.g. Claude.ai connecting to a remote MCP server).
MCP_PUBLIC_URL must match exactly what clients call (the proxy's external URL with scheme, not the internal Docker URL). Audience-mismatch is the #1 OAuth misconfig.

The Docker image's default MCP_HOST=0.0.0.0 won't start unless MCP_AUTH_MODE is bearer/oauth, MCP_ALLOWED_HOSTS is set, or MCP_ALLOW_INSECURE=true is the explicit override. This is intentional — it prevents accidental public-no-auth deploys.

Troubleshooting

Symptom	Likely cause	Fix
Server exits immediately with `refusing to start: MCP_HOST binds to all interfaces...`	Unsafe-binding safety guard	Set `MCP_AUTH_MODE=bearer`/`oauth`, set `MCP_ALLOWED_HOSTS`, or override with `MCP_ALLOW_INSECURE=true`
OAuth: `401` with token that looks valid	JWT `aud` doesn't match `MCP_OAUTH_AUDIENCE` (or `MCP_PUBLIC_URL` if audience override is unset)	Decode the JWT and check the `aud` array contains the configured audience exactly
OAuth: `401 invalid_token` after a successful login	Token issuer mismatches `MCP_OAUTH_ISSUER`, or AS rotated signing keys and JWKS cache is stale	Verify `MCP_OAUTH_ISSUER` matches the token's `iss`; restart server to flush JWKS cache
All clients get `429` after one client misbehaves	All traffic appearing as one IP because `MCP_TRUST_PROXY` isn't set	Set `MCP_TRUST_PROXY` to the proxy CIDR or `loopback`
Duende: `invalid_scope` even though the scope shows on the client	Scope is in client's allowed-scopes list but isn't defined as an `ApiScope` in IdentityServer	Add it under "API Scopes" + "API Resources", restart Duende to flush config cache
Duende: post-consent redirect bounces back to login	Cookie/SameSite issue on the post-consent redirect	Disable `RequireConsent` on the client as a workaround, or fix Duende's cookie config
`npm test` fails with "no tests" but no errors	vitest cache flake during back-to-back `build` + `test` invocations	Re-run `npm test`

Architecture

MCP client (Claude Desktop / Code)
        │  stdio  ── or ──  HTTP (stateless Streamable)
        ▼
   amp-mcp-server  ── REST/JSON ──▶  AMP install
        │
        └─▶ @neuralnexus/ampapi  (typed AMP client; no transitive deps)

The HTTP transport runs in stateless mode: each request gets a fresh StreamableHTTPServerTransport and McpServer so write-tool gating reflects the current AMP_ALLOW_WRITES value. Auth state on the AmpClient (the AMP session) is shared across requests as a singleton.

License

MIT — see LICENSE.

The bundled AMP client @neuralnexus/ampapi is dual-licensed GPL-3.0 / MIT and is used here under MIT.

Available Tools

8 tools

amp_get_active_usersGet active usersB

List currently connected users / players for one AMP instance. Returns a map of session UID to username.

ParametersJSON Schema

Name	Required	Description	Default
`instanceId`	Yes	Instance UUID, as returned by amp_list_instances

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the tool returns a map of session UID to username, but does not mention any behavioral traits such as authentication needs, rate limits, or side effects. The read-only nature is implied but not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences: the first front-loads the purpose, the second adds return details. No unnecessary words; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description is nearly complete: it explains what the tool does and what it returns. It lacks only minor context like what happens if no users are connected, but overall is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (instanceId well-documented). The description adds no additional parameter semantics; it only describes the output format. Baseline score of 3 is appropriate as the schema already handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the purpose: listing currently connected users/players for an AMP instance. It uses specific verb 'List' and resource 'active users', but does not explicitly differentiate from sibling tools like amp_get_console_output or amp_get_host_status, though the distinct resource makes it distinguishable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites beyond the instanceId parameter. It implicitly requires instanceId from amp_list_instances but does not elaborate on when retrieving active users is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amp_get_console_outputGet console outputA

Read recent console output for one AMP instance. AMP returns whatever buffer is currently held; pass lines to limit to the most recent N entries.

ParametersJSON Schema

Name	Required	Description	Default
`instanceId`	Yes	Instance UUID, as returned by amp_list_instances
`lines`	No	Limit to the most recent N console entries (default: all returned by GetUpdates).

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It explains that AMP returns whatever buffer is currently held, which is a key behavioral trait. It does not mention side effects or error conditions, but for a read-only tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences. The first sentence states the purpose, and the second adds essential usage detail. Every word earns its place, and the structure is front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations or output schema, the description sufficiently covers the tool's behavior, parameter usage, and buffer limitation. It does not describe output format or error handling, but for a simple read operation this is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the baseline is 3. The description adds minimal extra meaning beyond the schema, only repeating that `lines` limits to recent entries. No new semantic information is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Read'), the resource ('recent console output'), and the scope ('for one AMP instance'). It is distinct from sibling tools like amp_get_active_users and amp_get_host_status, which deal with different aspects of AMP instances.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use the tool (to read console output) and how to use the `lines` parameter to limit results. However, it does not explicitly state when not to use it or mention alternative tools for related tasks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amp_get_host_statusGet AMP host statusA

Get state, uptime, and metrics (CPU, RAM) for the AMP controller host machine itself (not a game-server instance).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the tool returns state, uptime, and metrics, indicating a read-only operation. With no annotations provided, this is sufficient transparency for a simple get tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no unnecessary words or repetition. Every part of the description adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter tool returning host metrics, the description covers the key outputs (state, uptime, CPU, RAM). Absence of output schema is compensated by mentioning these fields. Minor gaps like response format or units do not detract significantly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100%, so the description adds no parameter information. Baseline score of 4 applies due to zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves state, uptime, and metrics for the AMP controller host machine. It distinguishes itself from sibling tools like amp_get_instance_status by explicitly saying 'not a game-server instance'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for host-level information via the contrast with game-server instances, but does not provide explicit when-to-use or when-not-to-use guidance beyond that distinction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amp_get_instance_statusGet instance statusA

Get state, uptime, and metrics (CPU, RAM, players) for a single AMP instance. Pass an InstanceID from amp_list_instances.

ParametersJSON Schema

Name	Required	Description	Default
`instanceId`	Yes	Instance UUID, as returned by amp_list_instances

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry burden. It lists returned data but does not explicitly state side-effect-free or error conditions, which is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose, second gives usage hint. No wasted words, front-loaded with key info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool is simple with one required param and no output schema; description covers core function and param source. Missing explicit output structure but listed key fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description adds value by linking instanceId to amp_list_instances, reinforcing correct usage beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves state, uptime, and metrics for a single AMP instance, distinguishing it from siblings like amp_get_host_status and amp_list_instances.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs to pass an InstanceID from amp_list_instances, providing a clear prerequisite. It lacks explicit 'when not to use' but siblings imply alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amp_get_running_tasksGet running tasksA

List currently-running tasks on one AMP instance (backups, updates, etc.) with progress percentage. Useful for polling whether amp_take_backup or amp_update_application has finished.

ParametersJSON Schema

Name	Required	Description	Default
`instanceId`	Yes	Instance UUID, as returned by amp_list_instances

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It implies a read-only operation (listing) and mentions progress reporting, but doesn't disclose potential side effects, error handling, or authentication needs. For a simple list tool, it's adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main action, and no extraneous words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (one param, no output schema), the description covers the purpose, examples, and a use case. It could mention return format or pagination, but it's fairly complete for a list endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description of 'instanceId'. The tool description adds no new semantics beyond the schema. Baseline 3 is appropriate as the schema already documents the parameter well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists running tasks on one AMP instance with progress, and gives concrete examples (backups, updates). It distinguishes from siblings by specifying the resource (running tasks) and providing a use case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says it is useful for polling after backup/update operations, giving a clear when-to-use context. It doesn't explicitly mention when not to use or name alternatives, but the polling use case is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amp_get_update_infoGet application update infoA

Check whether a game-server update is available for one AMP instance. Returns the available version, build, and release notes URL.

ParametersJSON Schema

Name	Required	Description	Default
`instanceId`	Yes	Instance UUID, as returned by amp_list_instances

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It implies read-only behavior ('check') but does not explicitly state it has no side effects or mention authentication needs. The return fields are listed, which is helpful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with the purpose, no redundant words. Information is efficiently packed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 1-parameter tool with no output schema, the description adequately covers purpose, input, and return values. No gaps identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers the sole parameter with a clear description. The tool description does not add significant new semantics beyond what the schema already provides, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Check whether...available') and resource ('game-server update for one AMP instance'). It also lists specific return fields, distinguishing it from siblings like amp_get_instance_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for a single instance but does not provide explicit guidance on when to use this tool over siblings or mention any prerequisites beyond the instanceId.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amp_list_backupsList backupsA

List all local backups for one AMP instance (most-recent first per AMP's ordering). Returns whatever shape AMP's LocalFileBackupPlugin reports.

ParametersJSON Schema

Name	Required	Description	Default
`instanceId`	Yes	Instance UUID, as returned by amp_list_instances

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses ordering (most-recent first) and that response shape depends on AMP's plugin. No annotations provided, but for a read-like list tool, this is transparent. Could mention if it's read-only or requires auth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise, two sentences with no filler. Front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity and good schema coverage, description is mostly complete. Could mention error handling for invalid instanceId or no backups, but not essential for a simple list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already describes instanceId as UUID from amp_list_instances (100% coverage). Description adds no extra meaning beyond referencing the instance. Baseline score appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action (list) and resource (local backups for one AMP instance), and distinguishes from other tools like amp_list_instances. It specifies ordering and return shape.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage when needing backups for a specific instance, but does not explicitly mention when not to use or alternatives like other list tools. Adequate without exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amp_list_instancesList AMP instancesA

Enumerate all instances managed by the AMP controller. Returns InstanceID, name, module type, running state, and parent target for each game-server instance.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It correctly discloses the query nature (enumerate, returns) and specifies the returned fields. However, it does not mention potential rate limits, authentication requirements, or whether the operation is always safe. The description is adequate but could add more behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first sentence states the action and scope, second lists the return fields. No redundant or extra information. Efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description enumerates the return fields sufficiently. For a simple listing tool, this is complete. The sibling tools provide additional context, making the tool's niche clear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description adds no parameter-level detail beyond stating what the tool returns, which is appropriate for a parameterless tool. The schema coverage is 100% (no parameters), so no extra description is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool enumerates instances and lists specific return fields (InstanceID, name, module type, running state, parent target). This provides a specific verb and resource, and implicitly distinguishes from sibling tools that focus on individual instance details or console output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly indicates the tool's purpose (list all instances), but does not explicitly state when not to use it or mention alternatives. Given the sibling tools (e.g., amp_get_instance_status), the context is clear but lacks explicit exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.2.1May 2, 2026
- First observedamp_get_active_users
- First observedamp_get_console_output
- First observedamp_get_host_status
- First observedamp_get_instance_status
- First observedamp_get_running_tasks
- First observedamp_get_update_info
- First observedamp_list_backups
- First observedamp_list_instances

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct resource and action, with no apparent overlap. For example, amp_get_active_users retrieves users, amp_get_console_output reads logs, and amp_get_host_status monitors host metrics, all clearly separate.

Naming Consistency5/5

All tools follow the 'amp_{verb}_{noun}' pattern using lowercase and underscores. 'get_' is used for single resource or status retrieval, and 'list_' for enumerations, ensuring predictable naming.

Tool Count5/5

With 8 tools, the set is well-scoped for an AMP server management context. The tools cover essential monitoring and listing operations without being over or under populated.

Completeness3/5

The set lacks control actions such as starting, stopping, or updating instances, which are typical for a management server. While monitoring tools are decent, the absence of lifecycle operations is a notable gap.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hostinger-api-mcp
io.github.hostinger
MCP server for Hostinger API
Cloud Platforms Developer Tools
1150
server B
io.cycloid.mcp
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
Developer Tools CI/CD & DevOps Cloud Platforms
62
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
mcp AOAuth
com.mux
The official MCP Server for the Mux API
Multimedia Processing Entertainment & Media API Testing
22168

Related MCP Servers

Heim MCP
Cloud Platforms App Automation Developer Tools
Nor2-io
A
license
A
quality
C
maintenance
A MCP server do create and deploy backend applications using https://heim.dev
Updated 5 months ago (2026-03-23 09:31 UTC)
6
18
3
MIT
forgejo-mcp
Version Control Developer Tools
raohwork
A
license
Not graded
quality
D
maintenance
An MCP server for managing your repositories on Forgejo/Gitea server.
Updated 10 months ago (2025-10-28 07:59 UTC)
66
Mozilla Public 2.0
whmcs-mcp-server
App Automation Customer Support E-commerce & Retail
scarecr0w12
A
license
B
quality
B
maintenance
MCP server to help manage a WHMCS installation.
Updated 5 months ago (2026-03-30 20:03 UTC)
62
42
20
MIT
forge-mcp-server
Cloud Platforms Developer Tools CI/CD & DevOps
bretterer
A
license
B
quality
D
maintenance
MCP server for managing Laravel Forge servers, sites, and deployments via the Forge API.
Updated a year ago (2025-06-02 02:45 UTC)
12
1,237
8
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/eddinsw/amp-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server