Everstrike

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

No annotations are supplied, so the description carries the full behavioral burden. It reveals the returned fields (precision, deposit/withdrawal status, network info) but never states that this is a read-only, parameterless, static reference lookup, nor whether results are cached or reflect live chain state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short fragment with no padding, but it is grammatically incomplete (missing subject/verb) and reads like a field list rather than a statement of purpose. The key information is at least front-loaded.

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 zero-parameter listing tool with no output schema, the description should at minimum convey the full return shape and how it differs from the pairs endpoint. It lists three returned field groups, which is partially sufficient, but the missing sibling differentiation leaves a real gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate at the argument level; baseline 4 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 phrase 'Supported assets' identifies the resource, and the trailing details hint at reference data about tradable assets. However, there is no verb, and nothing distinguishes it from the sibling everstrike_pairs, which an agent could easily confuse with an asset-listing tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to call this versus everstrike_pairs, everstrike_globals, or everstrike_status, and no stated preconditions. The agent must infer usage entirely from the noun phrase.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It usefully clarifies that bids and asks are aggregated, but does not state that the operation is read-only, whether it returns a current snapshot, or whether depth or refresh limits apply.

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 single sentence is front-loaded, unambiguous, and contains no filler. It communicates aggregation, both sides of the book, and per-market scope very efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool, the rich pair schema supplies most invocation requirements, including naming and error-suggestion behavior. With no output schema, however, the terse description leaves response structure, aggregation levels or depth limits, and snapshot semantics unspecified.

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 pair parameter has 100% schema coverage, including perpetual naming conventions, accepted friendly forms, suggestions for unknown markets, and canonical discovery through everstrike_pairs. The description adds only the one-market scope and no parameter meaning beyond that comprehensive 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 clearly identifies the resource as aggregated bid/ask depth and limits its scope to one market. This conveys the order-book purpose, though it lacks an explicit retrieval verb and direct differentiation from siblings such as everstrike_ticker or everstrike_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?

The wording implies use when an agent needs order-book depth for a single market, but provides no explicit when-to-use, when-not, or sibling comparison. The schema's pointer to everstrike_pairs helps select a market, not choose between market-data tools.

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

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

No annotations are supplied, so the description carries the full behavioral burden and does very little with it. It does not state whether this is read-only, what time range or granularity the history covers, whether results are paginated or truncated, or how failures are reported — all material for calling it correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short, front-loaded sentence with no filler, which is efficient. The brevity is close to under-specification rather than verbosity, so it does not earn a 5 but wastes 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?

With no output schema and no annotations, the description is the only place behavioral detail could live, and it omits the return shape, time coverage, and granularity of the funding history. The optional 'pair' parameter also leaves open what happens when it is omitted, which the description never addresses.

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 'pair' parameter is thoroughly documented in the schema, including QUOTE-FIRST keying, fuzzy form resolution, and the suggestion behavior. The description adds nothing beyond that, 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?

The description names a specific resource ('Historical funding rates') and a specific scope ('perpetual markets'), which is enough to tell it apart from siblings like everstrike_ohlcv or everstrike_trades. It stops short of explicitly naming those alternatives, so it lands at 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance at all: no mention of what window of history is returned, whether the pair is required to narrow results, or which sibling to use for current funding versus historical funding. The only cue is the implicit 'historical' framing, which an agent must infer.

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

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

No annotations are provided, so the description carries the full burden, yet it says nothing about whether this is a read-only snapshot, how fresh the data is, the aggregation window, or whether any auth is needed. For a zero-parameter read tool the risk is low, but the behavioral picture is essentially undocumented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no filler, front-loading the resource and then the measures. It is efficient, though it reads as a fragment and leaves key scoping details unstated rather than merely brief.

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 and no parameters, the description is the only source of return-value information, and it names three example metrics without saying whether the list is exhaustive, whether values are a point-in-time snapshot or cumulative, or what units they use. It is adequate to identify the tool's subject but not to interpret the response confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline applies. The listed metrics are the only semantic content available, and they do not need parameter explanation.

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 (aggregate exchange statistics) and enumerates the measures returned (open interest, volume, user counts), which distinguishes it from sibling topic tools such as everstrike_depth or everstrike_funding. It lacks a verb and does not explicitly contrast itself with any sibling, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like everstrike_ticker or everstrike_status, and no stated preconditions. The agent must infer its role from the sibling names alone.

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

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

With no annotations supplied, the description carries the load and does real work: it declares the default price basis as mark, explains why (last-traded goes stale on thin markets), and states that omitting start/end returns the most recent candles. It doesn't cover ordering, pagination/truncation behavior when a range exceeds the 500-candle cap, or error behavior for unknown pairs (though the schema covers that last point).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with what the tool returns, then the default and its rationale, then the timestamp convention. Every sentence carries distinct information and none restates the tool name.

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 six-parameter read tool with no output schema, the definition covers the choices an agent is most likely to get wrong (price basis, timestamp units, default range). Remaining gaps are minor: what the returned candle fields look like and how range plus limit interact when both are supplied.

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 baseline is 3 and the schema already documents millisecond units, the price enum with mark default, and the limit cap. The description reinforces the millisecond convention and adds one genuinely new rule — omit start/end to get the most recent candles — but otherwise repeats schema content rather than extending it.

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?

"Candlestick history for one market" gives a specific resource (OHLCV candles) and scope (single market), which is clearly distinguishable from siblings like everstrike_trades, everstrike_depth, and everstrike_ticker. It stops short of naming any sibling explicitly, so an agent must infer the boundary rather than being told it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives usage guidance for parameters and defaults (use mark unless you need last/index; omit start/end for recent candles) but never states when to choose this tool over everstrike_trades or everstrike_ticker for price history versus snapshots/tick data. Usage is implied by the phrase "candlestick history" rather than spelled out.

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

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

