Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@deploy-check Check if my staging deploy actually updated the homepage."
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.
200 OK is not the same as "it works".
A page can return 200, weigh 41 KB, and show a human absolutely nothing. That is what a JavaScript bundle that threw looks like from the outside. It is also what a deploy that published the wrong directory looks like. And a preview that was checked before publishing will happily tell you everything is fine.
This MCP server gives your agent three read-only tools so it can answer the question you actually have after a deploy: did it work, and does the page show anything?
> check the homepage after my deploy
Up (200, 7166 ms) and rendering 5668 characters of visible text; 1 thing worth a look.
WARN Took 7166 ms to respond.
note No og:image. Links to this page will share without a preview image.> and check staging matches production
Both pages render the same visible text. If you expected a change,
the deploy has not landed here.Needs Node 18 or newer. Nothing else — no account, no API key, no telemetry.
git clone https://github.com/fahmiwol/deploy-check-mcp
cd deploy-check-mcp
npm install
npm test # 21 tests, no network neededClaude Code
claude mcp add deploy-check -- node /full/path/to/deploy-check-mcp/src/server.jsClaude Desktop, Cursor, Windsurf, Codex — add this to your MCP config:
{
"mcpServers": {
"deploy-check": {
"command": "node",
"args": ["/full/path/to/deploy-check-mcp/src/server.js"]
}
}
}Not on npm yet, so there is no
npxone-liner today. When it is published this section will say so; until then the clone above is the install, and it is two commands.
Related MCP server: Argus
All three are read-only. They fetch pages and report; nothing is ever written, posted or
changed. Each is annotated readOnlyHint: true so your agent knows it can use them freely.
check_pageFetch a URL and report whether it is genuinely working.
It tells you | Why you care |
status, redirect chain, response time | a 200 after three hops to another host is not the same as a 200 |
visible text length | the signal nobody checks, and the one that catches a dead render |
| what a browser tab, a search result and a shared link will show |
viewport meta | without it, your page renders at desktop width on every phone |
a stray | the single most expensive line to leave in from staging |
check_linksRead every link on a page and check each one resolves. HEAD first, falling back to GET for the many servers that answer HEAD with 405 or 403 — so a fussy server is never reported as a dead link. Capped and concurrency-limited by default so it stays polite to whatever it touches.
compare_pagesCheck two URLs and report where they differ. This is the "did my deploy actually land?" question: staging against production, or the same URL before and after a release. If both render identical text, you have your answer.
It does not run JavaScript. It reads what the server sends. That is a deliberate limit, not a missing feature — the whole point is to see the page the way a crawler, a link preview and a first-paint visitor see it.
The honest consequence: a healthy single-page app looks the same as a broken one in raw HTML. Both are empty. So blank HTML is only reported as a hard failure when the page loads no scripts at all — because then nothing can ever fill it. When scripts are present you get a warning that says plainly that this tool cannot tell the two apart, and to open a browser.
A tool that called every React app broken would be worth ignoring within a day.
It also does not measure Core Web Vitals, take screenshots, or audit accessibility. Lighthouse does those, well, and needs a real browser to do it.
npm test21 tests, none of which touch the internet. They run against a throwaway HTTP server started inside the test process, including a route that refuses HEAD the way real servers do and a redirect loop that must terminate. Four of them drive the actual server over stdio with the official MCP client, because a server that passes its unit tests and fails to hand-shake is still broken from the user's side.
It collects nothing. There is no account, no API key, no analytics and no telemetry, and no server of ours for anything to be sent to. It makes HTTP requests to exactly the URLs you ask it to check, identifies itself honestly in the user agent, writes no files, keeps no cache and retains nothing after a call returns.
One consequence worth stating plainly: the site you point it at sees a request from your machine, exactly as it would for a browser visit, so do not hand it URLs carrying secrets in the query string.
Full policy: PRIVACY.md · https://fahmiwol.github.io/deploy-check-mcp/privacy.html
MIT. Use it, fork it, ship it inside whatever you like.
Built while shipping things and getting caught by exactly these bugs.
Agent Memory Starter — free, open source. Stop re-explaining your project to every new AI session.
MCP Server Starter — $5. A zero-dependency MCP runtime and mcp-probe, which tests any MCP server, including this one.
Second Brain Kit — $7. One memory for every AI agent you use, served over MCP.
All of them: fahmiwolf.gumroad.com
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page whose links should be checked. | |
| limit | No | Maximum links to check. Default 50. | |
| timeoutMs | No | ||
| concurrency | No | Parallel requests. Default 6. | |
| sameHostOnly | No | Only check links pointing at the same host. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive, and the description adds meaningful behavioral detail: HEAD-first requests with GET fallback so 405s aren't misread, plus default rate limiting to avoid hammering sites. This gives the agent a clear mental model of how requests are made.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words; purpose comes first, then method, then the politeness guarantee. Every sentence adds distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, HTTP method details, and rate limiting, which is sufficient for a read-only link checker with annotations. The only gap is the lack of an explicit description of the output shape, but since there is no output schema, an agent might still be unsure what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema explains limit, concurrency, and sameHostOnly, covering 80% of parameters; the description adds the notion of a 'capped and rate-limited' default, loosely tied to limit/concurrency. It does not elaborate on timeoutMs or give further parameter-specific guidance, so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Read every link on a page and check each one resolves,' which names the exact verb and resource. This clearly separates it from siblings check_page and compare_pages because it targets link resolution rather than single-page or comparative analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to prefer this tool over check_page or compare_pages, nor any mention of situations where link checking is inappropriate. Usage context is only implied by the title and purpose, so the agent gets no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to check, including http:// or https://. localhost works. | |
| timeoutMs | No | Give up after this many milliseconds. Default 15000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds meaningful behavioral context: the tool not only checks HTTP status but also assesses visible text rendering, and warns that a 200 can still be useless. It also lists the extra metadata fields it reports. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it opens with the core action and outcome, then the unique rendering insight, then the output list, and ends with the use case. The parenthetical asides are substantive, not filler. Every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter, read-only tool with no output schema, the description covers the inputs and the key output aspects. It names the specific fields reported (status, redirect chain, response time, visible text, title, meta, viewport, canonical, og:image, noindex). It doesn't specify the exact output format/type, but that is a minor gap for invocation. The deploy use case rounds it out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions: url includes protocol requirement and localhost support, timeoutMs has min/max and default. The description does not add additional parameter-level detail, but the schema already handles that. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Fetch' and resource 'URL' with an explicit goal: determine if a page is genuinely working. Distinguishes itself by focusing on visible text rendering, which is a unique angle versus siblings. The description lists concrete output elements (status, redirect chain, response time, etc.), leaving no ambiguity about the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit timing guidance: 'Use this right after a deploy.' This establishes a clear context for when to invoke. It does not name alternatives or exclusion cases, so not a 5, but the deploy scenario is a strong contextual signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| urlA | Yes | First URL, for example your staging site. | |
| urlB | Yes | Second URL, for example production. | |
| timeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the read-only, idempotent, non-destructive profile. The description adds useful behavioral context by enumerating exactly what is compared and by explaining how to interpret the result. It does not contradict the annotations and does not need to repeat them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: first sentence states the core function, second gives the primary use case, third provides an interpretation rule. Every sentence adds value with no superfluous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only comparison tool, the description covers what the tool does, when to use it, and what output dimensions to expect. It does not mention edge cases like unreachable URLs, but the annotations and simple three-parameter schema reduce the risk of mis-invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents urlA and urlB with examples, and the description reinforces their semantic role as staging/production or before/after. However, timeoutMs is not explained in the description beyond schema constraints, and the description adds limited new parameter-level insight beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Check two URLs and report where they differ') and lists concrete comparison fields such as status, title, canonical, and byte size. The two-URL framing clearly distinguishes this tool from the sibling single-page and link-checking tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit use cases: comparing staging vs production and comparing the same URL before/after release. It also provides an interpretation rule for results ('did my deploy actually land?'), though it does not explicitly mention when to use a sibling tool instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0check_linkscheck_pagecompare_pagesEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Validate HTML/CSS, audit SEO and JSON-LD, check links, and capture responsive screenshots.
Read, screenshot, diff, verify and audit any URL: SEO, links, sitemaps, schema, a11y.
Browser-based QA for AI-built software. Test pages with real browsers via agents.
AI QA tester — real browsers scan sites for bugs, SEO, perf, and accessibility issues via chat.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/fahmiwol/deploy-check-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
