Perpetual futures across 40 venues, perps prop firms and sourced theses on 6,100+ US stocks.
Scored across 17 tools
Most tools have clearly distinct targets (filings vs insider vs congress trades vs perps market/history/market-wide). However, answer, get_thesis, get_thesis_impact, and what_changed all orbit the same 'investment case' concept, and a full answer largely subsumes what_changed. The explicit 'Not for:' routing in each description rescues most of this overlap.
13 of 17 tools follow a clean get_<noun> pattern (get_filings, get_insider_trades, get_perps_market). The outliers (answer, compare, what_changed, resolve_entity) break the verb_noun convention but are still readable and purposeful. Minor deviation, not chaotic.
17 tools is at the upper edge of comfortable but justified given the dual stock+perps scope plus congress, prop firms, and entity resolution. No obvious redundancy that could be cut without losing a real capability.
Strong lifecycle coverage: entity resolution, thesis, valuation via answer, filings, insider/congress trades, capital returns, calendar, track record, and a deep perps surface. Minor gaps like no standalone valuation tool and no company/search discovery beyond resolve_entity, but core workflows are covered.
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, nearest first: the next earnings date projected from its own filing cadence (held, not rolled, marked overdue when lapsed) and trial readouts. 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, 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 already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description instead adds genuinely non-obvious behavior: dates are projected from the company's own filing cadence, 'held, not rolled', and marked overdue when lapsed. Ordering (nearest first) is also stated. It stops short of failure modes or coverage limits, 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 and ordering, then usage, then exclusions — a sensible order with no filler. The closing 'Args:' list is redundant with a 100%-covered schema and is the one part that does not 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 format need not be described, and annotations cover the safety profile. What remains — what the events are, how they are derived, ordering, and routing against siblings — is all present, so nothing an agent needs to call 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 each parameter already documents itself (limit, types with both enum values, entity formats). The trailing 'Args: entity; types; limit' merely restates the schema and adds no new meaning, 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 ('upcoming dated events for a company') with concrete content: next projected earnings date and trial readouts. It explicitly names the siblings it is not (get_filings for past events, answer for actual results), 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 literal user phrasings that select this tool ('when does X report next', 'what's coming up for X') and an explicit not-for clause with the correct alternative for each excluded case. Both when-to-use and when-not are covered.
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 transactions for one company, newest 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, newest 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 genuinely new behavioral context: newest-first ordering and the transaction-code semantics (P buy, S sell, A grant, M exercise, F tax), which an agent cannot derive from structured fields. It stops short of stating pagination/limit behavior or result completeness (e.g., whether the list is truncated).
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 purpose, then triggers, then exclusions — a good ordering with no filler prose. The trailing 'Args: entity; start; end; limit' line is redundant given 100% schema coverage and is the one part that does not 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?
An output schema exists so return values need no explanation, yet the description still names the key returned fields and code meanings. Combined with explicit triggers, exclusions, and full annotation coverage, an agent has everything needed to select and 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 coverage is 100% and every parameter (entity, start, end, limit) is documented in the schema itself, so the baseline is 3. The description only restates the parameter names in an 'Args:' list without adding format, defaults, or filtering semantics beyond what the schema already says.
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 (Form 4 insider transactions) plus scope ('for one company, newest first') and enumerates the returned fields and code legend. This is enough to distinguish it from get_congress_trades and every other sibling 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 user-phrasing triggers ('are insiders buying X', 'did X's CEO sell', 'insider activity at X') and an explicit exclusion routing to the alternative ('Not for: Congress → get_congress_trades'). Nothing about when-to-use 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.
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 |
|---|---|---|---|
| entity | Yes | The market: a ticker or symbol (NVDA, BTC, XAU), a company name (Tesla) or a common asset name (bitcoin, gold, crude oil). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent, read-only, open-world lookup, so the safety burden is covered. The description adds the meaningful behavioral trait that this is a point-in-time snapshot ('right now') versus the history tool, and enumerates the data surface the agent will receive. It stops short of noting unknown-ticker handling or how the entity is resolved (a sibling resolve_entity exists), so not a full 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 and bounded to three compact clauses, with every sentence earning its place. The dense field list is slightly list-heavy but directly informs the agent about coverage 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 compensates by enumerating the returned data fields and the single-entity snapshot scope, and it routes the agent to the right sibling for history/depth. Missing only edge-case handling for unresolvable entities, a minor gap for a one-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'entity' parameter has 100% schema description coverage, including example forms (ticker, company name, common asset name), so the schema does the heavy lifting. The description only restates 'Args: entity' and adds no syntax, normalization, or ambiguity guidance 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?
Names a specific verb and resource — a single perp market snapshot, 'venue by venue' — and then enumerates the exact fields returned (price/premium, open interest, funding, max leverage, liquidation levels, whale trades, positioning). It explicitly distinguishes itself from the sibling get_perps_history, 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 concrete trigger examples ('X funding rate', 'where do X longs get liquidated') plus an explicit exclusion with the correct alternative ('Not for: trends or book depth → get_perps_history'). The when-to-use and when-not-to-use are both 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.
OptimistFi's perps desk: its stories, the traders directory with checked calls, and the Hyperliquid wallets it covered. Use when the user asks: latest perps news on X; is trader Y worth following. Args: view; market; trader; wallet; limit.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | news |
| limit | No | Rows, up to 25. | |
| market | No | news and traders: one market (BTC, NVDA, gold). | |
| trader | No | traders: one trader by name or X handle. | |
| wallet | No | wallets: one 0x address; adds what it holds now. |
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 only a small behavioral nugget — the wallet view 'adds what it holds now' — and says nothing about freshness, coverage windows, or result ordering beyond 'newest first' already in the view enum.
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 usage triggers, then args — a sensible priority order with little waste. The arg list is slightly telegraphic ('Args: view; market; trader; wallet; limit') but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all three views, the trigger scenarios, and every parameter name, which is adequate for a read-only tool with no output schema. Missing pieces are minor: no indication of what a returned row contains or how the views relate to the sibling perps tools.
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 itself explains each view, the market/trader/wallet filters, and the limit cap of 25 rows. The description merely restates the argument names ('view; market; trader; wallet; limit') without adding syntax or semantics 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 ('perps desk') and enumerates its contents: stories, traders directory with checked calls, and covered Hyperliquid wallets. An agent can tell it apart from get_perps_market or get_perps_history by the desk-coverage framing, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger examples ('latest perps news on X', 'is trader Y worth following') that map directly to the news and traders views. It stops short of stating when NOT to use it or which sibling to prefer for overlapping data.
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 across ~1,600 assets: trending, movers, funding, funding_gaps, premium, open_interest, liquidations, whales, new_listings, weekend, lean, leverage, builds, venues, market_series, funding_heatmap, returns, rsi, sessions. Use when the user asks: where can I trade 100x. Not for: one market → get_perps. Args: view; window; 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, 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). | 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. | |
| 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. | |
| 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?
With annotations already covering read-only, idempotent and non-destructive behavior, the description adds rich operational context: snapshot vs stored windows, venue coverage gaps between liquidations and liquidation_feed, pagination limits, and how totals can differ. This is well beyond what annotations provide and gives an agent useful behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a massive, largely undifferentiated wall of text that duplicates the view enum descriptions already present in the input schema. It is not front-loaded with the high-level purpose, and most of the length does not earn its place against structured fields.
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 highly complex, 16-parameter tool with no output schema, the description still conveys enough about view semantics, windowing, and scoping exclusions for an agent to call it correctly. Annotations cover safety, and the schema covers all parameters, so nothing essential 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%, so the schema already documents all 16 parameters in detail. The description's 'Args: view; window; market; venue' line is redundant and incomplete, adding no meaning beyond what the schema provides; 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?
The description states the resource and scope precisely: 'Perps across ~1,600 assets' and enumerates the views/data families it exposes. It also distinguishes itself from the sibling get_perps by explicitly saying 'Not for: one market → get_perps', so an agent can tell the two apart.
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 one narrow use case ('where can I trade 100x') and one exclusion ('one market → get_perps'), but does not guide selection among the many views or against other siblings like get_perps_desk and get_perps_history. The implication is that the view list itself suggests usage, which is only partial guidance.
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, each challenge's price after any live code, discount codes, country, platforms, assets, max allocation. Use when the user asks: crypto prop firm rules; X discount code; cheapest $50K challenge; prop firms in the UAE. 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 readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds meaningful context beyond that: the data comes 'from their own pages' and prices are 'after any live code', disclosing sourcing and price-computation semantics. No rate limits or pagination are mentioned, but the bar is lower with full annotation coverage.
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 and content before the usage triggers, and the whole thing is compact. The trailing 'Args:' enumeration is largely redundant against a 100%-documented schema, a minor waste, but overall the structure is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, all-optional filter tool with no output schema, the description usefully enumerates the returned fields (rules, discount codes, prices, platforms), which compensates for the missing output schema. Enough to call correctly, though it could clarify result shape per cold vs. filtered queries.
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 richer than the tool description itself (e.g. account_usd, country, rule all have detailed semantics). The description merely re-lists the argument names ('firm; rule; account_usd; country; asset; on_chain; max_price_usd') without adding meaning. 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 resource (perps prop firms) and enumerates the data returned: rules, challenge prices after live codes, discount codes, country, platforms, assets, max allocation. The title reinforces the domain (perpetual futures prop firms), clearly distinct from the perps market/history siblings. It does not explicitly name a sibling to differentiate against, keeping it at 4.
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 concrete trigger queries ('crypto prop firm rules', 'X discount code', 'cheapest $50K challenge', 'prop firms in the UAE') that map well onto the filters. This is strong when-to-use guidance, though it names no excluded cases or alternative tools.
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.
OptimistFi's dated track record on a company: each time a filing crossed or held its thesis's break condition. A crossing whose thesis predates the filing is a genuine call, dated before the event. 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 readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds interpretive domain context (a crossing whose thesis predates the filing is a genuine call), but says nothing about auth needs, rate limits, latency, or result volume. Useful but not rich behavioral disclosure.
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 core purpose and keeps the whole thing to a short paragraph. The trailing 'Args: entity' is redundant filler given the schema, which keeps it from being maximally tight, but overall it is efficient 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?
With no output schema, the description carries the burden of explaining returns and does so: a dated sequence of thesis break-condition crossings. It covers purpose, trigger, and interpretation, and only the sibling-alternative routing is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters including the reading_level/response_mode interaction are already documented. The description only restates 'Args: entity' and notes response_mode=plain for beginners, adding no syntax or format detail beyond the schema. 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?
Specific verb+resource: a dated track record of each time a filing crossed or held its thesis's break condition, with the notion of a 'genuine call' defined. This is clearly distinguishable from siblings like get_thesis, get_thesis_impact, and what_changed, which an agent could otherwise confuse it with.
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 triggering questions: 'has OptimistFi been right on X' and 'did X's thesis break.' That is clear context for selection. It stops short of naming the sibling alternatives (e.g., get_thesis_impact vs what_changed) that would let an agent disambiguate mechanically.
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.
answercompareget_calendarget_capital_returnsget_congress_tradesget_filingsget_insider_tradesget_perpsget_perps_deskget_perps_historyget_perps_marketget_prop_firmsget_thesisget_thesis_impactget_track_recordresolve_entitywhat_changedCrypto perps for AI agents: funding, OI, liquidations, order book, CVD, volume profile, footprint.
Live market data, financial analysis, and portfolio research tools across 10,000+ tickers.
Live prices, perps, prediction markets and a paper trading desk over one MCP.
Keyless prediction-market data across 12 venues plus paper-trading of crypto spot, futures, and PM.
Add one secure layer between your agents and this server.
