Skip to main content
Glama

Configure application server routes

configure_application_server_routes
DestructiveIdempotent

Replace the complete hostname-to-local-port route set for a Managed Applications server after reading current routes; submit the full confirmed list and fallback to apply changes.

Instructions

Queue a change of the server routes of one owned Managed Applications server. This REPLACES the COMPLETE set: read get_application_server_routes first, then send the full list of wanted routes and the fallback; a route or fallback that is omitted is removed. Each route sends one customer hostname to 127.0.0.1: on the same server over http or https (ports 1024-65535 except 10080, 10443 and 19090; no host field, upstream is always local; at most 64 routes). The hostname needs verified ownership evidence as well as DNS pointing at the server; pointing DNS alone does not prove ownership. get_application_server_routes reports DNS, per-route state/errors and records to create. Preserve backend refusals, including applicationServerRoutesDeliveredCertificates when delivered certificates prevent enabling routes. Removed hostname claims are not released until the change is applied. The server must have at least one installed managed application. Unknown hostnames are never sent to an application (HTTP 421 / TLS unrecognized_name). Coexistence: if the customer runs their own web server (Caddy, nginx, Traefik) on ports 80/443, either point it at local ports instead, or move it to local ports and declare it as fallback ({http_port?, https_port?}); the fallback receives every hostname the front door does not serve (HTTP proxied with its Host header, HTTPS passed through unterminated). Pass expected_revision from the read; a stale revision is refused with applicationServerRoutesRevisionConflict. Confirm the exact full set with the user first. A queued response (202, action type configure_routes) must be verified by polling get_application_server_routes until state is active. Requires applications:manage and is not a paid API-key operation.

Input Schema

NameRequiredDescriptionDefault
routesYesThe COMPLETE wanted set of routes; omitting a route removes it. An empty array removes all routes.
orderNoYesTenant-owned service order number: 1-64 ASCII letters, digits or hyphens, e.g. VP12345 or VP12345-1
fallbackNoThe customer's own web server on local ports, receiving every hostname the front door does not serve. null or omitted removes the fallback.
confirmedYesTrue only after the user confirmed the complete route set
idempotencyKeyYesClient-global unique key. Reuse it only to replay this exact request; never reuse it for another service or request.
expected_revisionYesCurrent revision returned by get_application_server_routes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.3.19

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds substantial context beyond them: full-replace semantics (omitted routes are removed), the 202 queued response requiring polling via get_application_server_routes, stale-revision refusal with applicationServerRoutesRevisionConflict, ownership-evidence vs DNS-only distinction, and backend refusal codes like applicationServerRoutesDeliveredCertificates. No contradictions.

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

Conciseness4/5

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

Dense but appropriately sized for a destructive multi-constraint mutation, and the critical 'This REPLACES the COMPLETE set' warning is front-loaded. Slightly heavy with nested parentheticals (port lists, coexistence detail) that slow scanning, keeping it just below top marks.

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?

Complete for a complex destructive tool with no output schema: it covers revisioning, idempotency, required confirmation, permissions scope (applications:manage, not paid API-key), prerequisite (at least one installed managed application), and how to verify the async 202 result. Nothing an agent needs to call correctly is missing.

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

Parameters5/5

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

Although schema coverage is 100%, the description meaningfully enriches parameter meaning: routes is a COMPLETE set where omission deletes, fallback receives unserved hostnames (HTTP proxied with Host header, HTTPS passed through unterminated), expected_revision ties to the read tool with a conflict on staleness, and port exclusions (10080, 10443, 19090) and no-host-field constraints are given. Adds real value over the raw 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?

States a specific verb ('Queue a change') and precise resource ('server routes of one owned Managed Applications server'), and explicitly distinguishes itself from get_application_server_routes. An agent immediately knows this is a full-set replacement mutation rather than an incremental edit.

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

Usage Guidelines5/5

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

Explicitly instructs to read get_application_server_routes first, confirm the exact full set with the user before calling, and describes the coexistence scenario (customer web server on 80/443) with two concrete alternatives. When-to-use and prerequisites are fully spelled out.

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

Deploy Server

Other Tools