Skip to main content
Glama

market

by com.hektai
OverviewDiscussionsAdmin

hekte_ask

Buy one answer on the Hekte market — PAY FIRST, per call, Lightning. Call it with prompt alone: the result is an error with status: "payment_required", a Lightning invoice (bolt11) for amount_sat (whole sats), a pay_url a human can open, an expires_at, and retry_with (payment_hash, retry_token). Show the human the pay_url (or the invoice) and ask them to pay it; then call this tool AGAIN with the SAME prompt and class plus the payment_hash and retry_token. Before the payment arrives the retry answers payment_not_received; after it, the question is posted as a paid job, a worker answers, the payment settles ON DELIVERY and the answer comes back with who served it and a receipt. If nothing is delivered the hold is cancelled (hold_cancelled: true) and nothing is charged. No balance is kept, no account exists: one invoice is one call. Refused by name: prompt_too_large (over 16384 bytes), class_unknown, invalid_max_sat, proof_unknown, proof_expired, proof_replayed, proof_cancelled, retry_token_invalid (the token is not this invoice's), request_mismatch (a retry must repeat the paid prompt), contract_mismatch (the contract named is not 2, this door's).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
classNoThe task class. Only `chat` exists today.chat
promptYesThe question, verbatim — it is posted to the market as the job's input. A retry must repeat it exactly.
max_satNoOptional cap on this call's price, whole sats. May only LOWER the door's per-call price; a higher value is lowered to it.
contractNoThe hosted contract number this client speaks — every result of this door names it as `contract` and `retry_with` repeats it (today 2). Omit it if unknown; an older number is refused `contract_mismatch` because its retry shape is not this door's.
retry_tokenNoThe `retry_with.retry_token` value from this tool's `payment_required` result. Omit it on the first call; always send it together with `payment_hash`.
payment_hashNoThe `retry_with.payment_hash` value from this tool's `payment_required` result, once a human has paid the invoice. Omit it on the first call; always send it together with `retry_token`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full transparency burden. It discloses PAY FIRST behavior, the hold-cancellation mechanism, no-balance/no-account policy, exact error statuses, and the settlement-on-delivery model. This is exceptionally transparent for a paid API.

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 a single dense paragraph, but it is chronologically organized and front-loaded with the core PAY FIRST behavior. Every clause carries protocol or error information, though the length is substantial. It earns its length without being rambling.

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?

For a non-trivial two-phase payment flow with no output schema, the description covers the first response, retry conditions, payment confirmation, delivery failure, receipt information, and all refusal names. An agent has everything needed to drive the tool correctly through its lifecycle.

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?

The schema already covers all parameters with descriptions, so the baseline is 3. The tool description adds valuable relational semantics: retry must repeat the exact prompt, retry_token must accompany payment_hash, contract determines retry shape, and max_sat only lowers the door price. This exceeds the schema's isolated parameter documentation.

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 opens with 'Buy one answer on the Hekte market' — a specific verb, resource, and transaction model. This clearly distinguishes the tool from the sibling balance and job tools by describing its unique paid-question role.

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?

The description gives an explicit two-phase protocol: call with prompt alone, receive an invoice, have a human pay, then retry with the same prompt/class plus payment_hash and retry_token. It also states when retry fields should be omitted and what happens before/after payment, leaving no ambiguity about invocation.

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

All market 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