relayted API

Nostr relay test

relay_check

Read-only

Test a public Nostr relay. mode "quick" (default, 200 Payloads = 0.02 EUR): DNS, TLS, WebSocket, NIP-11, publish/query, latency, stability. mode "conformance" (800 Payloads = 0.08 EUR): NIP-01, filters, event semantics, limits. Returns the JSON report inline (per check: pass, fail, warn, skip, info). A relay can be tested only a few times per hour.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "relay_check"
  }
}

Input Schema

Name	Required	Description
`mode`	No	Test bundle. Default "quick".
`relay`	No	Relay address, e.g. "wss://relay.example.com".
`job_id`	No	Collect the result of an earlier relay_check job instead of starting a new one.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Beyond the supplied annotations it discloses per-mode cost (0.02 EUR / 0.08 EUR, 200/800 payloads), a rate-limit warning, and the inline JSON report shape with its status vocabulary (pass, fail, warn, skip, info). What it leaves unreconciled is that the checks include publishing events to the remote relay, which sits awkwardly beside readOnlyHint=true; the description never clarifies that this external publish is the reason for the hourly cap.

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?

Dense but front-loaded: the verb and resource come first, modes and their check lists follow, and the return shape and rate limit close it out with no filler sentences.

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?

With no output schema, the description steps in to describe the inline report and per-check status values, and it covers cost and rate limits for a paid, rate-limited network tool. The only gap is the missing pointer on how job_id relates to the rate-limit warning for retrieving prior results.

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 100%, so baseline is 3, but the prose meaningfully enriches the enum by explaining what each mode tests and what it costs, which the raw schema does not. It adds nothing for job_id, leaving the schema's "collect an earlier job" wording to carry that parameter alone.

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?

"Test a public Nostr relay" gives a specific verb and resource, and the two modes enumerate exactly what is checked (DNS, TLS, WebSocket, NIP-11, publish/query, latency, stability vs NIP-01, filters, event semantics, limits). An agent immediately knows this is a diagnostic tool against an external relay rather than the balance/markdown/pdf/shot siblings.

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?

The description names the default mode ("quick") and shows what the heavier "conformance" bundle adds, which implicitly tells an agent when the extra spend is warranted, and it warns about the hourly test limit. It stops short of an explicit "use X when you need Y" rule or stating prerequisites for choosing conformance.

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

All relayted API 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?