Guides you through IoMarkets.ai: data prices, proof and receipt checks, runs, evaluation requests.
Scored across 9 tools
Each tool has a narrow, distinct target: one run vs. all runs, API catalogue vs. API uptime, cost estimate vs. glossary vs. task guide. The only mild overlap is the orientation trio (get_overview, get_guide, explain_term), which could occasionally be confused for 'tell me about the site' questions, but their descriptions clearly separate scope (site summary vs. per-task steps vs. single term).
All nine tools use snake_case verb_noun form (draft_evaluation_request, estimate_cost, explain_term, get_api_status, get_guide, get_overview, get_run, list_data_endpoints, list_runs). The get_/list_ prefix distinction is used meaningfully: get_ for single items or actions, list_ for collections.
Nine tools is well within the sweet spot and every tool maps to a real user need on a guide/documentation site. Nothing looks redundant or padded, and no major surface area is squeezed into one overloaded tool.
The surface covers orientation (overview, guide, glossary), the Data API (catalogue, uptime), Federated Computing runs (list and detail with receipt verification), cost estimation, and evaluation-request drafting. Minor gaps: there is no way to look up pricing/plans outside list_data_endpoints, and no tool for receipt verification standalone, though get_run checks it inline.
Turn what someone wants to evaluate, in their own words, into a Federated Computing evaluation request. Returns the message and a link that opens it in their email app; nothing is sent for them, and they can also use the form. Ask for anything missing, one question at a time, before calling it.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What they want to evaluate, in a sentence or two. | |
| name | Yes | ||
| role | Yes | Their role. | |
| Yes | Where the reply should go. | ||
| assets | No | The kind of model or data (optional). | |
| constraints | No | Regions, confidentiality, timing (optional). | |
| organisation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations say readOnlyHint=true, and the description backs that up with the critical disclosure that nothing is sent for them and the output is a message plus a link that opens their email app. Because there is no output schema, the description responsibly explains the return value. That is exactly the side-effect information an agent would otherwise be uncertain about for a tool named 'request'.
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, front-loaded with purpose, then behavior, then interaction guidance, and there is no filler. The final clause 'before calling it' is slightly compressed, and its referent ('it') has to be inferred. The sentence is otherwise tight.
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 7-parameter tool with 5 required fields and no output schema, the description covers purpose, return values, side-effect boundary, and the gathering protocol. Minor omissions are what the generated request actually contains and whether any authentication is needed; neither is essential for calling it correctly.
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 71%, so four of the seven fields (goal, role, email, assets, constraints) are described in the schema. The description adds the collection strategy ('ask for anything missing, one question at a time') and clarifies that the goal is captured 'in their own words,' helping the agent fill in the fields. But the 'name' and 'organisation' fields have no description in either place, so the description does not compensate for that remaining gap.
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 concrete verb phrase ('Turn what someone wants to evaluate ... into a Federated Computing evaluation request'), which pinpoints both the action and the artifact created. The purpose is easy to tell apart from the sibling tools, which are read-only lookups (get_guide, list_runs, explain_term). It stops just short of 5 because it never explicitly names the sibling tools or states the boundary against them.
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 says to ask for anything missing, one question at a time, before calling it, which is explicit pre-call guidance most tools never give. It also notes the person can use the web form instead, so it acknowledges a manual alternative. A 5 is withheld because it never says when NOT to use the tool (for example, for general questions about Federated Computing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What Federated Computing runs cost in confidential cloud time, at Google Cloud list prices, for the machines and run times the real runs used, plus key services. Same numbers as the cost estimator page. An estimate, not a quote.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | tabular-cpu (credit, fraud, risk models), tabular-tdx, gpu-small, or gpu-llm-14b. | |
| runs | No | How many runs. Default 1. | |
| months | No | Months the key services stay up. Default 3. | |
| key_services | No | Key services, one per data or model owner. Default 2. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish read-only/safe-execution context, and the description adds meaningful behavioral facts beyond them: prices are Google Cloud list prices, sizing is derived from real runs' machines and run times, key services are included, and the output is explicitly an estimate rather than a quote. It stops short of disclosing currency or whether discounts/actual billing are reflected.
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 short sentences, front-loaded with the core action and scope, followed by the crucial caveat that this is an estimate. Every sentence contributes distinct information with no filler.
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 cost estimator with no output schema, the description should clarify what comes back (a cost breakdown? currency? per-service line items?) and whether historical or hypothetical inputs are used. It covers the pricing basis and estimate caveat well but leaves the return value opaque, which is a notable gap given the absence of an output schema.
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 100%, so all four parameters, including the enum values and defaults, are already fully documented in the schema. The description mentions 'key services' in prose but adds no new syntax, units, or interpretation beyond what the schema provides; baseline 3 applies.
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?
States a specific verb (estimate) and resource (cost of Federated Computing runs) with clear scope: cloud time at Google Cloud list prices for observed machine/run configurations plus key services. It is unmistakably different from the doc/list siblings, but it never names or explicitly contrasts with any sibling, which is the rubric's bar for a 5.
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 phrases 'same numbers as the cost estimator page' and 'an estimate, not a quote' imply how to present the result, but there is no explicit guidance on when to call this versus other tools or for which planning scenarios (pre-provisioning, budgeting) it is intended. Usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A plain-English meaning of a word used on the site: x402, USDC, Algorand, test network, signed proof, Federated Computing, confidential hardware, attestation, receipt, AI agent, MCP. Without a word, lists them all.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | The word to explain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds the non-obvious behavior that omitting the term returns the full glossary. It does not describe result format or lookup-miss behavior, keeping it below a 5.
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?
One sentence plus a short clause, front-loaded with the purpose and closed with the default behavior. The enumeration of roughly eleven example terms is slightly long but earns its place by helping the agent match terminology.
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 one-optional-parameter read-only lookup with no output schema, the description covers purpose, scope, and zero-argument behavior. Nothing essential to invoking it correctly is missing, though return shape or miss handling would round it out.
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 100% and the single parameter is documented as optional, but the schema never says what happens when it is omitted. The description supplies exactly that missing semantics ('Without a word, lists them all'), adding real value beyond structured data.
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 gives a specific verb-plus-resource ('a plain-English meaning of a word') and scopes the resource to site terminology by enumerating concrete examples. It is clearly distinguishable from siblings like get_guide or get_overview, though it does not explicitly contrast itself with them.
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?
'Without a word, lists them all' tells the agent what the zero-argument call does, and the enumerated term list implicitly signals when to reach for this tool (encountering unfamiliar site jargon). There is no explicit exclusion or named alternative, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether the Data API at api.iomarkets.ai is up right now.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description contributes only the real-time ('right now') framing and the target endpoint; it says nothing about latency, caching, or failure modes. With annotations present the bar is lower, so a 3 is fair.
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?
A single front-loaded sentence with no filler. The resource and the question are stated in the first few 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?
There is no output schema, so the description should signal what comes back (a boolean, a status object, an error message). It stops at the question and leaves the return shape entirely to inference, which is the main gap for an otherwise simple 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?
The tool takes zero parameters, so the schema-coverage baseline of 4 applies. Nothing in the description misleads about inputs.
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?
States a specific resource (the Data API at api.iomarkets.ai) and the exact question answered ('whether it is up right now'). An agent can distinguish this from siblings like list_runs or get_overview, though the description does not explicitly name them.
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 is only implied by the phrasing 'up right now' — check liveness before/while calling other endpoints. There is no explicit when-to-use, no prerequisites, and no mention of alternatives among the other seven tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step-by-step instructions, with the exact button names, for one task on iomarkets.ai. Without a task, lists the tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | Which task. Leave out to list them all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the output is step-by-step with exact UI button names, and the no-argument path returns an enumeration rather than erroring. It doesn't discuss guide length or what a listing entry contains.
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, zero filler. The primary behavior is front-loaded and the fallback case follows immediately, so the agent reads the decision-relevant facts first.
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 one-optional-param read tool with no output schema and annotations covering safety, this is nearly complete: the agent knows what it gets, what shape it takes, and what happens with no argument. Minor residual gap is guide length/coverage of the 11 tasks, which is low stakes.
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 100% with the enum's own description already saying "Leave out to list them all." The description's "Without a task, lists the tasks" restates that, adding almost nothing beyond the schema; the enum values themselves carry the task semantics. Baseline 3 applies.
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?
Names a specific verb+resource (fetch step-by-step instructions for one task on iomarkets.ai) and states both operating modes: a single task guide, or a task list when no task is supplied. That dual-mode framing makes it clearly distinct from siblings like get_overview or explain_term without needing to name them.
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?
"Without a task, lists the tasks" tells the agent exactly how to use the omittable parameter as a discovery path, and "for one task" frames the primary case. It stops short of naming alternatives (e.g. explain_term for glossary lookups) or stating when not to reach for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What IoMarkets.ai is and what is built: the Data API (verifiable market data AI agents pay for per call over x402) and Federated Computing (private computing across organisations on confidential hardware), with the main pages and what is a demonstration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds content scope (Data API, Federated Computing, demonstrations) but says nothing about return shape, depth, or how the overview relates to the other informational tools. With annotations carrying the behavioral burden, this is adequate but not rich.
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 definition is a single front-loaded sentence that identifies the subject first and then lists the covered topics. It is slightly run-on with the parenthetical explanations, but every clause contributes content an agent would want.
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 no parameters and no output schema, the description only needs to convey what the tool returns, and it does so by enumerating the overview's subject matter. A brief note on how it relates to get_guide would close the remaining gap, but nothing essential is missing for calling a no-arg informational 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the schema is trivially complete and the description does not misrepresent any inputs.
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 names the resource (an overview of IoMarkets.ai) and enumerates the content it covers: the Data API, Federated Computing, main pages, and what is a demonstration. That is more specific than a tautology, but it does not differentiate this tool from siblings such as get_guide or explain_term.
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 is only implied: an agent can infer this is a starting-point overview, but the description never states when to call get_overview instead of get_guide, explain_term, or get_api_status. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One Federated Computing run in detail: what it showed, the model and data, hardware, location, result, payment, and whether its receipt verifies (checked now, with the same code as the receipt checker).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The run id, from list_runs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a read-only, non-open-world operation, and the description adds useful behavioral context: it returns details including model, data, hardware, location, result, payment, and receipt verification. It also discloses that receipt verification is performed now using the same code as the receipt checker. It does not cover error behavior or response shape, but the added disclosure is meaningful.
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 front-loaded sentence that states the scope and then enumerates the returned information without filler. Every clause contributes to understanding what the tool retrieves.
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?
There is no output schema, so the description carries the burden of explaining return values; it does so by listing the key details and the receipt verification behavior. Combined with the fully described input schema and read-only annotations, this is nearly complete, though it could mention not-found or error behavior.
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 100%, and the single id parameter is fully described in the schema as coming 'from list_runs' and constrained by an enum. The main description does not add further meaning beyond the schema. With high schema coverage, the baseline score of 3 is appropriate.
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 identifies the resource and scope: 'One Federated Computing run in detail,' and enumerates the fields exposed. It distinguishes itself from the sibling list_runs by emphasizing a single run and by the schema note that the id comes from list_runs. The only gap is the absence of an explicit retrieval verb, but the intent is unambiguous.
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 is implied rather than stated: the schema notes the id comes 'from list_runs,' indicating this tool should be called after discovering a run id. There is no explicit guidance on when not to use it, no statement of alternatives, and no prerequisites beyond the parameter source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Data API catalogue: each endpoint, what it returns, its parameters and its indicative price per call in USDC, plus how payment works and the indicative plans.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true and openWorldHint=false already establish that this is a safe, closed-world read, so the description's burden is lighter. It adds genuine value by disclosing what the payload contains (prices in USDC, payment explanation, plans), but says nothing about freshness of the indicative prices, result size, or whether the catalogue is static.
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?
A single dense sentence with the catalogue framing front-loaded and no filler. It reads as a noun-phrase fragment rather than a statement of action, which slightly weakens the opening, but nothing in it is wasted.
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 no parameters, no output schema, and safety covered by annotations, the description carries most of the burden and does explain the return contents well. It stops short of saying anything about how large or fresh that catalogue is, which is the one thing an agent might still need to know.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The 100% schema coverage signal is moot given the empty property set.
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?
A specific resource is named (the Data API catalogue) with its contents spelled out: endpoints, return values, parameters, price per call in USDC, payment mechanics, and plans. It is clearly distinct from siblings like get_guide, list_runs, or get_api_status, though the description never explicitly says so; the verb is carried by the tool name rather than the prose.
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 is only implied: an agent can infer this is the discovery tool for the Data API, but the description gives no when-to-use framing and names no alternatives. It does not say, for example, that this should be called before drafting an evaluation request or that a live status tool exists separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every Federated Computing run done on confidential hardware, newest first: its id, what it showed and the hardware it ran on.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the bar is lower; the description still adds real value by disclosing the sort order ('newest first') and the fields each entry carries. It does not say anything about result volume or truncation for large run histories.
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?
A single front-loaded sentence covering scope, ordering and returned fields with no filler. Every clause earns its place.
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 no output schema, the description usefully enumerates the returned fields and sort order. The only gap is unboundedness — 'every run' leaves unclear what happens with very large histories or whether there is any limit.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The absence of parameters is consistent with the promise of listing every run.
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?
States a specific verb and resource ('Every Federated Computing run ... its id, what it showed and the hardware it ran on') and scopes it to confidential-hardware runs. It contrasts implicitly with the singular sibling get_run via 'every', but never names it.
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 is only implied by the plural 'every ... run'; there is no explicit statement of when to use this versus get_run for a single run's detail or the other list_* tools. An agent must infer the routing.
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.
get_run1 field changedInput schema / properties / id / enumPrevious value: -[
- "join-across-banks",
- "federated-round",
- "gpu-llm-14b",
- "owner-key-service",
- "owner-kms",
- "sealed-tdx-gpu",
- "sealed-tdx",
- "gpu-llm-7b",
- "gpu-llm",
- "gpu-compute",
- "confidential-gpu",
- "three-banks",
- "governed",
- "intel-tdx",
- "bundled-image",
- "tabular-residency",
- "first-paid-run",
- "first-run"
-]New value: +[
+ "pilot-rehearsal",
+ "join-across-banks",
+ "federated-round",
+ "gpu-llm-14b",
+ "owner-key-service",
+ "owner-kms",
+ "sealed-tdx-gpu",
+ "sealed-tdx",
+ "gpu-llm-7b",
+ "gpu-llm",
+ "gpu-compute",
+ "confidential-gpu",
+ "three-banks",
+ "governed",
+ "intel-tdx",
+ "bundled-image",
+ "tabular-residency",
+ "first-paid-run",
+ "first-run"
+]estimate_costget_guide1 field changedInput schema / properties / task / enumPrevious value: -[
- "look-around",
- "verify-proof",
- "console",
- "runs",
- "verify-receipt",
- "audit-trail",
- "request",
- "own-assistant"
-]New value: +[
+ "look-around",
+ "verify-proof",
+ "console",
+ "runs",
+ "verify-receipt",
+ "audit-trail",
+ "request",
+ "review-pack",
+ "pilot",
+ "cost",
+ "own-assistant"
+]draft_evaluation_requestexplain_termget_api_statusget_guideget_overviewget_runlist_data_endpointslist_runsMarket data and analytics for external AI clients
Free market data with provenance and paid decision intelligence for AI agents.
Market data, LLM gateway, ML forecasts, batch+bundle, self-building catalog. USDC via x402 + MPP.
Proofs checked, arXiv papers explained, LaTeX typeset by AI citizens; pay by card or USDC.
Add one secure layer between your agents and this server.