Skip to main content
Glama
Sign In

MorseByte x402 Edge Data Refinery & Quant Gateway

by io.github.Ceejaythenerd
OverviewDiscussionsAdmin

Web Data Refinery

morsebyte_refine_url
Read-onlyIdempotent

Fetch any public URL and extract clean, token-efficient prose ($0.015 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": {
      "url": "<url>"
    },
    "name": "morsebyte_refine_url"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesPublic HTTP/HTTPS URL to scrape and refine

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / url / description
      Previous value: -"Public HTTPS URL to scrape and refine"New value: +"Public HTTP/HTTPS URL to scrape and refine"
  2. Changed5 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / url / description
      Previous value: -"Full public HTTPS URL to scrape and refine into clean text (e.g. https://example.com)"New value: +"Public HTTPS URL to scrape and refine"
    • removedInput schema / properties / url / format
      Removed value: -"uri"
    • removedInput schema / properties / url / title
      Removed value: -"Target URL"
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "char_count": {
-      "description": "Character count of refined prose",
-      "type": "number"
-    },
-    "content": {
-      "description": "Cleaned LLM-ready text content",
-      "type": "string"
-    },
-    "http_status": {
-      "description": "HTTP status code returned by target URL",
-      "type": "number"
-    },
-    "latency_ms": {
-      "description": "Edge extraction latency in milliseconds",
-      "type": "number"
-    },
-    "provider": {
-      "description": "Service provider name",
-      "type": "string"
-    },
-    "source_url": {
-      "description": "Scraped source URL",
-      "type": "string"
-    },
-    "title": {
-      "description": "Extracted webpage title",
-      "nullable": true,
-      "type": "string"
-    }
-  },
-  "required": [
-    "provider",
-    "source_url",
-    "http_status",
-    "char_count",
-    "content"
-  ],
-  "type": "object"
-}New value: +null
  3. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely new behavioral context: the $0.015 USDC x402 payment requirement, which the agent cannot learn from any structured field. It still omits error/rate-limit behavior and how non-public or paywalled pages are handled.

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 with the core action front-loaded and the cost appended, no filler or restatement of the name/title. Every clause earns its place.

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 read-only tool with no output schema, the description conveys action, scope, output character ('clean, token-efficient prose'), and the payment gate. Return shape and payment failure behavior remain unspecified, which slightly limits it, but the essential call-time context is present.

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?

Only one parameter and schema coverage is 100%, so the schema fully documents the 'url' string. The description adds nothing about URL format, redirect handling, or any per-URL constraints beyond 'public', so the 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?

States a specific verb and resource: 'Fetch any public URL and extract clean, token-efficient prose.' The prose-extraction framing implicitly distinguishes it from extract_json/dom_snapshot siblings, but no sibling is named, so an agent must infer the boundary rather than being told it.

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 when-to-use or when-not-to-use guidance. With siblings like morsebyte_extract_json and morsebyte_content_digest doing overlapping URL-fetch work, the description never explains which one an agent should pick or under what conditions. The only scope hint is 'any public URL'.

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 toolsInspect
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