Genesis402

Summarize text

genesis402_summarize

Summarize provided long text (reports, transcripts, filings, threads) into a paragraph, bullet list, or one-line TL;DR with a word limit. Paid per call, returns JSON.

Instructions

Paid ($0.006 USDC). Summarize long text you already have (a report, transcript, filing, thread) as a paragraph, bullet list or one-line TL;DR, within a word limit, on UnyKorn's own GPU. Use when the text is in hand; to summarize a live web page by URL instead, call the summarize-url endpoint through genesis402_call. To answer one specific question from the text use genesis402_answer_from_text. Returns the summary in the requested style as JSON. Works only from the supplied text. Payment: call once without payment_signature to get the exact price quote (nothing is charged or signed), then call again with the signed payment to receive the result and settlement details.

Input Schema

TableJSON Schema

Name	Required	Description
`text`	Yes	The text to summarize, up to 24,000 characters. Trim longer input first.
`style`	No	Output shape: 'paragraph' (default), 'bullets' for a bullet list, or 'tldr' for one or two sentences.
`max_words`	No	Upper bound on summary length in words, 20 to 400. Defaults to 120.
`payment_signature`	No	Optional. An x402 v2 payment you signed for this call's quote (the PAYMENT-SIGNATURE header value). Omit to get the price quote first; nothing is charged without it.

Output Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes	QUOTE_ONLY: price quote only, nothing signed or charged. PAID: the call was paid and result holds the data. FREE: the endpoint answered without payment.
`paid`	Yes	true only when a payment was settled for this call.
`price`	No	The Base USDC quote. Present on QUOTE_ONLY and on PAID calls made by a local payer; null when the rail offered no Base USDC lane or the caller signed the payment.
`result`	No	PAID or FREE: the endpoint's JSON result.
`resource`	No	QUOTE_ONLY: the full URL of the paid resource.
`how_to_pay`	No	QUOTE_ONLY: how to sign and resend the call.
`settlement`	No	PAID: decoded PAYMENT-RESPONSE settlement (transaction hash, network, payer), or null if the rail sent none.
`what_you_get`	No	QUOTE_ONLY: the rail's description of what the payment buys.
`payment_required_b64`	No	QUOTE_ONLY: the raw base64 PAYMENT-REQUIRED header, to sign with any x402 v2 client.
`also_accepted_networks`	No	QUOTE_ONLY: every network the 402 challenge accepts.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.6Oct 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the sparse annotations, disclosing the paid price ($0.006 USDC), the quote-then-sign payment dance, that nothing is charged on the first call, that it works only from supplied text, and that it runs on the provider's own GPU. This is the kind of behavioral context annotations do not carry.

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?

Front-loads the price and core action, then routes and payment mechanics. Dense and every sentence carries information, though it runs long enough that the routing and payment instructions compete for attention.

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?

An output schema exists, so return values need not be explained, yet the description still notes JSON output. For a paid, single-shot transformation tool, purpose, routing, constraints and payment flow are all covered.

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 parameters are already documented; the description reinforces the style options and the word limit and clarifies the payment_signature omission semantics. It adds marginal but real meaning over the schema baseline.

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?

States a specific verb and resource (summarize supplied text) plus the output modes, and explicitly differentiates from the URL-summarization path and the question-answering sibling. An agent can route correctly without opening the schema.

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

Usage Guidelines5/5

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

Explicitly says when to use it ('when the text is in hand') and names both alternatives: summarize-url via genesis402_call and genesis402_answer_from_text for a single question. The two-step payment precondition is also spelled out.

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