Read-only data for OUROS AI trading agents: markets, agents, receipts, proof checks, backtests.
Scored across 8 tools
Each tool targets a distinct resource or action: agents (get/list), markets, model prices, signals, receipts (list/verify), and strategy simulation. The singular get_agent versus list_agents boundary is clear, and list_receipts versus verify_receipt separates discovery from cryptographic verification.
All eight tools follow a consistent snake_case verb_noun pattern: get_*, list_*, simulate_strategy, and verify_receipt. There are no mixed conventions or vague standalone verbs.
Eight tools is well-scoped for an analytics and verification surface covering agents, markets, signals, models, receipts, and backtesting. Each tool has a clear role without redundant variants.
The surface covers reading agents, markets, model prices, signals, listing and verifying receipts, and simulating strategies. Minor gaps exist around agent lifecycle management (create/update/register agent) and direct receipt retrieval by hash, but the core read/verify/simulate workflows are present.
One agent with its strategy, limits and stats. Use a demo ID (e.g. atlas-01) or an ERC-8004 agent ID (a number).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
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 by structured data. The description adds what the payload contains (strategy, limits, stats), which is real added value, but omits error behavior for missing IDs and says nothing about data freshness despite the open-world annotation.
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 short sentences, front-loaded with what is returned and followed by parameter guidance. No waste, though the opening fragment is slightly clipped.
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 single-record read with annotations covering safety and no output schema, the description supplies the return-content summary and ID format. Only edge-case behavior for invalid IDs is missing.
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 the description must carry the parameter meaning. It does compensate meaningfully by explaining that `id` is either a demo string like 'atlas-01' or a numeric ERC-8004 agent ID passed as a string, which the bare schema does not convey.
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-less but clear resource retrieval: 'One agent with its strategy, limits and stats.' An agent can tell this is a single-record fetch, implicitly distinct from list_agents, though no sibling is named explicitly.
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 covers accepted ID forms ('demo ID (e.g. atlas-01) or an ERC-8004 agent ID'), which is useful, but says nothing about when to prefer this over list_agents or what happens for an unknown ID. Usage is implied rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All 36 OUROS markets on Hyperliquid (crypto, stocks, commodities, FX, index): price, 24h change, hourly funding, 24h volume, max leverage.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and openness are covered. The description adds the useful behavioral fact that it returns a live snapshot of a fixed universe of 36 markets with specific metrics. It does not say whether values are real-time versus cached, nor any rate-limit or freshness caveats.
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 pairing universe ('All 36 OUROS markets') with the returned metrics. Dense and waste-free; only a minor cost is that the asset classes and field list are compressed into one long parenthetical chain.
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, which is the main thing an agent needs. But for a no-required-param live market tool it omits whether the response is per-market objects, whether category narrows the list, and any freshness/refresh semantics.
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%, but the single parameter is a self-explanatory enum and the description's parenthetical matches those enum values. However, it never explains whether `category` filters the result or whether the 'All 36' framing conflicts with passing a category, leaving a real ambiguity about the parameter's effect.
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 the resource precisely (all 36 OUROS markets on Hyperliquid) and enumerates the asset classes and returned fields, so the agent knows exactly what data this returns. The verb is only implied ('get' from the name), and it doesn't explicitly contrast with get_model_prices or get_signals, but the scope is unmistakable.
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?
There is no statement of when to use this versus siblings like get_model_prices or get_signals, and no exclusions. The parenthetical asset-class list implies the tool is for market data, but the agent must infer the routing decision from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The models an OUROS agent can think with, with live OpenRouter prices per 1M tokens and context length.
| 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; the word 'live' reinforces the open-world, real-time fetch behavior, which is useful corroboration. However, it says nothing about freshness, caching, cost of the call, or what happens if OpenRouter is unavailable — meaningful gaps for a live external fetch.
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 tight sentence with the subject front-loaded and no filler. It is slightly compressed into a fragment, which costs a little readability but nothing 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 input parameters and no output schema, the description needs to convey what comes back — it does so by naming the two payload fields (price per 1M tokens, context length). It does not describe the record shape or ordering, but for a simple zero-arg read this is close to sufficient.
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 description correctly signals that no filtering input is expected.
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?
It names the specific resource (models available to an OUROS agent) and the payload (live OpenRouter prices per 1M tokens plus context length), which distinguishes it from siblings like get_markets and get_signals. The phrasing is a noun fragment rather than a verb+resource statement, so it stops short of a textbook 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?
There is no guidance on when to call this versus get_agent or get_markets, and no mention of prerequisites or frequency. The agent must infer from the name alone that this is the pricing/catalog lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live signals computed from public Hyperliquid data (spread z-scores, momentum gaps, funding, volume), each with its source and the numbers that triggered it.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| limit | No |
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 adds real value beyond that: the data is public Hyperliquid data, signals are computed rather than raw, and each result carries its source and triggering numbers. It does not mention freshness/refresh cadence or whether an empty result is possible, which matters for a 'live' feed.
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; every clause (source of data, signal types, per-signal provenance) 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 does useful work by saying each signal comes with its source and triggering numbers. But for a two-parameter, filterable feed it leaves the filtering/pagination behavior and the meaning of 'live' (snapshot vs streaming) unexplained, which an agent needs before calling.
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 the description must carry the burden, and it partially does: the listed categories (spread, momentum, funding, volume) map one-to-one onto the `kind` enum values, giving that filter implicit meaning. The `limit` parameter (1-50) is never mentioned, and it's not stated that `kind` filters results rather than selecting a computation.
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 concrete verb and resource ('Live signals computed from public Hyperliquid data') and enumerates the signal families (spread z-scores, momentum gaps, funding, volume), which tells an agent exactly what comes back. It never names or contrasts against siblings like get_markets, so sibling differentiation is left implicit.
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?
There is no statement of when to reach for this tool versus get_markets or simulate_strategy, and no prerequisites or exclusions. The agent must infer that this is a read-only analytics feed from the phrase 'live signals' alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OUROS agents: the demo agents (paper trading on live prices) and agents registered on Robinhood Chain (ERC-8004), with 7-day stats.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely new context — that live prices underpin demo agents, that on-chain agents live on Robinhood Chain via ERC-8004, and that stats cover 7 days — but says nothing about pagination, ordering, result limits, or what 'stats' contain.
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 no filler, front-loading the resource and its two categories. Slightly awkward phrasing with stacked parentheticals, but nothing 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?
For a one-optional-param read-only list with no output schema, this is close to adequate: it explains both sources and the stat horizon. It still leaves the agent guessing about result shape, ordering, and whether results are paginated or capped.
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 carry the load. It indirectly explains two of the three enum values (demo = paper trading on live prices, onchain = ERC-8004 on Robinhood Chain) but never names the `source` parameter or clarifies that 'all' is the default/union.
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 the resource (OUROS agents) and states the two populations being returned — demo agents paper trading on live prices and ERC-8004 agents on Robinhood Chain — plus the stat window. The list semantics are clear from the name and the enumeration of what is included, though the verb is never stated explicitly.
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 versus the sibling get_agent (single agent lookup) or when to prefer one source over another. The only implied usage cue is that this covers multiple agents while get_agent covers one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent decision receipts of a demo agent, each with its SHA-256 hash and UTC day. Verify any of them with verify_receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external scope are covered. The description adds genuinely useful detail about returned fields (hash, UTC day), but leaves "recent" undefined and says nothing about default page size, ordering, or what happens when an agent has no receipts.
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 tight sentences with no filler; the return-content detail comes first and the sibling routing second. Nothing is repeated from the name or title.
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 sketches the return shape (hash plus UTC day), which is the right call. However, for a two-parameter tool with zero schema description coverage, it omits the semantics of both the agent identifier and limit, leaving an agent to guess on 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?
Schema description coverage is 0%, so the description must carry the parameter burden, and it largely does not. "of a demo agent" hints at the agent parameter but never states its expected format (ID vs. name vs. slug), and the limit parameter — including its 1-100 range and default — is never mentioned.
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 concrete resource (decision receipts) and the scope (recent, per demo agent), and states what each item carries: SHA-256 hash and UTC day. It also names the sibling verify_receipt, so an agent can separate listing from verification without opening a schema.
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?
"Verify any of them with verify_receipt" gives an explicit routing rule to the correct sibling for the natural follow-up action. It stops short of saying when to prefer this over list_agents or when not to use it, but the core use/alternative split is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paper-backtest a pair strategy on the last 7 days of Hyperliquid prices with $10,000, the same engine the OUROS launch desk uses.
| Name | Required | Description | Default |
|---|---|---|---|
| long | No | fixed / spread: first leg | |
| type | Yes | How the pair is chosen | |
| exitZ | No | spread: close when |z| falls under this (default 0.3) | |
| short | No | fixed / spread: second leg | |
| entryZ | No | spread: open when |z| reaches this (default 1.5) | |
| perDay | No | max USD opened per UTC day, at least 2 × perTrade (default 4000) | |
| perTrade | No | max USD per leg (default 1000) | |
| universe | Yes | Hyperliquid market names, e.g. BTC, ETH, xyz:NVDA, xyz:GOLD | |
| lookbackH | No | ||
| rebalanceH | No | ||
| maxLeverage | No |
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 usefully adds that execution is paper-only, that the window is fixed at the last 7 days, and that capital is fixed at $10,000 rather than parameterized — but it says nothing about determinism, runtime, or what the simulation returns.
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 wasted preamble; the verb and core assumptions land immediately. The closing clause about the 'OUROS launch desk' engine is credibility framing rather than actionable information, which keeps it just short of a 5.
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 an 11-parameter simulation tool with no output schema, the description should say what a backtest yields (equity curve, PnL, trade list) and whether results are reproducible. It also leaves the 7-day window and fixed $10,000 capital potentially in tension with perDay/perTrade parameters, without clarifying how the caps interact.
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 73%, above the midpoint, so the schema carries most of the load and a 3 baseline is appropriate. However, the description adds zero parameter-level meaning and does not compensate for the three undescribed enum parameters (lookbackH, rebalanceH, maxLeverage), nor does it explain how 'type' interacts with 'long'/'short'.
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 ('Paper-backtest a pair strategy') plus the data source (Hyperliquid prices) and fixed notional ($10,000), which no sibling tool offers. It is clearly distinguishable from get_markets, get_signals, and get_model_prices, though it never names those alternatives explicitly.
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 gives no when-to-use or when-not-to-use guidance and does not point to any sibling tool for alternative workflows. 'Paper-backtest' implies a simulation rather than live execution, but that is the only usage signal and it is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-hash a receipt (canonical JSON, SHA-256), fold its Merkle proof and compare with the published daily root. Pass the receipt object or its hash.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | No | ||
| receipt | No |
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 adds valuable behavior beyond that: the deterministic SHA-256/canonical-JSON algorithm, the Merkle proof fold, and the comparison target (published daily root), which explains why the call may reach outside the local context. It stops short of noting what happens on mismatch or whether the published root must be fetched.
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 dense sentences with zero filler; the verification mechanism comes first and the input alternatives last. Every clause carries information an agent needs.
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 must carry the return contract, and it does not say whether the tool returns a boolean, a validity object, or the expected vs. actual root. For a cryptographic verification tool with an undocumented nested input, this leaves the agent guessing about results and edge cases.
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% for both parameters, so the description is the only source — and it does convey the key semantic that 'hash' and 'receipt' are alternative inputs for the same verification. However, it does not clarify that effectively one of the two must be supplied, nor what fields of the nested receipt object are used in the canonical JSON hash.
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 (verify/re-hash) and resource (a receipt) plus the exact mechanism: canonical JSON SHA-256 re-hash, Merkle proof fold, comparison against the published daily root. This is clearly distinguishable from sibling read tools like list_receipts, which merely enumerate receipts rather than cryptographically validating one.
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 gives parameter-level usage ("Pass the receipt object or its hash") but no guidance on when to prefer this over list_receipts or what happens if using this without a published root. Usage is implied by the verification workflow rather than stated with prerequisites or exclusions.
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_agentget_marketsget_model_pricesget_signalslist_agentslist_receiptssimulate_strategyverify_receiptRead-only Proof of Agent explorer: epochs, rewards, holders, swaps and agent census. No auth.
Free market data with provenance and paid decision intelligence for AI agents.
Read-only Hyperliquid data for AI agents: fills, candles, funding, liquidations, wallet analytics.
Read-only gateway for durable agent identity, consent, recognized work, and signed receipts.
Add one secure layer between your agents and this server.