No annotations are provided, so the description carries the full burden. It discloses the fields returned, which is useful, but does not state whether results are paginated, how fresh the data is, or whether any authentication/permission constraints apply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no unnecessary wording. It immediately conveys the resource and the key returned 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 parameterless list tool with no output schema, the description usefully enumerates the returned market attributes. It could be slightly more complete by mentioning ordering, pagination, or data freshness, but it is adequate for this simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so parameter semantics are inherently trivial. The baseline score of 4 applies because there is no schema-level parameter meaning to clarify.

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 states the resource: all tradable markets, along with the metadata returned (tick size, lot size, leverage caps, contract type). This distinguishes it from siblings like ticker, depth, or trades, though it does not explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance, no mention of when not to use it, and no reference to sibling tools such as everstrike_assets or everstrike_ticker. The intended use as a market-discovery/metadata call is only implied.

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

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

With no annotations, the description must carry the whole burden, and it does disclose the three content areas returned. However, it says nothing about whether the endpoint is public or authenticated, whether results are cached, how often it refreshes, or what the health values signify. For a zero-parameter read this is adequate but thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short fragment covering exactly the three delivered items, front-loaded with the resource name. Nothing is padded, though the telegraphic style leaves no room for the guidance noted above.

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 is the only source for the return shape, and it lists the three fields at a high level. It does not explain response structure, freshness, or what an agent should do with maintenance-window information, so it is complete only for a minimal reading.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter hints are present.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (exchange-wide status) and enumerates what it covers: uptime, engine health, maintenance windows. That is enough to distinguish it from every sibling, all of which return market data rather than operational metadata. It lacks an explicit verb, but the fragment form is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this versus the market-data siblings, and no note on when it is unnecessary. The agent has to infer that it is a pre-flight/health check rather than a data feed. No exclusions or alternatives are named.

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

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

With no annotations, the description carries the full behavioral burden and does notable work: it discloses payload scale (257 markets × ~50 fields), explains that omitting the parameter returns a compact subset rather than everything, and notes that unknown market values are echoed back with suggestions. It does not mention rate limits, freshness/latency, or the shape of the returned fields, which keeps 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?

Two sentences, front-loaded with the two-mode rule and immediately followed by the reason for the default (payload size). No filler, though the phrase 'the full ticker is 257 markets of ~50 fields, which no caller can use in one piece' is slightly verbose relative to the information it conveys.

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 single optional-parameter read tool with no output schema, the description covers both call modes, the default behavior, and the size constraint that motivates the default. It lacks any indication of what a returned market entry contains ('every field' is asserted but not illustrated) and says nothing about response latency or limits.

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 description is unusually rich, already covering the quote-first keying convention, friendly-spelling resolution, the six-item cap, and the everstrike_pairs pointer. The prose adds only a light usage directive ('always pass this when the question is about specific markets'), so baseline 3 is appropriate given 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 states the resource (live prices across markets) and distinguishes two operating modes: full per-market ticker when `pairs` is supplied, compact summary of most active markets when omitted. It is specific enough to separate it from siblings like everstrike_ohlcv or everstrike_depth, 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?

It gives a clear conditional rule – pass `pairs` for specific markets, omit it for a compact overview – and points to everstrike_pairs for canonical market names. It stops short of stating when to prefer everstrike_ohlcv, everstrike_depth, or everstrike_trades instead, so the routing is implied rather than exhaustive.

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

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

No annotations are supplied, so the description carries the full behavioral burden, yet it discloses little. 'Public' weakly implies no authentication is needed and 'recent' implies a recency/window limit, but the number of trades returned, any pagination, rate limits, and whether results are ordered newest-first are all unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler, and the scope constraint is front-loaded. It is efficient but borders on under-specified for a tool with zero annotation coverage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with a fully documented schema, this is close to adequate, but with no annotations and no output schema the description should say what a trade record contains (price, size, side, timestamp) and how many come back. Those gaps leave an agent guessing about the response.

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%; the pair parameter already documents the QUOTE-FIRST keying convention, friendly-form resolution, and points to everstrike_pairs. The description adds nothing beyond that, 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 and resource ('Recent public trades') scoped to 'one market', which is enough to tell it apart from everstrike_ohlcv, everstrike_depth and everstrike_ticker by resource type. It stops short of explicitly contrasting itself with those siblings, so it lands at 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to choose this over everstrike_ohlcv (candles), everstrike_depth (order book) or everstrike_ticker, nor any stated prerequisites. The only implied usage signal is 'one market', meaning a required market identifier.

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

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

No annotations are supplied, so the description carries the full behavioral burden and delivers little: it says nothing about this being a read-only snapshot, about authentication requirements, data freshness, or caching. 'State' hints at a read, but that is inference rather than 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?

A single short clause with the resource front-loaded and the returned fields listed compactly. No filler, but also no structure beyond the colon-delimited list.

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 is the only place return values can be described, and it names just three fields without units, formats, or whether the response includes additional vault metadata. For a parameterless read tool this is marginally adequate but leaves the agent guessing at the shape of the payload.

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?

Zero parameters, so the baseline is 4. There is nothing schema-side or description-side to reconcile, and the vacuous object schema means no parameter ambiguity exists.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names the specific resource (perpetual vault state) and enumerates the three data points returned: redemption rate, total earnings, USD supply. That is enough for an agent to tell it apart from the market-data siblings (ohlcv, depth, ticker, trades). It stops short of a 5 because there is no explicit retrieval verb and the field list is descriptive rather than a statement of scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no exclusions, and no reference to the sibling tools despite ten of them being available. The agent must infer that this is the vault-metrics endpoint; nothing says whether to call it for earnings analysis, redemption-rate monitoring, or both.

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