Skip to main content
Glama

mcp-liveness

by io.github.agentwares
OverviewDiscussionsAdmin

Can a stock client use this MCP server?

mcp_liveness_check
Read-only

Makes one handshake with an MCP server's endpoint — server/discover at protocol revision 2026-07-28, then initialize for a server on the older revision — with no credential, and reports what a stock client gets. The server is named either by its exact official-registry name, or by its endpoint url when it is not in the registry or is listed under another name; exactly one of the two is accepted.

Outcomes: usable (it connected and negotiated a protocol version), needs_credential (401 or 403 — by name, the answer also says whether a credential can be obtained in-band or whether a person has to create one), charged (402, access is for sale), unreachable (not an MCP server there: wrong URL, dead host, or a 200 that is not JSON-RPC), and, for a name only, local_only (no remote endpoint; it must be spawned as a process) and not_listed (no server with that exact name; its endpoint can still be checked by url).

A url must be public https: private, loopback, link-local, multicast and cloud-metadata addresses are refused, redirects are re-checked, and URL checks are limited to 30 a minute per caller. Useful before relying on a server: roughly two in five remote registry listings do not answer a stock client.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoThe server's Streamable HTTP endpoint, e.g. `https://example.com/mcp`, for a server that is not in the registry or is named differently there. Public https only. Pass this or `name`, not both.
nameNoThe server's exact name in the official MCP registry, namespaced — e.g. `io.github.owner/server`. Not a title. Pass this or `url`, not both.
skipCredentialCheckNoName checks only: skip the OAuth discovery chain on a 401. Faster (one request instead of up to five) but the answer then cannot say whether a credential is obtainable. A URL check never walks the chain.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / name / description
      Previous value: -"Exact registry name, namespaced — e.g. `io.github.owner/server`. Not a URL and not a title."New value: +"The server's exact name in the official MCP registry, namespaced — e.g. `io.github.owner/server`. Not a title. Pass this or `url`, not both."
    • changedInput schema / properties / skipCredentialCheck / description
      Previous value: -"Skip the OAuth discovery chain on a 401. Faster (one request instead of up to five) but the answer then cannot say whether a credential is obtainable."New value: +"Name checks only: skip the OAuth discovery chain on a 401. Faster (one request instead of up to five) but the answer then cannot say whether a credential is obtainable. A URL check never walks the chain."
    • addedInput schema / properties / url
      Added value: +{
+  "description": "The server's Streamable HTTP endpoint, e.g. `https://example.com/mcp`, for a server that is not in the registry or is named differently there. Public https only. Pass this or `name`, not both.",
+  "maxLength": 2048,
+  "minLength": 1,
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "name"
-]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the credential-free handshake, the full outcome taxonomy (usable/needs_credential/charged/unreachable/local_only/not_listed), SSRF guards (private, loopback, link-local, multicast, cloud-metadata refused; redirects re-checked), and a concrete rate limit of 30 URL checks per minute per caller. It also supplies a base rate ('roughly two in five remote registry listings do not answer'), which no structured field conveys.

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?

Front-loaded with the core behavior, then scoped to outcomes, then constraints; no filler sentences. It is longer than typical but each block carries distinct operational information, with only mild redundancy between the outcome list and the parameter notes.

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?

With no output schema, the description carries the return burden and does so by enumerating every outcome string and what each implies. Combined with zero required parameters and public-https restrictions, an agent has everything needed to call this and interpret the result.

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 already 100%, so the baseline is 3, but the description adds real semantics: that exactly one of name/url is accepted, that skipCredentialCheck applies to name checks only and changes what the answer can report (one request instead of up to five), and that URL checks never walk the OAuth chain.

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 (makes one handshake) against a specific resource (an MCP server's endpoint) and names the exact protocol calls used (`server/discover`, `initialize`). The 'with no credential' framing implicitly separates it from the credential-oriented sibling mcp_liveness_check_auth, so an agent can route between them.

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

Usage Guidelines4/5

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

Gives clear context ('Useful before relying on a server') and the selection rule for the two mutually exclusive parameters (name for registry entries, url for unregistered or differently-named servers). It does not explicitly say when to prefer the sibling tools mcp_liveness_check_apps, _auth, or _drift, so routing against those is left to inference.

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

All mcp-liveness toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources