agent-health

diagnose_http

Read-only

Check whether the task's public endpoint is reachable and explain what failed. First call: {"url":"https://YOUR-TARGET.example/health","evidence_pack":true}. Replace the example URL with the actual target. No account or key is required. Checks DNS, TCP, verified TLS and HTTP HEAD. Report finding and suggested_action. Only ports 80/443, no credentials/query strings/fragments or redirects. Default uses HEAD. Optional surface_scan=true requires surface_authorized=true: only hosts you operate or may test. Public scope GETs the root, discovery docs and linked JS. Verified scope also probes config files and sourcemaps: supply agent_id and its owner api_key with current DNS verification of that hostname. At most 15 URLs, 256 KiB each, 2 MiB total and 6.5 seconds extra. No remote tools or credentials sent to the target. Returns categories, confidence, remediation and coverage, never matched values, fragments, snippets or dynamic paths. Findings are candidates; no_findings is not a security certificate. Surface scans are point-in-time, unsigned and share the same quota; not available in scheduled watches. evidence_pack=true adds a compact unsigned verdict, finding, observations, confidence basis and next step; omits the echoed URL path. Returns cause, evidence and suggested_action. 10 attempts per IP per 24h; honor Retry-After. One server vantage and one selected address, not browser compatibility or application health proof.

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": {
      "url": "<url>"
    },
    "name": "diagnose_http"
  }
}

Input Schema

Name	Required	Default
`url`	Yes
`api_key`	No
`agent_id`	No
`surface_scan`	No
`evidence_pack`	No
`surface_scope`	No	public
`surface_authorized`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 4, 2026

addedInput schema / properties / evidence_pack

Added value: +{
+  "default": false,
+  "title": "Evidence Pack",
+  "type": "boolean"
+}

Changed5 schema fields changedOct 23, 2026

addedInput schema / properties / agent_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Agent Id"
+}

addedInput schema / properties / api_key

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Api Key"
+}

addedInput schema / properties / surface_authorized

Added value: +{
+  "default": false,
+  "title": "Surface Authorized",
+  "type": "boolean"
+}

addedInput schema / properties / surface_scan

Added value: +{
+  "default": false,
+  "title": "Surface Scan",
+  "type": "boolean"
+}

addedInput schema / properties / surface_scope

Added value: +{
+  "default": "public",
+  "title": "Surface Scope",
+  "type": "string"
+}

AddedOct 1, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already establish a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description still adds substantial behavior: a hard 10-attempts-per-IP-per-24h quota with Retry-After handling, port restrictions to 80/443, bans on credentials/query strings/fragments/redirects, and the authorization precondition for active scanning. It also discloses limits an agent could otherwise misread as guarantees: point-in-time, unsigned, single vantage point, no_findings is not a security certificate, and no matched values or dynamic paths are returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and example call are correctly front-loaded, but the body is a dense wall of sentences that hops between quotas, scope rules, size limits, output contents and disclaimers without grouping. There is also redundancy: 'Report finding and suggested_action' and 'Returns cause, evidence and suggested_action' say the same thing, and the return contents are restated for both normal and evidence_pack modes.

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?

For a 7-parameter tool with zero schema descriptions, the description covers the operational essentials: prerequisites, authorization, quota, size and time caps, and scope caveats. An output schema exists, so the repeated explanations of returned fields (categories, confidence, remediation, coverage) are extra rather than necessary, but nothing an agent needs in order to call it correctly appears to be absent.

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 description coverage is 0% across 7 parameters, so the description must carry the load, and it does: it explains url with an example, evidence_pack's added payload and what it omits, the surface_scan/surface_authorized dependency, the public vs verified meaning of surface_scope, and the agent_id plus api_key requirement for verified scope. All seven parameters receive at least some meaning, though the coupling between api_key/agent_id and scope is stated in prose rather than tied explicitly to each field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource: check whether the task's public endpoint is reachable and explain what failed, then enumerates the exact checks (DNS, TCP, verified TLS, HTTP HEAD). That is far more precise than the name alone. It never names diagnose_mcp or any other sibling as the contrasting option, so the differentiation is left to the reader inferring 'HTTP vs MCP' from the tool name.

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?

It gives a concrete first-call example, tells the caller to replace the placeholder URL, states no account or key is required, and spells out the conditions that gate surface_scan (requires surface_authorized) and verified scope (agent_id plus owner api_key with current DNS verification). What is missing is any explicit routing guidance against alternatives, e.g. when to prefer diagnose_mcp or agent_endpoint_assessment instead.

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

All agent-health tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?