MorseByte x402 Edge Data Refinery & Quant Gateway

Parallel Citation & Link Auditor

morsebyte_verify_links

Read-onlyIdempotent

Verify up to 20 URLs in parallel for HTTP status, liveness, and latency ($0.005 USDC via x402).

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": {
      "urls": "<urls>"
    },
    "name": "morsebyte_verify_links"
  }
}

Input Schema

Name	Required	Description	Default
`urls`	Yes	1 to 20 public URLs

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026
- changedInput schema / properties / urls / description
```
Previous value: -"Array of 1 to 20 URLs to verify"New value: +"1 to 20 public URLs"
```

Changed8 schema fields changedOct 19, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / urls / description

Previous value: -"Array of 1 to 20 public HTTPS URLs to audit in parallel"New value: +"Array of 1 to 20 URLs to verify"

removedInput schema / properties / urls / items / description
```
Removed value: -"Public HTTPS URL to check"
```
removedInput schema / properties / urls / items / format
```
Removed value: -"uri"
```
removedInput schema / properties / urls / maxItems
```
Removed value: -20
```
removedInput schema / properties / urls / minItems
```
Removed value: -1
```
removedInput schema / properties / urls / title
```
Removed value: -"URLs to Verify"
```

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "alive_count": {
-      "description": "Count of healthy HTTP 200-299 URLs",
-      "type": "number"
-    },
-    "dead_count": {
-      "description": "Count of unreachable or broken URLs",
-      "type": "number"
-    },
-    "provider": {
-      "description": "Service provider name",
-      "type": "string"
-    },
-    "results": {
-      "description": "Per-URL verification results",
-      "items": {
-        "properties": {
-          "alive": {
-            "description": "True if HTTP status is 200-299",
-            "type": "boolean"
-          },
-          "final_url": {
-            "description": "Final URL after following redirects",
-            "nullable": true,
-            "type": "string"
-          },
-          "latency_ms": {
-            "description": "Round-trip verification time in milliseconds",
-            "type": "number"
-          },
-          "status": {
-            "description": "HTTP status code",
-            "type": "number"
-          },
-          "url": {
-            "description": "Original requested URL",
-            "type": "string"
-          }
-        },
-        "required": [
-          "url",
-          "alive",
-          "status",
-          "latency_ms"
-        ],
-        "type": "object"
-      },
-      "type": "array"
-    },
-    "total_checked": {
-      "description": "Total URLs audited in batch",
-      "type": "number"
-    }
-  },
-  "required": [
-    "provider",
-    "total_checked",
-    "alive_count",
-    "dead_count",
-    "results"
-  ],
-  "type": "object"
-}New value: +null

First observedOct 18, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-structured context: parallel execution, the 20-URL ceiling, and the $0.005 USDC cost via x402, which tells the agent about rate/cost constraints. It stops short of explaining the x402 payment flow or auth requirements.

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?

A single sentence front-loads the core action and packs the key facts (limit, parallelism, checks, cost) with no filler.

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 one-parameter tool with no output schema, the description adequately signals what is returned (HTTP status, liveness, latency). It omits failure semantics and the mechanics of the x402 payment requirement, which would matter for an agent orchestrating a paid call.

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 coverage is 100% and the single 'urls' parameter is already documented as '1 to 20 public URLs'. The description's mention of 'up to 20 URLs' merely restates the schema rather than adding new meaning, so baseline 3 applies.

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 description gives a clear verb (Verify) plus resource (URLs) and enumerates the exact checks performed: HTTP status, liveness, and latency. It implicitly distinguishes itself from siblings like morsebyte_content_digest and morsebyte_dom_snapshot, though it never explicitly states how it differs from morsebyte_refine_url, which also operates on URLs.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives such as morsebyte_refine_url or morsebyte_dom_snapshot, nor any prerequisites or exclusions. Usage is only inferable from the verb 'verify'.

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

All MorseByte x402 Edge Data Refinery & Quant Gateway 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?