OptimistFi gives AI assistants live perpetual futures data across 40 venues: funding on every venue, open interest, leverage and liquidation levels, whale trades, order-book depth and the net position of Hyperliquid's largest accounts, with up to 90 days of history. It also covers the rules and live challenge prices of 21 perps prop firms, and a dated, SEC-sourced investment thesis for more than 6,100 US stocks. Public and read-only: no key, no sign-up. Every answer names its source and time.
Scored across 17 tools
Descriptions are unusually disciplined, with explicit 'Not for:' cross-references routing agents between similar tools (answer vs compare, get_thesis vs what_changed vs get_thesis_impact, insider vs congress trades). The main soft spot is the four perps tools (get_perps, get_perps_history, get_perps_market, get_perps_desk) and the thesis-family tools, whose boundaries are distinguishable but require careful reading.
The dominant pattern is snake_case verb_noun/get_noun (get_calendar, get_filings, get_insider_trades), consistently applied across most tools. A few deviations—bare verbs 'answer' and 'compare', plus 'what_changed'—break the pattern but remain readable and unambiguous.
17 tools is at the high end but is justified by the genuinely broad surface: stock research, perps markets, congressional/insider trades, and prop firms. Each tool maps to a distinct query type, so nothing feels purely redundant, though a few perps tools could be consolidated.
Strong lifecycle coverage for the domain—entity resolution, valuation, thesis tracking, filings, capital returns, calendar, insider/congress trades, plus perps and prop firm data. Gaps exist (explicitly no 10-K/10-Q section reading, no price history or screening), but core research workflows are covered end to end.
A stock's full read in one call: the standing investment case, valuation off its filed financials, and the latest quarter. Use when the user asks: is X a buy; is X cheap; what are X's earnings; how was X's quarter; did X beat. response_mode=plain for beginners. Not for: several companies → compare. Args: entity; response_mode.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | The company: a ticker (AAPL, BRK.B), a company name (Apple) or an SEC CIK. | |
| reading_level | No | With response_mode plain, who the explanation is written for: 5 a complete beginner, 10 a general reader, 13 an informed investor (unset reads as 13, with precise figures). | |
| response_mode | No | "standard" (default): the full read with the investment case; "plain": a short beginner-friendly explanation at the reading_level grade. | standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the useful fact that this is a composite read aggregating three views in one call, but says nothing about latency, rate limits, data freshness, or when the composite is preferable to fetching pieces via get_filings/get_thesis.
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?
Front-loaded with the payload summary, then triggers, then the exclusion, then args – a sensible priority order with no filler prose. The trailing 'Args: entity; response_mode.' is redundant with the schema and slightly incomplete, which keeps it just short of 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?
There is no output schema, so the description carries the return-value burden and does name the three content blocks the agent will get back. Combined with annotation coverage of the safety profile, an agent has enough to call this correctly, though it lacks guidance on output size or multi-entity behavior beyond the compare pointer.
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 the schema already fully documents entity, reading_level, and response_mode, making baseline 3 appropriate. The description only restates response_mode=plain for beginners and its 'Args' line even omits reading_level, adding little beyond the structured fields.
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 concrete verb+resource ('a stock's full read in one call') and enumerates the three payload components: standing investment case, valuation off filed financials, and latest quarter. It explicitly names the sibling it is not ('several companies → compare'), so an agent can route 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?
Gives explicit when-to-use triggers in the user's own phrasing ('is X a buy; is X cheap; what are X's earnings; how was X's quarter; did X beat') and an explicit exclusion with the alternative tool ('Not for: several companies → compare'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Two or more companies side by side: each one's valuation, investment case, and what supports or challenges it, so the comparison rests on the cases, not just ratios. Use when the user asks: X vs Y; which is the better buy; is X or Y more defensive. response_mode=plain for beginners. Not for: one company → answer. Args: entities (2-5).
| Name | Required | Description | Default |
|---|---|---|---|
| entities | Yes | Two to five companies or tickers to set side by side. | |
| reading_level | No | With response_mode plain, who the explanation is written for: 5 a complete beginner, 10 a general reader, 13 an informed investor (unset reads as 13, with precise figures). | |
| response_mode | No | "standard" (default): the full read with the investment case; "plain": a short beginner-friendly explanation at the reading_level grade. | standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuine behavioral framing beyond that: the comparison is case-based rather than ratio-based, and response_mode=plain yields a beginner-oriented rendering. It does not describe return structure or length, but the added analytical framing is real 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?
Front-loads what the tool produces, then triggers, then exclusions, then args. Dense but each clause earns its place; the trigger-phrase list is slightly listy but functional rather than padding.
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 carries the burden of describing results, and it does identify the comparison contents (valuation, investment case, supports/challenges). It is slightly thin on output shape or length, but an agent has enough to select and call 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 description coverage is 100%, so entities, reading_level and response_mode are already fully documented with their semantics and defaults. The description only restates the entities cardinality ('Args: entities (2-5)') and one mode hint, adding essentially nothing beyond the schema — the baseline 3 for high coverage 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 and resource ('Two or more companies side by side') and enumerates exactly what is produced — valuation, investment case, supporting and challenging factors. It explicitly distinguishes itself from the single-company sibling ('Not for: one company → answer'), so an agent can route without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger phrasings ('X vs Y', 'which is the better buy', 'is X or Y more defensive') and an explicit exclusion routing to the answer tool. Both the use case and the boundary case are stated, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What is ahead for a company: the next earnings date projected from its own filing cadence (held, not rolled, marked overdue when lapsed), then trial readouts, nearest first. Use when the user asks: when does X report next; what's coming up for X. Not for: past events → get_filings; what the earnings were → answer. Args: entity; types; limit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most events: the earnings date first, then readouts nearest first to return. | |
| types | No | Kinds of dated event: "corporate_event" (projected earnings dates) and "fda_event" (clinical trial readouts); unset returns both. | |
| entity | Yes | The company: a ticker (AAPL, BRK.B), a company name (Apple) or an SEC CIK. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely non-obvious behavior: dates are projected from filing cadence, are 'held' rather than rolled, and are flagged overdue when a projection lapses. That derivation rule is exactly the kind of trait an agent cannot get from structured fields.
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?
Front-loaded with the core purpose, then usage triggers, then exclusions and args in a compact sequence. It is dense as a single paragraph but nearly every clause carries information; a light structural break before the 'Not for' clause would improve scanning.
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 read-only lookup with an output schema and fully documented parameters, the description covers purpose, triggers, exclusions, projection semantics, and ordering. An agent has everything needed to select and call 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 100% and the schema already explains entity formats (ticker/name/CIK), the types enum values, and limit ordering, so the baseline is 3. The description's 'Args: entity; types; limit' restates the names but also reinforces the ordering contract ('nearest first'), which adds slight value beyond the 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?
States a specific verb and resource: 'the next earnings date projected from its own filing cadence ... then trial readouts, nearest first.' It also defines the projection semantics (held, not rolled, marked overdue), so an agent knows exactly what the timeline contains versus a raw filing list.
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?
Gives explicit trigger phrasings ('when does X report next', 'what's coming up for X') and explicit exclusions routed to named siblings: past events to get_filings, actual results to answer. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How a company returns capital: dividend-rate history with each raise or cut, buyback authorizations beside the cash actually spent, splits and name changes. Forward ex-dates are not served. Use when the user asks: did X raise its dividend; is X buying back stock; has X cut it. Args: entity; kind = dividends | buybacks | actions.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | "dividends" (default): the declared per-share dividend over time, each raise or cut named; "buybacks": repurchase authorisations beside the cash actually spent; "actions": stock splits and name changes; "calendar": the declared dividends (forward ex-dates are not served). | dividends |
| limit | No | Most records to return. | |
| entity | Yes | The company: a ticker (AAPL, BRK.B), a company name (Apple) or an SEC CIK. | |
| periods | No | How many of the latest filed periods to read (usually quarters). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a scope boundary (forward ex-dates are not served) but does not elaborate on return format, data freshness, or sources beyond what the schema and output schema imply; with an output schema present, a 3 is appropriate.
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 front-loaded with the resource definition, followed by scope boundaries and usage examples in compact sentences; every sentence adds information and there is no waste.
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 read-only data-retrieval tool with full schema coverage and an output schema, the description covers what is returned, what is excluded (forward ex-dates), and when to use it. It leaves minor gaps around data recency and output shape, but those are not required given the 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 coverage is 100% and the schema already describes entity, kind with its enum meanings, limit, and periods in detail. The description only restates 'Args: entity; kind = dividends | buybacks | actions' without adding new semantics, so it meets the baseline 3 for a fully documented 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 names a specific resource (capital returns: dividend history, buybacks, splits, name changes) with a clear framing verb phrase, and lists exactly what records are returned. It is distinguishable from siblings like get_calendar or get_insider_trades.
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 explicit example questions that map directly to the tool (did X raise its dividend; is X buying back stock; has X cut it), which is strong when-to-use guidance. It does not name alternatives or when-not-to-use cases, keeping it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
US House stock-trade disclosures (STOCK Act) by ticker or by member, dated by transaction. Use when the user asks: which members of Congress traded X; what did a named member buy; is Congress selling X. Not for: company insiders → get_insider_trades. Args: ticker or member; limit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most trades, newest first to return. | |
| entity | No | A company name, instead of a ticker. | |
| member | No | A House member's name: what that member traded (House only). | |
| ticker | No | A stock ticker: which members traded it. | |
| chamber | No | "house" (default): US House disclosures by ticker or member. | house |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the regulatory provenance (STOCK Act), that dates are transaction dates rather than filing dates, and the House-only limitation. It stops short of mentioning disclosure lag or result freshness, which would be the remaining useful detail.
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?
Front-loaded with the core definition, then triggers, then exclusion, then args — no wasted sentences. The arg line listing only two of five parameters is the one weak spot, being both incomplete and slightly inaccurate.
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 an output schema present, return values need not be explained. Purpose, routing, and the House-only constraint are covered; only the entity/chamber parameters and any disclosure-lag caveat are left to the schema, which is a minor gap for a read-only lookup 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?
Schema description coverage is 100%, so the schema already documents all five parameters well (including the entity-vs-ticker distinction and chamber default). The description's 'Args: ticker or member; limit' is a partial and slightly misleading summary — it omits entity and chamber and implies the two selectors are mutually exclusive. Baseline 3 with high coverage.
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?
Specific verb+resource: 'US House stock-trade disclosures (STOCK Act) by ticker or by member, dated by transaction.' It names the data source and both access axes, and explicitly distinguishes itself from the sibling insider-trades tool, so an agent can route without opening either 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?
Gives three concrete user-question triggers ('which members traded X', 'what did a named member buy', 'is Congress selling X') and an explicit negative routing rule ('Not for: company insiders → get_insider_trades'). When-to-use and when-not-to-use are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A company's own disclosures: filed 8-K events, its press releases, the text of those 8-Ks, and governance red flags (late filings, auditor changes, selling clusters). Use when the user asks: any red flags at X; what did X announce; latest 8-K from X. Not 10-K/10-Q sections. Args: entity; kind = events | press_releases | event_text | red_flags.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Window end, YYYY-MM-DD. | |
| kind | No | "events" (default): filed 8-K events and how significant; "press_releases": the company's own releases; "event_text": the text of the latest filed events; "red_flags": late filings, auditor changes and insider-selling clusters. | events |
| limit | No | Most records to return, newest first. For events it counts the 8-K filings; the declared dividends, insider trades and sentiment reading beside them come in addition, up to as many of each. | |
| start | No | Window start, YYYY-MM-DD. | |
| entity | Yes | The company: a ticker (AAPL, BRK.B), a company name (Apple) or an SEC CIK. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral content: what 'red_flags' actually contains (late filings, auditor changes, insider-selling clusters) and how 'limit' interacts with adjacent event data. It does not mention rate limits, pagination cursors, or ordering caveats beyond 'newest first' implied by the schema, so it falls short of 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?
Three compact sentences, front-loaded with the core purpose before usage triggers and args. No filler, though the trailing args line partially duplicates the schema enum rather than earning new 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?
No output schema exists, so the description must convey what comes back; it does this per-kind, and the date window and limit semantics are covered in the schema. What is missing is any note on result shape consistency across kinds or behavior when a window returns nothing, which is minor given a single required, well-documented parameter.
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 schema already documents every parameter in detail, including the full alias enum and the unusual limit-counting behavior for events. The description only restates a subset of the kind values (events | press_releases | event_text | red_flags), adding little beyond the schema, so the 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 resource and its scope: a company's own disclosures, enumerated as filed 8-K events, press releases, event text, and governance red flags. It explicitly distinguishes itself from sibling content ('Not 10-K/10-Q sections'), so an agent can route between this and other filing-oriented tools without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete user-phrasing triggers ('any red flags at X; what did X announce; latest 8-K from X') plus a clear exclusion ('Not 10-K/10-Q sections'). That is explicit when-to-use and when-not guidance rather than inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Form 4 insider trades for one company, P and S first: who, role, code (P buy, S sell, A grant, M exercise, F tax), shares and dollar value. Use when the user asks: are insiders buying X; did X's CEO sell; insider activity at X. Not for: Congress → get_congress_trades. Args: entity; start; end; limit.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Latest transaction date, YYYY-MM-DD. | |
| limit | No | Most transactions, open-market buys and sales first to return. | |
| start | No | Earliest transaction date, YYYY-MM-DD. | |
| entity | Yes | The company: a ticker (AAPL, BRK.B), a company name (Apple) or an SEC CIK. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds real behavioral value beyond that: the data source (Form 4) and the result ordering ('P and S first'), which tells the agent what a truncated result set will and won't contain. It stops short of describing pagination or date-default behavior, keeping it off 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?
Front-loaded with the core purpose, then usage, then exclusion, then args — a clean scan order with no filler sentences. The trailing arg list is mildly redundant with the schema and is the only thing that doesn't fully earn 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 an output schema present, return values needn't be explained, yet the description still names the returned fields and ordering. Combined with the sibling exclusion and the usage triggers, an agent has everything needed to call it correctly; only edge behaviors like pagination or unbounded date ranges are left unstated.
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 entity, start, end and limit are already documented with formats and defaults. The 'Args: entity; start; end; limit' line merely restates the parameter names without adding meaning, which is the baseline-3 case when the schema does the heavy lifting.
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+resource with source ('Form 4 insider trades for one company') and even previews the record shape (who, role, code, shares, dollar value). The parenthetical code legend (P buy, S sell, A grant, M exercise, F tax) makes the domain unmistakable and clearly separates it from get_congress_trades.
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?
Gives concrete user-question triggers ('are insiders buying X', 'did X's CEO sell', 'insider activity at X') and an explicit exclusion with the correct alternative ('Not for: Congress → get_congress_trades'). Both the when and the when-not are stated, so no inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One perp market right now, venue by venue: price and premium to the index or stock, open interest, funding, max leverage, liquidation levels, whale trades, positioning; a stock perp's weekend move. Use when the user asks: X funding rate; where do X longs get liquidated. Not for: trends or book depth → get_perps_history. Args: entity.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | research: detailed hourly evidence; trading: bounded fresh order-book reads on supported venues, never an hourly-price fallback. | research |
| entity | Yes | The market: a ticker or symbol (NVDA, BTC, XAU), a company name (Tesla) or a common asset name (bitcoin, gold, crude oil). | |
| max_age_s | No | Trading mode: maximum age of the venue's book in seconds, default 3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, openWorld, non-destructive, so the safety bar is met structurally; the description adds real behavioral value by listing the returned surface (liquidation levels, whale trades, positioning, weekend move for stock perps) and implying a live snapshot ('right now'). It does not mention auth needs, rate limits, or venue coverage limits, so it stops short of 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?
Front-loaded with the resource and scope, then usage, then exclusion, then args — a sensible priority order with no filler sentences. The dense semicolon list of data dimensions is information-carrying rather than padding, though slightly heavy.
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 exists, so the description carries the return-value burden and does so by enumerating the metrics returned. Combined with a fully documented schema for the three parameters, an agent has enough to call it correctly; only deeper operational detail (which venues, freshness semantics in research mode) is absent.
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 the schema already fully documents mode, entity, and max_age_s, including the mode enum trade-off. The description only says 'Args: entity', adding no meaning beyond the schema — baseline 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?
States a specific verb+resource+scope: a single perp market snapshot, venue by venue, and enumerates the exact data dimensions covered (price/premium, OI, funding, max leverage, liquidation levels, whale trades, positioning). It also explicitly names the sibling it is not (get_perps_history), so an agent can separate the two without opening either 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?
Gives concrete triggering user phrasings ('X funding rate', 'where do X longs get liquidated') and an explicit exclusion with the correct alternative: 'Not for: trends or book depth -> get_perps_history.' This is textbook when/when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OptimistFi's perps desk: stories, traders with checked calls, wallets covered, companies that blocked tokenized trading of their stock, Kalshi's BTC/ETH odds and perp funding. Use when the user asks: perps news on X; is trader Y worth following; Kalshi's BTC odds. Args: view; market; trader; wallet; limit.
| Name | Required | Description | Default |
|---|---|---|---|
| dex | No | account view only: Hyperliquid builder dex name, e.g. xyz; empty reads the main dex. | |
| view | No | news: the desk's published perps stories, newest first. traders: the perps traders directory, with the desk's checked calls on each. wallets: the Hyperliquid wallets the desk has covered, with their stories. account: a fresh public Hyperliquid wallet state on one dex, with positions and margin; wallet is required. tokenized: which companies have blocked tokenized trading of their stock, from each venue's public notice. kalshi: Kalshi's BTC and ETH odds for the next 5 PM ET close and Friday's beside its perps' funding, read every five minutes, with its daily study of perps volume against open interest. | news |
| limit | No | Rows, up to 25. | |
| market | No | news and traders: one market (BTC, NVDA, gold). tokenized: one company by ticker or name (MSFT, Microsoft). kalshi: BTC or ETH. | |
| trader | No | traders: one trader by name or X handle. | |
| wallet | No | wallets: one 0x address; adds what it holds now. | |
| max_age_s | No | account only: maximum source age in seconds, default 3. A stale or undated account is unavailable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover the safety profile: readOnly, idempotent, non-destructive, open-world. The description adds some content-quality context such as 'traders with checked calls' and 'companies that blocked tokenized trading', but does not add much beyond the annotations and schema about freshness, caching, or response 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 reasonably front-loaded and compact, but the trailing 'Args: view; market; trader; wallet; limit' is redundant with the schema and incomplete because it omits dex and max_age_s. That sentence adds little value and slightly weakens precision.
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 a seven-parameter, multi-view tool with no output schema, the description supplies useful intent examples and content categories. The rich schema and safe-read annotations fill most remaining gaps, though explicit differentiation from sibling perps tools and coverage of the account view would improve completeness.
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 every parameter is already documented in detail. The description only lists 'view; market; trader; wallet; limit' and omits dex and max_age_s, adding little meaning beyond the schema. Baseline 3 is appropriate when the schema carries parameter semantics.
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 this as OptimistFi's perps desk and enumerates the content types it surfaces (stories, traders, wallets, tokenized stocks, Kalshi odds). However, it does not explicitly distinguish the tool from siblings such as get_perps, get_perps_market, or get_perps_history, leaving the agent to infer when this multi-view desk tool is preferable.
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 concrete example queries — perps news on X, whether trader Y is worth following, and Kalshi BTC odds — which clearly map user intent to this tool. It lacks explicit when-not-to-use guidance or named alternatives, but the usage context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One perp market over time (1d to 90d): price, open interest, funding, taker buying vs selling, big accounts' net position; plus the latest book depth (±0.5/1/2%) and big accounts' P&L and leverage. Use when the user asks: X funding this week; are whales adding to X; how deep is X's book. Args: entity; window.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | The market: a ticker or symbol (NVDA, BTC, XAU), a company name (Tesla) or a common asset name (bitcoin, gold, crude oil). | |
| window | No | How far back: 1d (hourly steps), 7d (4-hourly), 30d or 90d (daily). | 7d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is met structurally. The description adds genuine signal beyond that: it separates time-series fields from the 'latest book depth' snapshot and clarifies the granularity tiers, which warns the agent that some returns are point-in-time rather than historical. No rate limits or auth notes are given, but for a read-only analytics tool this is minor.
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 return-content list is front-loaded, followed by usage examples, which is a sensible order for an agent deciding whether to call it. The trailing 'Args: entity; window' is redundant with the schema and could be dropped, costing it the top score.
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 describing returns, and it does so thoroughly — listing every series and noting which are snapshot vs historical. The only real gap is the absence of any disambiguation from the sibling perps tools, which matters given three near-namesakes in the same family.
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%, so both parameters (entity, window) are fully documented in the schema, including the enum values and default. The description only restates 'Args: entity; window' plus '1d to 90d', adding essentially nothing beyond the schema — the 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?
The description gives a specific verb and resource — 'One perp market over time' — and enumerates the returned series (price, OI, funding, taker flow, whale net position, book depth, P&L, leverage), so an agent knows exactly what data this yields. It never distinguishes itself from close siblings such as get_perps, get_perps_market, or get_perps_desk, which an agent comparing these four tools would need.
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 supplies concrete trigger phrasings ('X funding this week', 'are whales adding to X', 'how deep is X's book') that map real user intents to this tool, which is stronger than generic context. However it names no alternatives and gives no when-not conditions, so the routing against the other three perps tools is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perps market research and sized trade costs. trade/cost: BTC/ETH entry, holding and exit dollars from fresh books. Funding, OI, whales and advanced supplied-data studies. Use when the user asks: what does my position cost; where can I trade 100x. Not for: one market overview → get_perps. Args: view; workflow; parameters; market; venue.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | whales and liquidation_feed: buys or sells (a short liquidated counts as a buy, a long as a sell). | |
| view | No | trending: where open interest is building over window (1h, 4h or 24h; dollars added, which move with price as well as positions), and the most active markets. movers: the largest price moves up and down over window (5m, 15m, 1h, 4h or 24h). funding: the highest and lowest funding now, annualized (the hour's rate times 8,760, a snapshot) and weighted by open interest, with the venues' settled, running and continuous rates counted. funding_gaps: the same market long on one venue and short on another, what each leg pays or earns after funding and borrow at the latest hourly reading (a snapshot funding spread), each leg's interval and whether its rate is settled or a running estimate, and the two legs' mark-price difference (not executable prices). funding_matrix: every market on every venue, largest open interest first: its funding now (hourly, per 8 hours and annualized), the venue's predicted rate where it publishes one, the funding interval, stablecoin- or coin-margined, and open interest. premium: listings trading furthest above or below the index they settle on (for a stock perp, the stock's price). open_interest: the largest markets by open interest (one side of the market: how much is open, not which way traders lean), with the change over one, four and 24 hours as the site counts it (a listing in whole) and over the markets read at both ends, in USD and in quantity; with venue, that venue's own markets, largest first, and on a pool venue (GMX, gTrade, Jupiter, Ostium, Variational, Vest, Veranta) each market's longs and shorts in USD. liquidations: per market, the dollars of longs and shorts liquidated over window from complete stored hours (stored_comparable_window), most first, with the venues counted and those left out. whales: single trades of $100K or more and single liquidations of $10K or more over window, largest first, plus the newest trades, each market's net whale buying or selling, totals over time, and big accounts' long and short positioning. new_listings: markets venues listed within window. weekend: while US stocks are shut, every stock perp's move since the close (one stock: get_perps). lean: where Hyperliquid's accounts worth $1M or more lean on each market, long against short, with each side's leverage and open profit. hl_cohorts: every Hyperliquid account's positioning across its markets, or one market's with `market`: accounts and dollars long and short, the share of open interest held, and cohorts by account equity and by all-time P&L, each with its accounts in profit and in loss. position_changes: the largest changes in Hyperliquid accounts' positions over window (15m, 1h, 4h or 24h), what each did (opened, added, reduced, closed, flipped) and the account's size cohort, never the account. twaps: Hyperliquid TWAP orders running now, their remaining size and the buying and selling they schedule over the next hour and day. leverage: every perp offered at `leverage` or more, the venues and their caps, and the move that liquidates at each. builds: markets where open interest kept building for two to seven days while the price lagged, ranked. venues: every venue on OptimistFi's perps pages, with its network, settlement, funding interval and markets. hlp: HLP, Hyperliquid's liquidation backstop vault: its account value and cumulative P&L now, its return month by month and year by year, annualized, and its max drawdowns. oi_caps: on Hyperliquid and each of its builder dexes, the markets at their open-interest cap and since when, and each market's cap against its open interest now, nearest the cap first. basis: for one coin (market), each dated future's premium to its index on Deribit, OKX, Kraken and Gate, annualized, and the 90-day constant-maturity basis over 30 days. options: for one coin (market), Deribit's options by expiry: ATM implied volatility (the term structure), 25-delta call and put IVs and skew, call and put open interest and their ratio, volume, max pain (the strike where the expiry's options pay their holders least), open interest by strike, and the 30-day ATM IV and skew over 30 days. market_series: open interest and 24-hour volume in total and per venue over window (24h hourly, 7d every 4 hours, 30d, 90d or 1y daily), the share of BTC, ETH and the rest, each point with the venues it covers, the venues first read inside the window, the like-for-like total over the venues read across all of it (sameVenues), and each venue's liquidations over the hours it recorded. funding_heatmap: funding weighted by open interest, annualized, every 4 hours over the last week, for each market holding $10M or more. returns: how many markets moved how far over window (24h or 7d) in 5% buckets, and the largest gainers and losers with their open-interest change. rsi: RSI(14) on completed hourly, 4-hour and daily closes, each with its last close; window picks the one ranked (1h, 4h, or 24h for daily), or market reads one. sessions: for one market over 30 days, the average return by UTC hour and weekday and the cumulative return of the Asia, Europe and US sessions. liquidation_feed: every single liquidation record the venues publish one by one (event_feed: a record, not a trader), newest first, with the dollars liquidated per coin and per exchange over trailing windows of 1, 4, 12 and 24 hours and each venue's readThrough; it covers other venues and hours than the stored-window liquidations, so the totals differ. cvd: one market's cumulative volume delta per venue and across venues, and its netflow (taker buying less selling) over 1h, 4h, 12h, 24h, 3d and 7d; with no market, the markets with the most net buying and selling. footprint: one market's taker buying and selling at each price, hour by hour. liquidation_max_pain: the price band within 2, 5, 10 or 25% of a market's price where the most perp positions are liquidated, from Hyperliquid's mapped positions (not options max pain); with no market, every mapped market ranked. hyperliquid: Hyperliquid beside its markets, by section: its user count and totals, validators and staking, spot markets, deploy auctions, builder dexes (HIP-3), outcome markets (HIP-4), USDC through its Arbitrum bridge, traders seen, the leaderboard's top 100 by P&L (ranked, never named) and fees. market_overview: per market, open interest and its split by venue, open interest per dollar of volume, market cap, 30-day volume with its change, sector tags and the price change over 5 minutes to a day, ranked by open interest and by 30-day volume. exchanges: per venue, open interest and its share of reported OI, 24-hour volume, liquidations, markets and taker and maker fee, each column ranked on its own. sectors: each sector's open interest, volume and 1-, 7- and 30-day return weighted by open interest. indicators: the technical indicator or index named by `indicator` (one market's TD Sequential, ATR, RSI, MA, EMA, MACD or Bollinger Bands at `interval`; RSI, ATR and MACD lists across markets; Bitfinex margin longs and shorts, borrow rates, futures to spot volume, the altcoin season index; or the catalog of every indicator and its status). btc_cycle: Bitcoin's long-history measures (AHR999, Pi Cycle Top, Golden Ratio Multiplier, 2-Year MA Multiplier, 200-week average, Rainbow, Stock-to-Flow, Puell Multiple, profitable days) and peak signals. fear_greed: our fear and greed index with each of its six inputs. macro: Bitcoin against money supply (M2), its correlations with stocks, gold, the dollar and ether, and the US economic release calendar. etf: every spot ETF on market (BTC, ETH or SOL; a fund ticker such as IBIT for that fund's days, "fund BTC" or "fund ETH" for Grayscale's mini trusts; grayscale for every Grayscale trust), each fund's NAV, shares, net assets, coins held, premium and daily net flow from the issuer's own figures. cot: CFTC Commitments of Traders for market's futures (CME and others), weekly positions by trader group. treasuries: companies holding bitcoin, each count dated and quoted from the SEC filing that states it. orderbook: bids against asks resting within 0.5, 1, 2, 5, 10 and 20% of the mid, per venue and summed across venues, each band's change over 1 hour, 24 hours and 7 days, and the bands over window (for one market), or every market ranked by bid-heavy, ask-heavy, deepest and depth added or pulled in 24 hours. large_orders: every price level resting $100K or more within 10% of the mid, as far as each venue's published book reaches (coverage states the span read), resting now (price, size, side, venue, distance from the mid, size against the market's open interest) and those that ended within window, filled, pulled or unseen, with full counts and totals. orderbook_heatmap: one market's resting dollars by price bucket over window, from its book read every five minutes. week_in_numbers: one week's market-wide figures, frozen once built (period 2026-W42). venue_scorecard: one month's figures per venue (period 2026-10). | trending |
| limit | No | Rows per list, up to 25. | |
| venue | No | One venue id (hyperliquid, dydx, aster, lighter, gmx, …) for whales, new_listings, exchanges, open_interest (that venue's markets, with longs and shorts on a pool venue), large_orders, orderbook_heatmap, liquidation_feed and footprint (that venue's price buckets). | |
| margin | No | funding_matrix only: stablecoin-margined markets (settled in a dollar stablecoin or US dollars), coin-margined (settled in the market's own coin), or either (each position takes a coin or a stablecoin); unset reads every market. | |
| market | No | One market (BTC, NVDA, gold) for whales, funding_gaps, funding_matrix, premium, new_listings, movers, market_overview, oi_caps, funding_heatmap, rsi, hl_cohorts, position_changes, twaps, liquidation_feed, cvd and liquidation_max_pain; the market sessions and footprint read; for basis and options, the coin they read (BTC, ETH, SOL); one spot token or pair (HYPE, HYPE/USDC) for the hyperliquid view's spot section. For etf and cot the asset (BTC by default), for etf also a fund ticker ("fund BTC" for a ticker that is also an asset's) or grayscale. orderbook, large_orders and orderbook_heatmap read one market. Unset reads every market. | |
| offset | No | Rows to skip in each list: with limit, pages through a list's full length (count gives it where a view reports one; funding_matrix pages every row, the other views reach 2,000). | |
| period | No | week_in_numbers: a week, 2026-W42 (Monday 00:00 to Monday 00:00 UTC); venue_scorecard: a month, 2026-10. Unset: the latest closed one; the current one is served marked preview. | |
| proven | No | whales only: true keeps the trades of proven whales, accounts whose large positions kept winning after they were picked. | |
| window | No | Look-back for liquidations, whales, new_listings, liquidation_feed, footprint (1h, 4h or 24h), cvd (24h hourly, 7d in four-hour steps), trending (positions building over 1h, 4h or 24h), position_changes (15m, 1h, 4h or 24h; 7d reads 24h), returns (24h or 7d) and market_series (24h, 7d, 30d, 90d or 1y; only it reads 30d to 1y); rsi's 1h, 4h or 24h picks the closes ranked. movers covers 5m, 15m, 1h, 4h or 24h; funding, funding_gaps, funding_matrix, premium and open_interest, market_overview, exchanges and sectors read the latest reading. orderbook (one market): its history, 1h and 4h from the five-minute reads, 24h hourly, 7d 4-hourly; large_orders: how far back ended levels are listed; orderbook_heatmap: the span drawn. | 24h |
| min_usd | No | whales and liquidation_feed: smallest trade or liquidation in USD; funding_gaps and premium: smallest open interest per listing (default $100K), an open-interest floor; open interest is not order-book depth; large_orders: smallest resting level (default $100K). | |
| section | No | hyperliquid view only: one section in full; unset gives every section's headline. stats: users, volume, open interest. validators: stake, commission, uptime, the active set, total staked over time. spot: every pair's price, 24h volume and supply (market: one pair's hourly history). auctions: the three deploy auctions now and every token's deploy gas. hip3: each builder dex's markets, open interest, volume and net deposits. hip4: outcome markets listed and settled, and contracts traded each day. bridge: daily USDC deposits and withdrawals. users: Hyperliquid's user count and traders seen each day. leaderboard: top 100 by all-time and 30-day P&L. fees: the fee schedule and the Assistance Fund. | |
| interval | No | indicators view: the bar length for a market's indicator or a list (default 1h). | |
| leverage | No | leverage view only: the leverage, one of 5, 10, 20, 50, 100, 200 or 500. | |
| workflow | No | Optional workflow inside this existing tool. trade: fresh supported books. carry: explicit economics; analysis=compare ranks equal-delta spot/perp/dated scenarios. funding: stored settlements or analysis=calendar. risk: supplied shocks/collateral, public wallet scenarios, analysis=hedge_size, or analysis=events for sourced-schedule exposure (future events remain estimated). study: closed trades; analysis=hedge (stored candles), execution (fills/benchmarks), events/conditional (confirmed event evidence with supplied or stored closed prices), or copy_delay (supplied historical visible depth). screen: source=markets, analysis=divergence/crowding research scans, or analysis=monitor_metrics with exact venue/symbol for hourly funding percentile and fixed-instrument OI quantity change. contracts: stored registry; liveRules=true with one venue adds public size/price/margin rules. replay: stored readings; knownAt selects a prospective immutable platform edition, not original vendor known-at history. Funding confidenceBlockObservations controls descriptive block-bootstrap bands. No account writes or notification sends. | |
| indicator | No | indicators view: which one (td, atr, rsi, ma, ema, macd and boll read one market, named by market; the _list ones every market; coinbase_premium is Coinbase's BTC-USD against OKX's BTC-USDT; bitfinex_margin and borrow_rate take a coin as market; catalog lists every indicator with its status). macro view: m2, correlations or calendar; unset reads all three. | |
| parameters | No | Validated workflow inputs. trade analysis=cost: market BTC/ETH, sizesUsd (1-6 sizes), side long/short, holdingHours, maxAgeSeconds default 3; live Hyperliquid/Lighter books, optional feeOverridesBps, or up to four normalized supplied quotes. Entry, hold and same-book exit dollar scenarios; missing costs stay null. trade analysis=execution_choices: supplied bids/asks, quantityBase, feeBps and optional explicit passive/sliced fill fractions. screen analysis=liquidity_resilience: eventAt, horizonsSeconds, frozen bandPriceRangeUsd, samples/cadence or prospective venue/market capture. study analyses: markouts (fills and timed benchmarks), price_discovery (synchronized observations and predeclared lags/clocks), relative_value (return_beta with frozen training), capacity (fixed cohort and entry/exit books), options_context (bounded expiry IV summaries). risk analyses: reference_divergence (native-timed mark/oracle/sized exit), leg_risk (separate standard linear margin pools), crowded_exit (one shared book and explicit cohort). carry analysis=capture reconciles supplied settled funding with oracle notionals and an explicit entitlement boundary. Legacy carry/funding/hedge/events/replay inputs remain supported. No MCP writes; private prospective cost studies are saved through the authenticated website. Source clocks, assumptions and economic receipts accompany results. | |
| asset_class | No | Only this kind of market; unset reads every class. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds only hints ('fresh books', 'fresh supported books', 'supplied-data studies') but omits rate limits, latency, or cost of the expensive 'trade/cost' path. Adequate against annotations, 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?
Front-loads purpose, followed by use cases and the sibling exclusion, with no wasted prose. The trailing arg list is low value (5 of 18) but short. Overall tight and well-ordered.
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 48 views and 11 nested workflow schemas this description is thin; it never explains the workflow/analysis regime beyond 'advanced supplied-data studies'. Since schema coverage is 100% and no output schema exists, the essentials are recoverable from schema, but the routing text alone would leave an agent under-informed about the most complex paths.
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 the schema fully documents all 18 parameters, making 3 the baseline. The description's 'Args: view; workflow; parameters; market; venue.' lists only 5 of 18 without adding meaning, so it neither helps nor hurts.
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?
Opens with a specific framing ('Perps market research and sized trade costs') and explicitly distinguishes itself from the sibling get_perps ('Not for: one market overview'). The breadth of 48 views makes a single precise verb hard, but the two named use cases ('what does my position cost', 'where can I trade 100x') anchor it. Clear rather than tautological.
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 explicit when-to-use examples and a when-not clause routing one-market lookups to get_perps. This is real routing guidance. It stops short of a full 5 because the 11 workflows and 48 views are not disambiguated here, leaving most internal selection to the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perps prop firms from their own pages: rules, challenge prices and live codes, country, platforms, assets, max allocation; a named firm's on-chain hedge book, reserves or payouts. Use when the user asks: prop firm rules; X discount code; cheapest $50K challenge; can Propr pay. Args: firm; rule; account_usd; country; asset; on_chain; max_price_usd.
| Name | Required | Description | Default |
|---|---|---|---|
| firm | No | One firm by name (Breakout, HyroTrader, Propr): its full record, every challenge and its dated rule changes. Unset: a short record per firm. | |
| rule | No | Only firms on one of OptimistFi's rule lists, by its slug. | |
| asset | No | Only firms that offer this asset class. | |
| country | No | Only firms based in this country: where the firm says it operates, else where its contracting company is registered (United Arab Emirates or UAE, United States or US, Cayman Islands). | |
| on_chain | No | true: only firms whose trades execute on an on-chain venue. | |
| account_usd | No | Only challenges of this account size in dollars (50000): each firm's challenges at that size, cheapest to get funded first (the price after any live code plus any fee due on passing), and the firm's offers that cover it. | |
| max_price_usd | No | Only firms whose cheapest published evaluation costs this much or less, in dollars (100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds mild provenance context ('from their own pages', implying self-reported/scraped data), but says nothing about freshness, caching, or coverage limits. With annotations carrying the load, 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?
Front-loaded with the data scope and use cases, which is good, but the prose is a semicolon run-on and the final Args list is pure duplication of a schema that is already 100% documented. Trimming that list would lose nothing.
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 has to sketch the return content; it does (rules, challenge prices, codes, country, platforms, assets, max allocation, on-chain hedge book/reserves/payouts). With 7 optional params, all documented in the schema, and annotations covering the safety profile, an agent has enough to invoke 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 description coverage is 100% and the schema descriptions are rich (e.g., firm, account_usd, country all explain behavior in detail). The trailing 'Args: firm; rule; account_usd; country; asset; on_chain; max_price_usd.' merely repeats parameter names and adds no semantics beyond the schema. Baseline 3 is correct.
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+resource: retrieves prop firm records (rules, challenge prices, live codes, country, platforms, assets) plus a named firm's on-chain hedge book, reserves or payouts. This is clearly distinct from the perps market/desk/history siblings. It stops short of naming those siblings, so an agent must infer the boundary from the noun alone.
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?
Gives concrete trigger utterances: 'prop firm rules', 'X discount code', 'cheapest $50K challenge', 'can Propr pay'. That is strong positive routing. There is no when-not guidance or explicit alternative (e.g., get_perps_market for exchange-side perp data), which keeps it out of 5 territory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The standing investment case for a stock: the thesis, its testable claims with the condition that breaks each, the bear case, catalysts, whether it still holds. Use when the user asks: what's the bull case for X; what would break X's thesis; is X's story holding up. response_mode=plain for beginners. Not for: valuation → answer. Args: entity; view.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | "case" (default): the thesis, its testable claims, the bear case and catalysts; "review": the case re-checked against the latest filings; "story": whether the company's own narrative in its releases matches its reported numbers. | case |
| entity | Yes | The company: a ticker (AAPL, BRK.B), a company name (Apple) or an SEC CIK. | |
| reading_level | No | With response_mode plain, who the explanation is written for: 5 a complete beginner, 10 a general reader, 13 an informed investor (unset reads as 13, with precise figures). | |
| response_mode | No | "standard" (default): the full read with the investment case; "plain": a short beginner-friendly explanation at the reading_level grade. | standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so safety is covered. The description adds useful context beyond that: the response_mode=plain beginner variant and the structured nature of the return (claims, breaking conditions, bear case). It stops short of noting data freshness or auth, so not 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?
Front-loads the resource definition, then use cases, then exclusions and args. Dense but every clause earns its place; the 'Args: entity; view' tail is slightly redundant given the full schema.
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 carries the burden of describing returns, and it does so well (thesis, claims, bear case, catalysts, review/story modes). Combined with complete annotations and 100% param coverage, an agent has nearly everything needed; only freshness/refresh semantics are unaddressed.
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 the schema already documents entity, view, reading_level and response_mode fully. The description only reinforces response_mode=plain and lists 'entity; view', adding marginal meaning beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('standing investment case for a stock') and enumerates exactly what it returns: the thesis, testable claims with breaking conditions, bear case, catalysts, and whether it still holds. It also distinguishes itself from siblings via 'Not for: valuation → answer', so an agent can route 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?
Gives concrete trigger phrases ('what's the bull case for X', 'what would break X's thesis', 'is X's story holding up') and an explicit exclusion with the alternative tool named ('valuation → answer'). When-to-use, when-not, and the fallback are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One metric's recent quarters read against the investment case: the claim it tests, whether it supports or challenges it, and what it cannot prove. item=earnings covers revenue, profit and EPS. Use when the user asks: what do X's earnings mean for the thesis. response_mode=plain for beginners. Not for: the full read → answer. Args: entity; item.
| Name | Required | Description | Default |
|---|---|---|---|
| item | No | The figure to read against the case: "earnings" (revenue, net income and diluted EPS together) or one metric: revenue, net_income, eps_diluted, gross_margin, operating_margin, net_margin, free_cash_flow, operating_cash_flow, ebitda, total_debt, cash, shares_outstanding. | revenue |
| entity | Yes | The company: a ticker (AAPL, BRK.B), a company name (Apple) or an SEC CIK. | |
| reading_level | No | With response_mode plain, who the explanation is written for: 5 a complete beginner, 10 a general reader, 13 an informed investor (unset reads as 13, with precise figures). | |
| response_mode | No | "standard" (default): the full read with the investment case; "plain": a short beginner-friendly explanation at the reading_level grade. | standard |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior, so the bar is lower. The description still adds real context: the output decomposes into the claim tested, the verdict, and explicitly what it cannot prove, plus the item=earnings grouping and the beginner-oriented plain mode.
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?
Purpose is front-loaded and the whole thing is compact. However, the trailing 'Args: entity; item.' duplicates the schema without adding meaning, and the identifier is incomplete (reading_level and response_mode are omitted), making that line low-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?
An output schema exists, so return values need not be explained. The description covers purpose, trigger, exclusion, and the key parameter behaviors; only the cryptic '→ answer' routing and the truncated arg list leave minor 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 100%, so the baseline is 3. The description restates that item=earnings covers revenue, profit and EPS and that response_mode=plain suits beginners, but this largely mirrors what the schema already documents rather than adding new syntax or constraints.
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 operation: reading one metric's recent quarters against the investment case, including what it tests, whether it supports or challenges, and what it cannot prove. It also distinguishes itself from the sibling get_thesis via the 'Not for: the full read' exclusion, though the arrow-to-tool mapping is terse.
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?
Gives an explicit trigger ('Use when the user asks: what do X's earnings mean for the thesis') and an explicit exclusion ('Not for: the full read'). The exclusion points at the alternative but names it only obliquely as 'answer', leaving some inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The dated track record on a company: each filing that crossed or held its thesis's break condition (a dated call if the thesis came first), plus early_warnings from the latest 10-Q's trailing year. Use when the user asks: has OptimistFi been right on X; did X's thesis break. response_mode=plain for beginners. Args: entity.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | The company: a ticker (AAPL, BRK.B), a company name (Apple) or an SEC CIK. | |
| reading_level | No | With response_mode plain, who the explanation is written for: 5 a complete beginner, 10 a general reader, 13 an informed investor (unset reads as 13, with precise figures). | |
| response_mode | No | "standard" (default): the full read with the investment case; "plain": a short beginner-friendly explanation at the reading_level grade. | standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real context on what the record contains (break-condition filings, trailing-year early warnings) and recommends response_mode=plain for beginners, but says nothing about what happens when a company has no thesis, how far back the history goes, or any limits on the result.
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 content definition is front-loaded and the usage triggers follow immediately, with no filler sentences. The opening sentence is dense and jargon-laden ('crossed or held its thesis's break condition'), which costs a little readability but every clause carries 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 three-parameter analytical read with no output schema, the definition explains the conceptual shape of the return (dated calls plus early warnings) well enough to set expectations. The gaps are edge-case behavior – unresolvable entity, no-thesis companies, empty history – which are secondary for this 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?
Schema description coverage is 100%, so entity, reading_level, and response_mode are already fully documented, including the enum values and the default of 13. The description's 'Args: entity' and 'response_mode=plain for beginners' restate rather than extend the schema, so 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 resource (a company's dated track record) and defines its contents precisely: filings that crossed or held a thesis break condition, plus early_warnings from the latest 10-Q trailing year. That scope distinguishes it from siblings like get_thesis, get_filings, and what_changed, though the verb is only implied by the tool name.
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?
Gives concrete trigger questions ('has OptimistFi been right on X', 'did X's thesis break') that tell an agent when to reach for this tool. It does not name an explicit alternative or when-not condition, but the query examples are clear enough to route correctly in most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a ticker, company name or CIK to the canonical company (name, ticker, CIK, FIGI), confirming which company a name means before other tools run. Use when the user asks: which company is X; what's the ticker for X; is X listed. Args: query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A company name, ticker or SEC CIK to identify; returns its name, ticker, CIK and FIGI. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuine value beyond that by positioning the tool as a pre-step that confirms entity identity before other tools run, which is workflow context an agent cannot get from annotations.
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: the capability and its output fields come first, then the trigger conditions. The trailing 'Args: query.' is mildly redundant but costs almost nothing.
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?
An output schema exists so return values need no prose, annotations cover the safety profile, and the one parameter is fully documented. Purpose, triggers and workflow placement are all present; nothing needed to invoke it correctly 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 description coverage is 100% and the single 'query' parameter is fully documented in the schema itself. The description only echoes it with 'Args: query.' and adds no syntax or format detail, so the 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 (Resolve) and resource (ticker, company name or CIK) and names the exact canonical output fields (name, ticker, CIK, FIGI). No sibling tool does entity resolution, so the agent can distinguish it immediately from answer, compare, or get_filings.
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?
Gives concrete trigger phrasings ('which company is X', 'what's the ticker for X', 'is X listed') plus sequencing guidance to run it before other tools. It stops short of naming an explicit alternative or a when-not-to-use case, so it falls just below the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What has happened for a company since a date, read against its case: the latest quarter's earnings, filings and 8-K events, insider trades, capital returns, price move. Use when the user asks: what changed with X; catch me up on X. response_mode=plain for beginners. Not for: the standing case → get_thesis. Args: entity; since.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Window start as an ISO date (YYYY-MM-DD); unset reads the last 30 days. | |
| entity | Yes | The company: a ticker (AAPL, BRK.B), a company name (Apple) or an SEC CIK. | |
| reading_level | No | With response_mode plain, who the explanation is written for: 5 a complete beginner, 10 a general reader, 13 an informed investor (unset reads as 13, with precise figures). | |
| response_mode | No | "standard" (default): the full read with the investment case; "plain": a short beginner-friendly explanation at the reading_level grade. | standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description's job is to add context beyond that. It does: it discloses the enumeration of sources read, the existence of a plain-language mode, and how reading_level interacts with that mode. It stops short of describing pagination, latency, or output shape, which keeps it from 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?
Front-loaded with the data scope, then triggers, then the exclusion — a sound ordering. It is compact, though the trailing 'Args: entity; since.' duplicates the schema and the fragment-heavy style costs a little 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?
With no output schema, the description carries the burden of telling the agent what comes back, and it does so by enumerating the covered sources. Combined with annotations covering safety and 100% schema coverage, an agent has enough to call this correctly; only return-format detail is absent.
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 every parameter (since, entity, reading_level, response_mode) is already documented in the schema. The description's 'Args: entity; since.' and its 'response_mode=plain for beginners' note largely restate schema content, adding only a hint of intent. Baseline 3 is appropriate when the schema does the heavy lifting.
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 a specific verb+resource ('what has happened for a company since a date') and enumerates exactly what the read covers: earnings, filings and 8-K events, insider trades, capital returns, price move. It also distinguishes itself from the sibling get_thesis by framing its scope as a delta since a date rather than a standing case.
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 gives concrete trigger utterances ('what changed with X; catch me up on X') and an explicit exclusion with the correct alternative ('Not for: the standing case → get_thesis'). Both the when and the when-not are stated, so nothing is left to inference.
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_calendar1 field changedInput schema / properties / limit / descriptionPrevious value: -"Most events, nearest first to return."New value: +"Most events: the earnings date first, then readouts nearest first to return."get_insider_trades1 field changedInput schema / properties / limit / descriptionPrevious value: -"Most transactions, newest first to return."New value: +"Most transactions, open-market buys and sales first to return."get_perps_desk3 fields changedInput schema / properties / market / descriptionPrevious value: -"news and traders: one market (BTC, NVDA, gold). tokenized: one company by ticker or name (MSFT, Microsoft)."New value: +"news and traders: one market (BTC, NVDA, gold). tokenized: one company by ticker or name (MSFT, Microsoft). kalshi: BTC or ETH."Input schema / properties / view / descriptionPrevious value: -"news: the desk's published perps stories, newest first. traders: the perps traders directory, with the desk's checked calls on each. wallets: the Hyperliquid wallets the desk has covered, with their stories. account: a fresh public Hyperliquid wallet state on one dex, with positions and margin; wallet is required. tokenized: which companies have blocked tokenized trading of their stock, from each venue's public notice."New value: +"news: the desk's published perps stories, newest first. traders: the perps traders directory, with the desk's checked calls on each. wallets: the Hyperliquid wallets the desk has covered, with their stories. account: a fresh public Hyperliquid wallet state on one dex, with positions and margin; wallet is required. tokenized: which companies have blocked tokenized trading of their stock, from each venue's public notice. kalshi: Kalshi's BTC and ETH odds for the next 5 PM ET close and Friday's beside its perps' funding, read every five minutes, with its daily study of perps volume against open interest."Input schema / properties / view / enumPrevious value: -[
- "news",
- "traders",
- "wallets",
- "account",
- "tokenized"
-]New value: +[
+ "news",
+ "traders",
+ "wallets",
+ "account",
+ "tokenized",
+ "kalshi"
+]get_perps_desk3 fields changedInput schema / properties / market / descriptionPrevious value: -"news and traders: one market (BTC, NVDA, gold)."New value: +"news and traders: one market (BTC, NVDA, gold). tokenized: one company by ticker or name (MSFT, Microsoft)."Input schema / properties / view / descriptionPrevious value: -"news: the desk's published perps stories, newest first. traders: the perps traders directory, with the desk's checked calls on each. wallets: the Hyperliquid wallets the desk has covered, with their stories. account: a fresh public Hyperliquid wallet state on one dex, with positions and margin; wallet is required."New value: +"news: the desk's published perps stories, newest first. traders: the perps traders directory, with the desk's checked calls on each. wallets: the Hyperliquid wallets the desk has covered, with their stories. account: a fresh public Hyperliquid wallet state on one dex, with positions and margin; wallet is required. tokenized: which companies have blocked tokenized trading of their stock, from each venue's public notice."Input schema / properties / view / enumPrevious value: -[
- "news",
- "traders",
- "wallets",
- "account"
-]New value: +[
+ "news",
+ "traders",
+ "wallets",
+ "account",
+ "tokenized"
+]get_perps_market2 fields changedInput schema / properties / parameters / anyOfPrevious value: -[
- {
- "additionalProperties": true,
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "type": "null"
+ },
+ {
+ "not": {
+ "properties": {
+ "analysis": {
+ "enum": [
+ "cost",
+ "execution_choices",
+ "liquidity_resilience",
+ "markouts",
+ "price_discovery",
+ "relative_value",
+ "capacity",
+ "capture",
+ "reference_divergence",
+ "leg_risk",
+ "options_context",
+ "crowded_exit"
+ ]
+ }
+ },
+ "required": [
+ "analysis"
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "analysis": {
+ "const": "cost",
+ "type": "string"
+ },
+ "feeOverridesBps": {
+ "type": "object"
+ },
+ "frontendFeeBps": {
+ "type": "number"
+ },
+ "holdingHours": {
+ "type": "number"
+ },
+ "market": {
+ "type": "string"
+ },
+ "maxAgeSeconds": {
+ "type": "number"
+ },
+ "notionalUsd": {
+ "type": "number"
+ },
+ "quoteToUsd": {
+ "type": "number"
+ },
+ "quotes": {
+ "maxItems": 4,
+ "type": "array"
+ },
+ "side": {
+ "enum": [
+ "long",
+ "short"
+ ],
+ "type": "string"
+ },
+ "sizesUsd": {
+ "items": {
+ "exclusiveMinimum": 0,
+ "maximum": 100000000,
+ "type": "number"
+ },
+ "maxItems": 6,
+ "minItems": 1,
+ "type": "array"
+ },
+ "venues": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 4,
+ "type": "array"
+ },
+ "wallet": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "analysis"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "analysis": {
+ "const": "execution_choices",
+ "type": "string"
+ },
+ "asks": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "bids": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "feeBps": {
+ "type": "number"
+ },
+ "passiveFillFraction": {
+ "type": "number"
+ },
+ "passivePriceUsd": {
+ "type": "number"
+ },
+ "quantityBase": {
+ "type": "number"
+ },
+ "side": {
+ "type": "string"
+ },
+ "slicedFillFraction": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "analysis",
+ "bids",
+ "asks",
+ "quantityBase",
+ "feeBps"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "analysis": {
+ "const": "liquidity_resilience",
+ "type": "string"
+ },
+ "bandPriceRangeUsd": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "eventAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ }
+ ]
+ },
+ "horizonsSeconds": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "knownAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ }
+ ]
+ },
+ "market": {
+ "type": "string"
+ },
+ "maxGapSeconds": {
+ "type": "number"
+ },
+ "quoteToUsd": {
+ "type": "number"
+ },
+ "sampleIntervalSeconds": {
+ "type": "number"
+ },
+ "samples": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "venue": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "analysis",
+ "eventAt",
+ "horizonsSeconds",
+ "bandPriceRangeUsd"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "analysis": {
+ "const": "markouts",
+ "type": "string"
+ },
+ "benchmarks": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "coverageComplete": {
+ "type": "boolean"
+ },
+ "fills": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "fundingPaidUsd": {
+ "type": "number"
+ },
+ "horizonsSeconds": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "maxBenchmarkSkewSeconds": {
+ "type": "number"
+ },
+ "realizedGrossPnlUsd": {
+ "type": "number"
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "venue": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "analysis",
+ "venue",
+ "symbol",
+ "fills",
+ "benchmarks",
+ "horizonsSeconds",
+ "maxBenchmarkSkewSeconds"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "analysis": {
+ "const": "price_discovery",
+ "type": "string"
+ },
+ "clockUncertaintyMs": {
+ "type": "number"
+ },
+ "lagsMs": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "observations": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "sampleIntervalMs": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "analysis",
+ "observations",
+ "lagsMs",
+ "clockUncertaintyMs",
+ "sampleIntervalMs"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "analysis": {
+ "const": "relative_value",
+ "type": "string"
+ },
+ "method": {
+ "const": "return_beta",
+ "type": "string"
+ },
+ "notionalUsd": {
+ "type": "number"
+ },
+ "observations": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "trainFraction": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "analysis",
+ "observations",
+ "method",
+ "trainFraction",
+ "notionalUsd"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "analysis": {
+ "const": "capacity",
+ "type": "string"
+ },
+ "signals": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "sizesUsd": {
+ "maxItems": 2000,
+ "type": "array"
+ }
+ },
+ "required": [
+ "analysis",
+ "signals",
+ "sizesUsd"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "analysis": {
+ "const": "capture",
+ "type": "string"
+ },
+ "borrowCostUsd": {
+ "type": "number"
+ },
+ "boundaryRule": {
+ "type": "string"
+ },
+ "coverageComplete": {
+ "type": "boolean"
+ },
+ "entryAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ }
+ ]
+ },
+ "exitAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ }
+ ]
+ },
+ "roundTripCostUsd": {
+ "type": "number"
+ },
+ "settlements": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "signedQuantityBase": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "analysis",
+ "entryAt",
+ "exitAt",
+ "signedQuantityBase",
+ "settlements",
+ "boundaryRule"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "analysis": {
+ "const": "reference_divergence",
+ "type": "string"
+ },
+ "exit": {
+ "type": "object"
+ },
+ "mark": {
+ "type": "object"
+ },
+ "maxAgeSeconds": {
+ "type": "number"
+ },
+ "maxSkewSeconds": {
+ "type": "number"
+ },
+ "oracle": {
+ "type": "object"
+ }
+ },
+ "required": [
+ "analysis",
+ "mark",
+ "oracle",
+ "exit",
+ "maxAgeSeconds",
+ "maxSkewSeconds"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "accountMode": {
+ "type": "string"
+ },
+ "analysis": {
+ "const": "leg_risk",
+ "type": "string"
+ },
+ "horizonSeconds": {
+ "type": "number"
+ },
+ "legs": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "pools": {
+ "maxItems": 2000,
+ "type": "array"
+ }
+ },
+ "required": [
+ "analysis",
+ "accountMode",
+ "pools",
+ "legs",
+ "horizonSeconds"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "analysis": {
+ "const": "options_context",
+ "type": "string"
+ },
+ "expiries": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "limit": {
+ "type": "number"
+ },
+ "targetDays": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "analysis",
+ "expiries",
+ "targetDays"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "analysis": {
+ "const": "crowded_exit",
+ "type": "string"
+ },
+ "bids": {
+ "maxItems": 2000,
+ "type": "array"
+ },
+ "coverageFraction": {
+ "type": "number"
+ },
+ "depthFraction": {
+ "type": "number"
+ },
+ "participants": {
+ "maxItems": 2000,
+ "type": "array"
+ }
+ },
+ "required": [
+ "analysis",
+ "bids",
+ "participants",
+ "depthFraction",
+ "coverageFraction"
+ ],
+ "type": "object"
+ }
+]Input schema / properties / parameters / descriptionPrevious value: -"Workflow inputs. carry: hours, collateralUsd, legs (notionalUsd, side, own_side_pays funding convention/rate/state, borrow, entry/exit fees INCLUDING builder fees and rebates, and slippage in bps). trade: notionalUsd, side buy/sell, venue, maxAgeSeconds, optional includeDepth. funding: exact venue/symbol plus optional start/end (up to 90 days), or analysis=calendar, market, notionalUsd, side long/short. Stored funding defaults to compact statistics; includeEvents adds the ledger. Other workflows require explicit records; missing inputs return a readable error."New value: +"Validated workflow inputs. trade analysis=cost: market BTC/ETH, sizesUsd (1-6 sizes), side long/short, holdingHours, maxAgeSeconds default 3; live Hyperliquid/Lighter books, optional feeOverridesBps, or up to four normalized supplied quotes. Entry, hold and same-book exit dollar scenarios; missing costs stay null. trade analysis=execution_choices: supplied bids/asks, quantityBase, feeBps and optional explicit passive/sliced fill fractions. screen analysis=liquidity_resilience: eventAt, horizonsSeconds, frozen bandPriceRangeUsd, samples/cadence or prospective venue/market capture. study analyses: markouts (fills and timed benchmarks), price_discovery (synchronized observations and predeclared lags/clocks), relative_value (return_beta with frozen training), capacity (fixed cohort and entry/exit books), options_context (bounded expiry IV summaries). risk analyses: reference_divergence (native-timed mark/oracle/sized exit), leg_risk (separate standard linear margin pools), crowded_exit (one shared book and explicit cohort). carry analysis=capture reconciles supplied settled funding with oracle notionals and an explicit entitlement boundary. Legacy carry/funding/hedge/events/replay inputs remain supported. No MCP writes; private prospective cost studies are saved through the authenticated website. Source clocks, assumptions and economic receipts accompany results."get_perps_market1 field changedInput schema / properties / view / descriptionPrevious value: -"trending: where open interest is building over window (1h, 4h or 24h; dollars added, which move with price as well as positions), and the most active markets. movers: the largest price moves up and down over window (5m, 15m, 1h, 4h or 24h). funding: the highest and lowest funding now, annualized (the hour's rate times 8,760, a snapshot) and weighted by open interest, with the venues' settled, running and continuous rates counted. funding_gaps: the same market long on one venue and short on another, what each leg pays or earns after funding and borrow at the latest hourly reading (a snapshot funding spread), each leg's interval and whether its rate is settled or a running estimate, and the two legs' mark-price difference (not executable prices). funding_matrix: every market on every venue, largest open interest first: its funding now (hourly, per 8 hours and annualized), the venue's predicted rate where it publishes one, the funding interval, stablecoin- or coin-margined, and open interest. premium: listings trading furthest above or below the index they settle on (for a stock perp, the stock's price). open_interest: the largest markets by open interest (one side of the market: how much is open, not which way traders lean), with the change over one, four and 24 hours as the site counts it (a listing in whole) and over the markets read at both ends, in USD and in quantity; with venue, that venue's own markets, largest first, and on a pool venue (GMX, gTrade, Jupiter, Ostium, Variational, Vest, Veranta) each market's longs and shorts in USD. liquidations: per market, the dollars of longs and shorts liquidated over window from complete stored hours (stored_comparable_window), most first, with the venues counted and those left out. whales: single trades of $100K or more and single liquidations of $10K or more over window, largest first, plus the newest trades, each market's net whale buying or selling, totals over time, and big accounts' long and short positioning. new_listings: markets venues listed within window. weekend: while US stocks are shut, every stock perp's move since the close (one stock: get_perps). lean: where Hyperliquid's accounts worth $1M or more lean on each market, long against short, with each side's leverage and open profit. hl_cohorts: every Hyperliquid account's positioning across its markets, or one market's with `market`: accounts and dollars long and short, the share of open interest held, and cohorts by account equity and by all-time P&L, each with its accounts in profit and in loss. position_changes: the largest changes in Hyperliquid accounts' positions over window (15m, 1h, 4h or 24h), what each did (opened, added, reduced, closed, flipped) and the account's size cohort, never the account. twaps: Hyperliquid TWAP orders running now, their remaining size and the buying and selling they schedule over the next hour and day. leverage: every perp offered at `leverage` or more, the venues and their caps, and the move that liquidates at each. builds: markets where open interest kept building for two to seven days while the price lagged, ranked. venues: every venue on OptimistFi's perps pages, with its network, settlement, funding interval and markets. hlp: HLP, Hyperliquid's liquidation backstop vault: its account value and cumulative P&L now, its return month by month and year by year, annualized, and its max drawdowns. oi_caps: on Hyperliquid and each of its builder dexes, the markets at their open-interest cap and since when, and each market's cap against its open interest now, nearest the cap first. basis: for one coin (market), each dated future's premium to its index on Deribit, OKX, Kraken and Gate, annualized, and the 90-day constant-maturity basis over 30 days. options: for one coin (market), Deribit's options by expiry: ATM implied volatility (the term structure), 25-delta call and put IVs and skew, call and put open interest and their ratio, volume, max pain (the strike where the expiry's options pay their holders least), open interest by strike, and the 30-day ATM IV and skew over 30 days. market_series: open interest and 24-hour volume in total and per venue over window (24h hourly, 7d every 4 hours, 30d, 90d or 1y daily), the share of BTC, ETH and the rest, each point with the venues it covers, the venues first read inside the window, the like-for-like total over the venues read across all of it (sameVenues), and each venue's liquidations over the hours it recorded. funding_heatmap: funding weighted by open interest, annualized, every 4 hours over the last week, for each market holding $10M or more. returns: how many markets moved how far over window (24h or 7d) in 5% buckets, and the largest gainers and losers with their open-interest change. rsi: RSI(14) on completed hourly, 4-hour and daily closes, each with its last close; window picks the one ranked (1h, 4h, or 24h for daily), or market reads one. sessions: for one market over 30 days, the average return by UTC hour and weekday and the cumulative return of the Asia, Europe and US sessions. liquidation_feed: every single liquidation record the venues publish one by one (event_feed: a record, not a trader), newest first, with the dollars liquidated per coin and per exchange over trailing windows of 1, 4, 12 and 24 hours and each venue's readThrough; it covers other venues and hours than the stored-window liquidations, so the totals differ. cvd: one market's cumulative volume delta per venue and across venues, and its netflow (taker buying less selling) over 1h, 4h, 24h and 7d; with no market, the markets with the most net buying and selling. footprint: one market's taker buying and selling at each price, hour by hour. liquidation_max_pain: the price band within 2, 5, 10 or 25% of a market's price where the most perp positions are liquidated, from Hyperliquid's mapped positions (not options max pain); with no market, every mapped market ranked. hyperliquid: Hyperliquid beside its markets, by section: its user count and totals, validators and staking, spot markets, deploy auctions, builder dexes (HIP-3), outcome markets (HIP-4), USDC through its Arbitrum bridge, traders seen, the leaderboard's top 100 by P&L (ranked, never named) and fees. market_overview: per market, open interest and its split by venue, open interest per dollar of volume, market cap, 30-day volume with its change, sector tags and the price change over 5 minutes to a day, ranked by open interest and by 30-day volume. exchanges: per venue, open interest and its share of reported OI, 24-hour volume, liquidations, markets and taker and maker fee, each column ranked on its own. sectors: each sector's open interest, volume and 1-, 7- and 30-day return weighted by open interest. indicators: the technical indicator or index named by `indicator` (one market's TD Sequential, ATR, RSI, MA, EMA, MACD or Bollinger Bands at `interval`; RSI, ATR and MACD lists across markets; Bitfinex margin longs and shorts, borrow rates, futures to spot volume, the altcoin season index; or the catalog of every indicator and its status). btc_cycle: Bitcoin's long-history measures (AHR999, Pi Cycle Top, Golden Ratio Multiplier, 2-Year MA Multiplier, 200-week average, Rainbow, Stock-to-Flow, Puell Multiple, profitable days) and peak signals. fear_greed: our fear and greed index with each of its six inputs. macro: Bitcoin against money supply (M2), its correlations with stocks, gold, the dollar and ether, and the US economic release calendar. etf: every spot ETF on market (BTC, ETH or SOL; a fund ticker such as IBIT for that fund's days, \"fund BTC\" or \"fund ETH\" for Grayscale's mini trusts; grayscale for every Grayscale trust), each fund's NAV, shares, net assets, coins held, premium and daily net flow from the issuer's own figures. cot: CFTC Commitments of Traders for market's futures (CME and others), weekly positions by trader group. treasuries: companies holding bitcoin, each count dated and quoted from the SEC filing that states it. orderbook: bids against asks resting within 0.5, 1, 2, 5, 10 and 20% of the mid, per venue and summed across venues, each band's change over 1 hour, 24 hours and 7 days, and the bands over window (for one market), or every market ranked by bid-heavy, ask-heavy, deepest and depth added or pulled in 24 hours. large_orders: every price level resting $100K or more within 10% of the mid, as far as each venue's published book reaches (coverage states the span read), resting now (price, size, side, venue, distance from the mid, size against the market's open interest) and those that ended within window, filled, pulled or unseen, with full counts and totals. orderbook_heatmap: one market's resting dollars by price bucket over window, from its book read every five minutes. week_in_numbers: one week's market-wide figures, frozen once built (period 2026-W42). venue_scorecard: one month's figures per venue (period 2026-10)."New value: +"trending: where open interest is building over window (1h, 4h or 24h; dollars added, which move with price as well as positions), and the most active markets. movers: the largest price moves up and down over window (5m, 15m, 1h, 4h or 24h). funding: the highest and lowest funding now, annualized (the hour's rate times 8,760, a snapshot) and weighted by open interest, with the venues' settled, running and continuous rates counted. funding_gaps: the same market long on one venue and short on another, what each leg pays or earns after funding and borrow at the latest hourly reading (a snapshot funding spread), each leg's interval and whether its rate is settled or a running estimate, and the two legs' mark-price difference (not executable prices). funding_matrix: every market on every venue, largest open interest first: its funding now (hourly, per 8 hours and annualized), the venue's predicted rate where it publishes one, the funding interval, stablecoin- or coin-margined, and open interest. premium: listings trading furthest above or below the index they settle on (for a stock perp, the stock's price). open_interest: the largest markets by open interest (one side of the market: how much is open, not which way traders lean), with the change over one, four and 24 hours as the site counts it (a listing in whole) and over the markets read at both ends, in USD and in quantity; with venue, that venue's own markets, largest first, and on a pool venue (GMX, gTrade, Jupiter, Ostium, Variational, Vest, Veranta) each market's longs and shorts in USD. liquidations: per market, the dollars of longs and shorts liquidated over window from complete stored hours (stored_comparable_window), most first, with the venues counted and those left out. whales: single trades of $100K or more and single liquidations of $10K or more over window, largest first, plus the newest trades, each market's net whale buying or selling, totals over time, and big accounts' long and short positioning. new_listings: markets venues listed within window. weekend: while US stocks are shut, every stock perp's move since the close (one stock: get_perps). lean: where Hyperliquid's accounts worth $1M or more lean on each market, long against short, with each side's leverage and open profit. hl_cohorts: every Hyperliquid account's positioning across its markets, or one market's with `market`: accounts and dollars long and short, the share of open interest held, and cohorts by account equity and by all-time P&L, each with its accounts in profit and in loss. position_changes: the largest changes in Hyperliquid accounts' positions over window (15m, 1h, 4h or 24h), what each did (opened, added, reduced, closed, flipped) and the account's size cohort, never the account. twaps: Hyperliquid TWAP orders running now, their remaining size and the buying and selling they schedule over the next hour and day. leverage: every perp offered at `leverage` or more, the venues and their caps, and the move that liquidates at each. builds: markets where open interest kept building for two to seven days while the price lagged, ranked. venues: every venue on OptimistFi's perps pages, with its network, settlement, funding interval and markets. hlp: HLP, Hyperliquid's liquidation backstop vault: its account value and cumulative P&L now, its return month by month and year by year, annualized, and its max drawdowns. oi_caps: on Hyperliquid and each of its builder dexes, the markets at their open-interest cap and since when, and each market's cap against its open interest now, nearest the cap first. basis: for one coin (market), each dated future's premium to its index on Deribit, OKX, Kraken and Gate, annualized, and the 90-day constant-maturity basis over 30 days. options: for one coin (market), Deribit's options by expiry: ATM implied volatility (the term structure), 25-delta call and put IVs and skew, call and put open interest and their ratio, volume, max pain (the strike where the expiry's options pay their holders least), open interest by strike, and the 30-day ATM IV and skew over 30 days. market_series: open interest and 24-hour volume in total and per venue over window (24h hourly, 7d every 4 hours, 30d, 90d or 1y daily), the share of BTC, ETH and the rest, each point with the venues it covers, the venues first read inside the window, the like-for-like total over the venues read across all of it (sameVenues), and each venue's liquidations over the hours it recorded. funding_heatmap: funding weighted by open interest, annualized, every 4 hours over the last week, for each market holding $10M or more. returns: how many markets moved how far over window (24h or 7d) in 5% buckets, and the largest gainers and losers with their open-interest change. rsi: RSI(14) on completed hourly, 4-hour and daily closes, each with its last close; window picks the one ranked (1h, 4h, or 24h for daily), or market reads one. sessions: for one market over 30 days, the average return by UTC hour and weekday and the cumulative return of the Asia, Europe and US sessions. liquidation_feed: every single liquidation record the venues publish one by one (event_feed: a record, not a trader), newest first, with the dollars liquidated per coin and per exchange over trailing windows of 1, 4, 12 and 24 hours and each venue's readThrough; it covers other venues and hours than the stored-window liquidations, so the totals differ. cvd: one market's cumulative volume delta per venue and across venues, and its netflow (taker buying less selling) over 1h, 4h, 12h, 24h, 3d and 7d; with no market, the markets with the most net buying and selling. footprint: one market's taker buying and selling at each price, hour by hour. liquidation_max_pain: the price band within 2, 5, 10 or 25% of a market's price where the most perp positions are liquidated, from Hyperliquid's mapped positions (not options max pain); with no market, every mapped market ranked. hyperliquid: Hyperliquid beside its markets, by section: its user count and totals, validators and staking, spot markets, deploy auctions, builder dexes (HIP-3), outcome markets (HIP-4), USDC through its Arbitrum bridge, traders seen, the leaderboard's top 100 by P&L (ranked, never named) and fees. market_overview: per market, open interest and its split by venue, open interest per dollar of volume, market cap, 30-day volume with its change, sector tags and the price change over 5 minutes to a day, ranked by open interest and by 30-day volume. exchanges: per venue, open interest and its share of reported OI, 24-hour volume, liquidations, markets and taker and maker fee, each column ranked on its own. sectors: each sector's open interest, volume and 1-, 7- and 30-day return weighted by open interest. indicators: the technical indicator or index named by `indicator` (one market's TD Sequential, ATR, RSI, MA, EMA, MACD or Bollinger Bands at `interval`; RSI, ATR and MACD lists across markets; Bitfinex margin longs and shorts, borrow rates, futures to spot volume, the altcoin season index; or the catalog of every indicator and its status). btc_cycle: Bitcoin's long-history measures (AHR999, Pi Cycle Top, Golden Ratio Multiplier, 2-Year MA Multiplier, 200-week average, Rainbow, Stock-to-Flow, Puell Multiple, profitable days) and peak signals. fear_greed: our fear and greed index with each of its six inputs. macro: Bitcoin against money supply (M2), its correlations with stocks, gold, the dollar and ether, and the US economic release calendar. etf: every spot ETF on market (BTC, ETH or SOL; a fund ticker such as IBIT for that fund's days, \"fund BTC\" or \"fund ETH\" for Grayscale's mini trusts; grayscale for every Grayscale trust), each fund's NAV, shares, net assets, coins held, premium and daily net flow from the issuer's own figures. cot: CFTC Commitments of Traders for market's futures (CME and others), weekly positions by trader group. treasuries: companies holding bitcoin, each count dated and quoted from the SEC filing that states it. orderbook: bids against asks resting within 0.5, 1, 2, 5, 10 and 20% of the mid, per venue and summed across venues, each band's change over 1 hour, 24 hours and 7 days, and the bands over window (for one market), or every market ranked by bid-heavy, ask-heavy, deepest and depth added or pulled in 24 hours. large_orders: every price level resting $100K or more within 10% of the mid, as far as each venue's published book reaches (coverage states the span read), resting now (price, size, side, venue, distance from the mid, size against the market's open interest) and those that ended within window, filled, pulled or unseen, with full counts and totals. orderbook_heatmap: one market's resting dollars by price bucket over window, from its book read every five minutes. week_in_numbers: one week's market-wide figures, frozen once built (period 2026-W42). venue_scorecard: one month's figures per venue (period 2026-10)."answercompareget_calendarget_capital_returnsget_congress_tradesget_filingsget_insider_tradesget_perpsget_perps_deskget_perps_historyget_perps_marketget_prop_firmsget_thesisget_thesis_impactget_track_recordresolve_entitywhat_changedExchange-exact crypto derivatives data for AI agents: OI, funding, liquidations, 13 venues, 42 tools
Crypto perps for AI agents: funding, OI, liquidations, order book, CVD, volume profile, footprint.
Read-only perp funding, OI and positioning across 4 onchain venues. Not financial advice.
Hyperliquid perp funding, OI, preflight & news sentiment for agents. Pay per call in USDC (x402).
Add one secure layer between your agents and this server.
