upkeep-mcp

Site reachability and headers

uptime_check

Read-onlyIdempotent

Check whether a page is up and how it responds: status code, load time, redirect chain, HTTPS upgrade, and security headers. Run it when a client reports a site down or slow.

Instructions

Requests a page and reports whether it answered, how long it took, the full redirect chain it went through, whether plain HTTP is upgraded to HTTPS, and which security headers came back.

Use it to answer "is this site up?", "why does this URL take four redirects to load?", "does http:// still work and should it?" or "does this site send HSTS?". It is the check to run when a client reports that a page is down or slow.

Do not use it to inspect a certificate — that is ssl_check — or for registration and DNS, which is domain_check. It fetches one page, not a whole site: use seo_audit for crawling.

Redirects are followed one hop at a time so the whole chain is visible, up to ten hops. Response time is wall clock to the first response headers and includes DNS, TCP and TLS setup, so it is not a measure of server processing time.

Status codes are graded rather than lumped together: 5xx, 404 and 410 are critical, 401 and 403 are a warning because they are normal for a staging site, and 429 is reported as unknown because a throttled check establishes nothing about real availability. Returns findings ordered by urgency, worst first.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	The page to request, e.g. "https://example.com". A bare domain such as "example.com" is accepted and tried over HTTPS. Include the path when a specific page matters; the homepage is checked otherwise.

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	The URL that was requested first.
`hsts`	Yes	The HSTS policy, read from the HTTPS response only.
`https`	Yes	Whether visitors arriving over plain HTTP are moved to HTTPS.
`status`	Yes	Status code at the end of the redirect chain.
`finalUrl`	Yes	Where the redirect chain ended.
`findings`	Yes	What needs attention, worst first.
`severity`	Yes	How much attention this needs. "critical" means act now; "warning" means act this month; "unknown" means the check could not establish the fact, which is not the same as it being fine.
`checkedAt`	Yes	When the check ran, ISO 8601 in UTC.
`reachable`	Yes	Whether the server answered at all.
`redirects`	Yes	The redirect chain, followed manually one hop at a time.
`responseTimeMs`	Yes	Wall-clock milliseconds to the first response headers. Includes DNS, TCP and TLS setup, so it is not server processing time.
`securityHeaders`	Yes	Security-relevant response headers.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly, idempotent, non-destructive), so the description carries the real behavioral burden and does so richly: redirects followed one hop at a time up to ten hops, timing measured as wall clock to first response headers inclusive of DNS/TCP/TLS, and status-code grading with the rationale for 429 being 'unknown'. This is well beyond what structured fields disclose.

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?

Front-loaded with purpose, then usage, then exclusions, then behavioral detail. Despite its length, each paragraph maps to a distinct decision the caller must make, and nothing is redundant padding.

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?

An output schema exists, so return values need not be restated. Combined with explicit routing to siblings, coverage of redirect/timing semantics, and status-code grading, an agent has everything needed to invoke this correctly.

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% and the single url parameter is fully documented in the schema (bare domain, path handling, homepage fallback). The description adds only the scoping nuance that it fetches one page rather than a whole site, so the baseline 3 applies with little added meaning.

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 and resource ('requests a page') and enumerates exactly what it reports: reachability, timing, redirect chain, HTTP→HTTPS upgrade, and security headers. It explicitly distinguishes itself from siblings ssl_check, domain_check, and seo_audit, so an agent can route without opening another 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?

Gives concrete triggering questions ('is this site up?', 'why does this URL take four redirects?', 'does this site send HSTS?') plus the operational context (run it when a client reports a page is down or slow). It also states explicit exclusions: not for certificates (ssl_check), not for DNS/registration (domain_check), not for whole-site crawling (seo_audit).

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

Deploy Server