Pay-per-call AI & Blockchain APIs for AI agents, settled in Kaspa (KAS). No account, API key, or credit card required — agents prepay with KAS and calls are metered against the balance.
Session & Payment Management (free)
catalog — Browse all available services and their live KAS/USD prices
open_session — Create a payment session and get a personal Kaspa deposit address
session_status — Check current balance, deposits, and spending
Text Processing
summarize — Summarize text or a public URL to a specified word count (~$0.001)
extract — Extract structured JSON from text using schema-constrained decoding (~$0.0015)
rewrite — Rewrite text for tone, format, or length (~$0.001)
classify — Classify text into 2–32 labels, single or multi-label (~$0.0003)
Web & Embeddings
read_url — Fetch a public webpage as clean markdown, optionally with key-fact bullets (~$0.0012)
embed_text — Generate 768-dim embeddings for up to 64 texts (~$0.0003)
search_index — Store documents in a named collection for semantic search (~$0.0015)
search_query — Semantically query an indexed collection, returning top-k matches (~$0.0003)
Kaspa Blockchain Data
kaspa_balance — Get balance of any Kaspa mainnet address (~$0.00015)
kaspa_utxos — Retrieve the UTXO set for a Kaspa address (~$0.0003)
kaspa_tx_status — Check mempool status of a transaction (~$0.00015)
kaspa_fee_estimate — Get current feerate buckets for Kaspa mainnet (~$0.00015)
kaspa_network — Get network stats: DAA score, block count, difficulty, sync state (~$0.00015)
GPU Language Model Generation
generate — Run prompts on GPU model tiers (~$0.0015–$0.004):
chat — Fast 7B model
reason — 35B reasoning model
code — Code-specialized model
kaspa-expert — RAG-grounded Kaspa knowledge model
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@k402-mcp Check Kaspa network status and summarize https://kaspa.org"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives any agent (Claude Code, Claude Desktop, agent SDKs) a catalog of agent-payable APIs: text tools (summarize, schema-guaranteed extraction, classify, rewrite), web reading, embeddings + semantic search, live Kaspa mainnet chain data, GPU model tiers, covenants-as-a-service (compile/derive/inspect/build/check/broadcast Silverscript covenants), and RISC Zero attestation-as-a-service (upload a guest, preflight for a cycle-exact quote, prove, verify). No account, no card, no API key — the agent opens a session, gets a personal KAS deposit address, and every call meters against the prepaid balance. Prices are USD-pegged, fractions of a cent per call, settled on Kaspa L1 (sub-second, ~zero fees).
The payment loop is agent-native: an unfunded call returns instructions ("send KAS to this address, this call costs X"), so an agent can discover the service, learn how to pay, and use it autonomously — the x402 idea, on Kaspa.
The same server runs hosted at the public gateway (streamable HTTP):
https://x402-compute.68cxgfyr0.workers.dev/mcpClaude Code:
claude mcp add --transport http k402 https://x402-compute.68cxgfyr0.workers.dev/mcpHosted sessions are per-connection: open_session binds the payment session to your MCP
connection and returns the key — save it, and re-attach with use_session(<key>) after a
reconnect. Nothing is shared between connections.
Related MCP server: x402engine-mcp
pip install k402-mcpClaude Code:
claude mcp add k402 -- k402-mcpClaude Desktop / generic MCP config:
{ "mcpServers": { "k402": { "command": "k402-mcp" } } }Env (all optional): K402_GATEWAY (defaults to the public gateway), K402_SESSION (pin a funded
session key), K402_STATE (where the auto-opened session persists, default ~/.k402/session.json).
catalog — see every service and its live KAS/USD price (free)
open_session — get a session + personal Kaspa mainnet deposit address (free); fund it from
any wallet (min 0.25 KAS — confirmed in seconds)
Call anything: summarize, extract, classify, rewrite, read_url, embed_text,
search_index/search_query, kaspa_balance, kaspa_utxos, kaspa_tx_status,
kaspa_fee_estimate, kaspa_network, generate (tiers: chat / llama / reason / think / code / kaspa-expert),
covenant_compile/covenant_address/covenant_utxos/covenant_build/covenant_check/covenant_broadcast,
prove_guest_upload/prove_preflight/prove_submit/job_status/job_result/attest_verify,
payment_options, pay_per_call
session_status — watch the balance draw down (free)
New here? Start with open_session — one funded deposit address, and every call meters
against it. That's the whole loop. The other schemes (per-call coins, or trustless payment
channels) are for when you want them; payment_options explains each.
kaspa-channel)Where the gateway offers it, channel_config/channel_status expose a covenant payment channel:
your KAS sits in a Kaspa L1 covenant (not the merchant's wallet), and you pay per call with signed
vouchers — the merchant can only ever claim what you signed, and you reclaim the rest. Opening and
funding a channel needs your Kaspa key, so that part runs in the k402
Python client (k402.channel); these MCP tools cover discovery and status.
Example, in Claude Code after claude mcp add:
"Use the k402 tools to check the current Kaspa network status and summarize https://kaspa.org"
The first call returns how-to-pay instructions; fund the deposit address it gives you and retry.
Prototype. Payments settle either custodial-prepaid (sessions) or trustlessly via
kaspa-channel covenant payment channels (live on mainnet, covenant unaudited — channel sizes
are capped). Keep balances small: a few KAS covers thousands of calls.
Paid tools return payment_required + instructions instead of failing opaquely.
The gateway rate-limits per IP; prices float with KAS/USD, so catalog shows current numbers.
Need KAS? Any exchange or wallet works — deposits are plain mainnet transfers.
mcp-name: io.github.Kali123411/k402
MIT © Kaspa Lab
List every service this gateway sells (text tools, Kaspa chain data, LLM tiers) with live prices in KAS and USD. Free. Start here to see what's available and what calls cost.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds value by stating 'Free' and 'live prices', indicating no cost and real-time data. Does not mention auth or side effects, but for a read-only listing this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the main action 'List every service'. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains what is returned (list of services with prices in KAS and USD). Also clarifies it's free and a starting point. Fully complete for a simple catalog tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema, so description cannot add parameter semantics beyond what schema provides. Baseline 4 for 0 params, but description adds context about output content (services, prices in KAS/USD), earning a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists all services with live prices, using specific verb 'List every service'. Distinct from sibling tools that perform different functions like classify, embed, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Start here' to discover what's available and costs, providing clear usage context. No explicit when-not-to-use, but the guidance is sufficient for a catalog tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify text into one (or multiple, if multi=true) of 2-32 labels; the result is constrained to your label set. Paid (~$0.0003 in KAS).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| multi | No | ||
| labels | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the tool is paid ($0.0003 KAS) and that results are constrained to the label set. However, it does not cover authentication, rate limits, or other behavioral traits like speed or data handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loading the core action and key constraints. It includes cost information efficiently. Slightly more structured formatting could help, but it is concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple classification tool with no output schema, the description covers the main purpose and key parameters. However, it lacks details on the return format (e.g., single string or array) and any limitations (e.g., maximum text length). This is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 0%, the description adds value by clarifying that 'multi=true' enables multiple labels and that labels must be between 2 and 32 items. This goes beyond the schema which only provides types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool classifies text into labels, with a constraint to the provided label set. It specifies input range (2-32 labels) and optional multi-label. This distinguishes it from sibling tools like 'extract' or 'summarize' which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for text classification) but does not explicitly mention when not to use or provide alternatives among siblings. No exclusions or context for choosing over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Embed up to 64 texts (768-dim vectors, nomic-embed-text). Paid (~$0.0003 in KAS).
| Name | Required | Description | Default |
|---|---|---|---|
| texts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries the burden. It discloses paid cost (~$0.0003 in KAS) and a limit of 64 texts. However, it does not mention that the operation is stateless, read-only, or any side effects, which is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff, covering key aspects: action, limit, model, dimensions, cost. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers purpose, limit, model, and cost. Missing return format (e.g., 2D array of floats) but otherwise complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by specifying the limit (up to 64 texts) and the output characteristics (768-dim, nomic-embed-text). It does not describe input constraints like text length or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'embed' and resource 'texts', with details about dimensionality (768-dim) and model (nomic-embed-text). This distinguishes it from sibling tools like classify or generate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for embedding text with a limit of 64 texts and a cost, but no explicit when-to-use or alternatives among siblings. The paid nature is a usage hint but not comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured data from text as JSON guaranteed to match your JSON schema (schema-constrained decoding, not best-effort). Paid (~$0.0015 in KAS).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| schema | Yes | ||
| instruction | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses cost and guarantee of schema matching, but does not address error handling, failure modes, or behavior on invalid schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is front-loaded with the core action and constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and a paid tool, the description is too minimal. It does not explain what is returned (beyond 'as JSON'), how to use the instruction parameter, or provide examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It explains 'text' and 'schema' implicitly via its purpose, but fails to mention the 'instruction' parameter, leaving it undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (extract structured data from text), the key property (JSON guaranteed to match schema), and distinguishes from best-effort extraction. It is specific and differentiates from sibling tools like generate or classify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'schema-constrained decoding, not best-effort', implying when to use it (when schema compliance is required), but lacks explicit guidance on when not to use it or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a prompt on a GPU model tier: 'chat' (fast 7B, ~$0.0015), 'reason' (35B, ~$0.004), 'code' (coder model, ~$0.0025), or 'kaspa-expert' (RAG-grounded, current Kaspa knowledge, ~$0.0015). Returns the completion text.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | chat | |
| prompt | Yes | ||
| system | No | ||
| max_tokens | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the action (run prompt on GPU tiers) and output (returns completion text). With no annotations, it provides basic transparency but omits details like statelessness, logging, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded action and return value. Concise and efficient, though adding parameter details could improve without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks parameter explanations, output format details, and usage context relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. Only 'tier' is partially explained with four options; 'prompt', 'system', and 'max_tokens' are not described. Major gaps remain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Run a prompt on a GPU model tier' and lists the specific tiers with costs. It distinguishes from sibling tools like 'classify' and 'summarize' by focusing on generative completion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'classify' or 'extract'. The description implies usage for text generation but does not help the agent choose among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Balance of any Kaspa MAINNET address, straight from a node (no indexer, no API key). Paid (~$0.00015 in KAS).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Implicitly indicates a read-only operation by describing balance query. Adds cost detail (~$0.00015). No annotations provided, so description carries burden but adequately conveys non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no extraneous text, front-loaded with the core purpose. Each part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description covers key aspects: network, source, cost. Missing return format is minor given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds 'MAINNET' and 'any address' context, clarifying the parameter's scope beyond the schema's minimal definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns the balance of a Kaspa MAINNET address. Differentiates from sibling tools like kaspa_fee_estimate and kaspa_utxos by specifying direct node query without indexer or API key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for querying Kaspa balance. Notes it is paid and direct from node, but does not explicitly state when not to use or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current Kaspa mainnet feerate buckets (sompi per gram of tx mass). Paid (~$0.00015).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses that the data is current and mentions a cost ('Paid (~$0.00015)'), but does not specify behavioral details like caching, rate limits, or idempotency. This is adequate but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise. It front-loads the key action ('Current...feerate buckets') and includes additional context (cost). No wasted words, though a slightly more structured format could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers the basic purpose and output context. However, it does not describe the exact format of the returned feerate buckets or how they are structured, which might be needed for tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is trivially 100%. The description adds value by explaining the meaning of the output (feerate buckets, units, cost), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'Current Kaspa mainnet feerate buckets', specifying the currency (sompi) and metric (per gram of tx mass). It differentiates from sibling tools as none of them appear to be fee-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It simply describes what it does without contextualizing its usage or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kaspa mainnet status: DAA score, block count, difficulty, node sync state. Paid (~$0.00015 in KAS).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes the tool is paid with a specific cost, which is important behavioral disclosure. However, it does not mention other traits like rate limits, idempotency, or data freshness, and no annotations are provided to fill gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: the first states the purpose and outputs, the second adds pricing context. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description adequately explains the return values. It could mention data frequency or pagination, but it's fairly complete for a simple status endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters, the baseline is 4. The description adds value by listing the returned metrics, which is sufficient since no input parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Kaspa mainnet status with specific fields (DAA score, block count, difficulty, node sync state), distinguishing it from sibling tools like kaspa_balance or kaspa_fee_estimate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided, but the tool's purpose is clear enough to infer general usage. No alternatives are mentioned despite sibling tools existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mempool status of a Kaspa transaction. Absent from mempool means accepted-or-unknown — confirm acceptance by checking one of its outputs with kaspa_utxos. Paid (~$0.00015).
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the interpretation of mempool absence and the cost. It doesn't mention error cases or limits, but the behavior is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the core purpose, then adds critical usage nuance and cost information. Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is reasonably complete: it covers purpose, interpretation, alternative, and cost. Minor omission of status values or error handling, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not elaborate on the txid parameter beyond its name. It doesn't provide format, examples, or constraints, so the agent lacks guidance on how to specify the transaction ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it returns the mempool status of a Kaspa transaction, and clarifies the meaning of absence. It distinguishes itself from siblings like kaspa_utxos and kaspa_balance by its specific function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear guidance: if transaction is absent from mempool, it could be accepted or unknown, and suggests using kaspa_utxos to confirm. Also mentions the cost, aiding decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UTXO set of a Kaspa mainnet address, including scriptPublicKey and covenant_id where set. Paid (~$0.0003 in KAS).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost (~$0.0003 in KAS) but no other behavioral traits. No annotations provided, so description bears full burden; missing idempotency, side effects, auth requirements, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences covering purpose and cost. No redundant information, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main output (UTXO set with scriptPublicKey and covenant_id) and cost, but lacks details on error handling, output format, or pagination. Adequate for a simple tool but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'address' is described as a Kaspa mainnet address, adding context beyond the schema. However, no format or validation details provided; schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns the UTXO set for a Kaspa mainnet address, distinguishing it from siblings like kaspa_balance and kaspa_tx_status. However, lacks a strong action verb like 'Retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives (e.g., kaspa_balance for balance only, kaspa_tx_status for transaction status). Only notes it is paid, which is not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a prepaid payment session: returns a session key and a personal Kaspa MAINNET deposit address. Send KAS to the address from any wallet (min 0.25 KAS); confirmed deposits become spendable balance within seconds and every paid tool call meters against it. Free. The session is saved locally so subsequent calls use it automatically.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly states it's free, returns a session key and deposit address, describes deposit confirmation, and notes automatic saving. Could mention session overwrite behavior but covers essential traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: purpose, deposit mechanics, and automatic saving. No wasted words, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description covers purpose, usage, and key behaviors. Lacks info on session expiration or multi-session handling, but adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline set at 4. Description adds meaning by explaining what the session is and how it functions, compensating for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool opens a prepaid payment session, returns a session key and deposit address. Specific verb 'Open' and resource 'prepaid payment session' distinguish it from sibling tools like 'session_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells when to use (to get a deposit address and session key for paid tool calls), includes minimum deposit amount (0.25 KAS) and that the session is saved locally. Does not explicitly exclude other use cases but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public web page and return its title + clean markdown; distill=true adds key-fact bullets. Useful when you have no web access of your own. Paid (~$0.0012 in KAS).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| distill | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It discloses that the tool is paid with a specific cost, which is good. However, it does not mention error handling (e.g., what happens if the URL is invalid or the page is inaccessible), rate limits, or other non-obvious behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long, with no wasted words. It front-loads the core purpose, then adds the distill option and usage context. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers the basics: what it does, what it returns, and when to use it. However, it omits details like supported URL schemes, maximum page size, or error scenarios. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage. The description explains the 'distill' parameter ('distill=true adds key-fact bullets') but does not explain the 'url' parameter beyond the tool's general purpose. Since schema coverage is very low, the description should provide more parameter-level detail, especially for the required 'url'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and resource 'public web page', and clearly states the return format (title + clean markdown) and an optional distill mode. It distinguishes from sibling tools by focusing on web page retrieval, though it doesn't explicitly compare to similar tools like 'extract'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Useful when you have no web access of your own.' It also mentions the cost, which helps the agent decide whether to use it. However, it does not specify when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rewrite text per an instruction (tone, format, length...). Paid (~$0.001 in KAS).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| instruction | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It adds a cost hint (Paid ~$0.001 in KAS) but does not disclose other behaviors like data handling, rate limits, or whether it is read-only. It adds some value beyond schema but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a cost note. It front-loads the main purpose and each word contributes value. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers the basic operation and cost. However, it does not mention the expected output (rewritten text) or confirm that the entire text is rewritten. It is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It mentions instruction can cover tone/format/length, which adds meaning to the parameter. However, it does not explain the 'text' parameter beyond being the input. Some semantics are added, but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'rewrite' and the resource 'text', and specifies it is done per an instruction covering tone, format, length, etc. This distinguishes it from sibling tools like summarize or classify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for rewriting text with style/format modifications, but lacks explicit guidance on when to choose this tool over alternatives (e.g., summarize, extract). No when-not or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store documents [{id, text, meta?}] in a named server-side collection for semantic search. Use an unguessable collection name and keep it secret. Paid (~$0.0015 in KAS).
| Name | Required | Description | Default |
|---|---|---|---|
| replace | No | ||
| documents | Yes | ||
| collection | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the operation is paid (~$0.0015 in KAS) and advises on security (keeping collection name secret). This adds useful behavioral context beyond the basic store operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First sentence front-loads the purpose and input format; second adds security and cost. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details on the replace parameter behavior (whether append or overwrite) and does not describe the return value. With 3 parameters and no annotations, the description is somewhat incomplete for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates by explaining the documents parameter structure (id, text, meta) and the collection parameter (named, secret). However, it does not explain the replace parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Store documents'), specifies the input format (documents with id, text, optional meta), and the purpose (semantic search). It distinguishes itself from sibling tools like search_query, which is used for querying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use a secret collection name and mentions cost. While it implies when to use this tool (for indexing) versus search_query (for querying), it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic-search a collection you indexed earlier; returns top-k matches with scores. Paid (~$0.0003 in KAS).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| top_k | No | ||
| collection | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description adds cost information (~$0.0003 KAS) and mentions returns scores, but does not disclose other behavioral traits like authentication, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: first states purpose and return type, second adds cost. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple search tool: explains purpose, return type, and cost. However, it lacks details on the collection parameter, query format, and potential errors. Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions 'top-k' but does not explain what parameters like 'q' (query string) or 'collection' represent, leaving the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs semantic search on a previously indexed collection, returning top-k matches with scores. It distinguishes from siblings like 'search_index' or 'catalog'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the collection must already be indexed but does not explicitly state when to use vs alternatives like 'search_index'. No exclusions or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the current payment session: deposit address, deposited / spent / remaining KAS. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It notes 'Free.' which is a behavioral cost disclosure. It does not mention side effects, authentication needs, or error conditions. The tool appears read-only and safe, but transparency could be improved with more detail on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences. The main action is front-loaded, and every word adds value. 'Free.' is a relevant behavioral note. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool with no parameters and no output schema, the description covers the core functionality and return data. It lacks mention of prerequisites (e.g., an active session) or behavior when no session exists, but these are minor omissions for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the input schema is empty (100% coverage trivially). The description adds value beyond the schema by detailing what is checked and returned. Per guidelines, 0 parameters baseline is 4, and the description fulfills this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Check the current payment session' and lists the specific data returned (deposit address, deposited/spent/remaining KAS). It clearly distinguishes from sibling tool 'open_session', which creates a session, by focusing on status checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: this tool is for checking the status of an existing payment session. However, no explicit when-to-use, when-not-to-use, or alternatives are given. The presence of sibling 'open_session' hints at the workflow, but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize text or a public URL in at most max_words. Paid (~$0.001 in KAS).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| text | No | ||
| max_words | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It mentions the cost (~$0.001 in KAS) and input limit (max_words), but does not disclose idempotency, error handling, or side effects. The cost detail adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a cost note. Every word earns its place, and the key information (action, inputs, constraint, cost) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no parameter descriptions in schema, and 3 parameters, the description is incomplete. It omits the output format, error conditions, and detailed parameter usage (e.g., required fields, text vs URL rules).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It states 'summarize text or a public URL' and mentions max_words, but does not clarify the relationship between the 'url' and 'text' parameters (mutually exclusive? both optional?), nor their expected formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Summarize' and the resources (text or public URL), along with a key constraint (max_words). However, it does not differentiate from sibling tools like 'extract' or 'read_url', though the action is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic usage (summarize text/URL with max_words) but offers no guidance on when to use this tool vs alternatives, no exclusions, and no prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1catalogclassifyembed_textextractgeneratekaspa_balancekaspa_fee_estimatekaspa_networkkaspa_tx_statuskaspa_utxosopen_sessionread_urlrewritesearch_indexsearch_querysession_statussummarizeScored across 17 tools
Every tool has a clearly distinct purpose, targeting either text processing (classify, embed, extract, generate, rewrite, summarize, read_url, search), Kaspa blockchain data (balance, fee, network, tx status, UTXOs), or session management (open, status). No significant overlap; descriptions clarify any potential confusion.
Most tools follow a verb_noun pattern in snake_case (e.g., embed_text, kaspa_balance, open_session). There are minor deviations like 'catalog' (noun used as command) and 'read_url' (verb_noun), but overall the pattern is consistent and readable.
17 tools is slightly above the ideal range but still reasonable for a gateway that combines text AI services and blockchain data. Each tool serves a distinct function, and the count matches the breadth of the server's purpose.
The tool set covers a wide range of text operations (classification, embedding, extraction, generation, summarization, semantic search) and essential Kaspa blockchain queries (balance, fees, network status, transactions, UTXOs). Minor gaps like transaction broadcasting or session closure are acceptable for the stated scope.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Pay-per-call APIs and MCP services for agents, no accounts or keys, with verifiable receipts.