Skip to main content
Glama
Sign In

ScorpTech x402 API

by com.it.scorptech
OverviewDiscussionsAdmin

Text Chunk

text_chunk
Read-onlyIdempotent

Split text into retrieval-ready chunks for RAG and embeddings: recursive (paragraph > line > sentence > clause > word), markdown-aware (splits on headings, keeps the heading path per chunk, respects code fences), sentence, or fixed windows; sized in estimated tokens or characters with overlap. Returns each chunk with Unicode start/end offsets, character and token estimates, plus totals. Deterministic and offline; 200 KB input. Price: $0.005 USDC per successful call (x402, Solana). Same tool over HTTPS: POST https://scorptech.it.com/api/x402/v1/text-chunk

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": {
      "text": "<text>"
    },
    "name": "text_chunk"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesText or Markdown to chunk (max 200 KB)
unitNotokens (default, estimated ~4 chars/token) or chars
overlapNoOverlap between consecutive chunks, at most half of chunk_size (default 10%)
strategyNorecursive (default), markdown, sentence or fixed
chunk_sizeNoMax chunk size in the unit (tokens 16-8192, default 512; chars 64-32768, default 2000)
include_textNoReturn chunk text (default true); false returns offsets only

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds substantial context: deterministic and offline execution, a 200 KB input limit, the returned fields (Unicode offsets, character/token estimates, totals), and pricing via x402 on Solana. This is exactly the kind of behavioral information an agent needs before invoking a paid text-processing endpoint.

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?

The description is dense but front-loaded: purpose and strategies first, then return values, execution properties, limits, and pricing. The first sentence is long and semicolon-heavy, but every clause carries useful information and none is gratuitous.

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?

There is no output schema, so the description carries the burden of explaining returns, and it does: chunks include Unicode start/end offsets, character and token estimates, plus totals. Combined with strategy, sizing, overlap, limit, and pricing details, an agent has enough information to invoke the tool correctly.

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 the baseline is 3; however, the description adds meaning beyond the schema by specifying the recursive fallback order (paragraph > line > sentence > clause > word), explaining markdown heading-path retention and code-fence respect, and noting that include_text=false returns offsets only. These details help the agent choose parameter values rather than merely restating the schema.

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?

The description states a specific verb and resource (split text into retrieval-ready chunks) and enumerates the exact strategies: recursive, markdown-aware, sentence, and fixed windows. This is far more specific than the title or name alone and clearly distinguishes it from sibling text tools such as text_stats, text_diff, and html_to_markdown.

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 clear context for when this tool is appropriate: preparing RAG and embedding inputs, with sizing in tokens or characters and optional overlap. It does not explicitly name when not to use it or point to alternative tools (e.g., readability_extract or html_to_markdown for preprocessing), so it falls short of full alternative routing.

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

All ScorpTech x402 API 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