Skip to main content
Glama

Check the public URL

deployments_check
Read-onlyIdempotent

Request this deployment over its public URL and report what came back. Use it after deploying or fixing a site to confirm it really works - "the logs say it started" is not the same as "the page loads". Returns the HTTP status and the start of the body, so a 500 or a stack trace is visible. Server-rendered output only: no JavaScript runs. Any method: POST a JSON body to test an API route. On a 2xx HTML page it also requests the first same-origin links and assets it finds (links) and names the broken ones and duplicated nav entries in note. It goes through the public URL, the way a visitor does. To hit many routes at once or load-test, one deployments.shell command with a curl loop on localhost:$SERVER_PORT is cheaper than one check per URL. To ask what is wrong with a deployment rather than what one URL returns, call deployments.diagnose instead: it answers this plus the state, the logs and the startup config in one call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "deployments_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
bodyNoRequest body. An object is sent as JSON (Content-Type set for you); a string is sent as is.
pathNoPath to request, e.g. '/' or '/api/scores'. Defaults to '/'.
methodNoDefault GET.
headersNoExtra request headers, e.g. Authorization.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, but the description adds genuinely new context the annotations cannot convey: no JavaScript runs, so only server-rendered output is visible; any HTTP method is allowed including POST bodies to API routes; and on a 2xx HTML page it cascades into first same-origin links/assets, reporting broken links and duplicated nav entries in `note`. It does not say what happens on timeouts, unreachable hosts, or redirect chains, which is the main remaining behavioral gap for a network-calling tool.

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?

Purpose and return values are front-loaded, then caveats, then alternatives, which is the right order for an agent scanning for fitness. It is on the long side (seven sentences) and the final diagnose sentence is dense, but each sentence contributes distinct decision-relevant information rather than restating the schema.

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?

With no output schema, the description does the work of describing returns: HTTP status, start of body, plus the `links` and `note` fields produced by the link crawl. Combined with the explicit 'no JavaScript runs' constraint, an agent knows what it will and will not learn; only request-level failure modes (timeouts, blocked requests) and the meaning of the required `id` are left implicit.

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 80%, so the schema already carries body, path, method and headers semantics, and the description mostly reinforces rather than duplicates ('Any method: POST a JSON body to test an API route'). It does not clarify the one required parameter, `id`, which carries no schema description — 'this deployment' implies it but never states it is a deployment identifier.

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 opens with a concrete verb and resource: 'Request this deployment over its public URL and report what came back,' and immediately frames it as a visitor-equivalent HTTP probe. It explicitly contrasts itself with deployments.diagnose ('what is wrong with a deployment rather than what one URL returns') and deployments.shell (bulk curl loops), so the agent can separate it from siblings without opening a schema.

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?

It states the triggering situation ('after deploying or fixing a site to confirm it really works') with a memorable rationale that logs are not proof of a working page. It names two alternatives and the exact conditions that select them: deployments.shell with a curl loop for many routes or load-testing, and deployments.diagnose when you need state/logs/startup config together.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources