deploy-check
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_pageA | Fetch a URL and report whether it is genuinely working: status, redirect chain, response time, and — the part people miss — how much visible text it actually renders. A page can return 200, weigh half a megabyte and still show a human nothing. Also reports title, meta description, viewport, canonical, og:image and a stray noindex. Use this right after a deploy. |
| check_linksA | Read every link on a page and check each one resolves. Uses HEAD first and falls back to GET for servers that refuse it, so a 405 is not mistaken for a dead link. Capped and rate-limited by default so it stays polite to the sites it touches. |
| compare_pagesA | Check two URLs and report where they differ: status, title, description, canonical, visible text length and byte size. This answers "did my deploy actually land?" — point it at staging and production, or at the same URL before and after a release. If both render identical text, the deploy has not reached the second one. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: one inspects a single page's health, one scans all links on a page, and one compares two URLs. Even where check_page and compare_pages both analyze pages, their roles are separated clearly enough that an agent should not confuse them.
All tool names follow the same lowercase verb_noun pattern: check_page, check_links, compare_pages. The shared 'check' prefix for two tools is appropriate since they share a similar action family, and compare_pages remains consistent in structure.
Three tools is a well-scoped size for a focused deploy-checking server. Each tool covers a distinct real workflow with no redundancy, and the count feels intentional rather than thin or bloated.
The tool set covers the core post-deploy needs: verifying a single page actually renders, checking linked resources, and comparing environments or releases. A minor gap is the lack of a batch or multi-page smoke-test tool, but agents can work around that by calling check_page multiple times.