Liquid State — Crypto Market Intelligence

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

Beyond the read-only annotation, the description discloses concrete operational behavior: a maximum of 25 per page, a 60 reads/minute/client rate limit shared with REST, and specific error-handling semantics for rate_limited, rate_limit_unavailable, and discovery_unavailable. This is exactly the kind of behavior an agent needs to invoke the tool safely and retry 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?

The description is dense and front-loaded: it starts with purpose, then scope exclusions, limits, parameter modes, and error behavior. Every sentence carries operational information, with no filler.

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

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

For a read-only discovery tool with no output schema, the description covers the important invocation constraints, rate limits, error cases, and parameter modes. It could say more about the returned record shape or lifecycle projection, but it is largely complete for correct tool use.

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?

With only 50% schema description coverage, the description usefully adds meaning for the main usage modes: slug for one record, slug plus format=registration for an export, and the 25-per-page limit. It still leaves the after cursor semantics mostly to the schema, but overall it compensates well for the partial schema 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?

The description names a specific resource, 'currently public Genuine Agent Records', and a clear discovery action, so the tool's core purpose is easy to identify. It does not explicitly contrast itself with sibling tools such as get_briefs or get_pricing, though those resources are inherently different.

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 clear mode-selection guidance: use slug for a single record and slug plus format=registration for an ERC-8004-shaped export. It also states meaningful scope exclusions, such as samples being excluded and no public metrics being available, but does not explicitly name when an alternative sibling tool should be used instead.

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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description goes beyond them by disclosing the payload shape (headline, category, coins, summary, url, publishedAt), which matters since there is no output schema. It does not discuss refresh cadence or limits, but it adds real context over the 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 sentences, front-loaded with the resource and its scope, then the trigger condition and return fields. No filler or redundancy.

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, single-optional-param tool, the description covers what it returns and when to use it, compensating for the absent output schema. Missing only minor details like freshness/recency window or ordering of results.

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 limit parameter (range, default 15) is fully documented in the schema. The description adds nothing about the parameter, so the baseline of 3 applies when the schema does all the work.

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 (crypto market-intelligence briefs from Liquid State) and enumerates the content covered (price action, liquidations, funding, macro), which separates it from get_derivatives/get_market_overview. It does not explicitly name which sibling to prefer for overlapping needs, so it stops short of 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?

"Use when the user wants recent crypto news/analysis or what's moving markets" gives a clear triggering condition. There are no exclusions or explicit alternative-routing statements against the five siblings, so it is clear context but not full when/when-not guidance.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-dependency profile are covered. The description adds that the data is 'live' and sourced from OKX, which is useful freshness/provenance context, but it says nothing about rate limits, caching, or behavior when the symbol is unknown.

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 first front-loads the resource and the returned fields, the second gives the usage trigger. No filler or redundancy.

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-parameter read tool with no output schema, the description compensates by listing the four returned metrics, so an agent knows what it gets back. Combined with annotations covering the read-only/open-world profile, nothing material 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 'symbol' parameter is documented with format examples (BTC, ETH, SOL). The description only reinforces 'one crypto asset' and does not add syntax, casing, or pair-format guidance beyond the schema.

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

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

States a specific verb (get) and resource (live perpetual-futures derivatives from OKX) and enumerates the exact metrics returned: funding rate, open interest, long-account %, last price. This is distinguishable from siblings like get_market_overview or get_market_state, which cover different 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?

Explicitly states when to use it: 'Use when the user asks about funding, open interest, positioning, or the perp price of a specific coin.' That is a clear triggering context with concrete query topics, though it names no alternatives or when-not conditions (e.g., spot price vs perp price).

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context beyond that: the content is paid, and "price is always disclosed," which tells the agent this is a catalog listing rather than a purchase flow. It omits any note on ordering, completeness, or pagination of the list.

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, both front-loaded: the resource and its fields come first, the alternate trigger second. The em-dash field enumeration is dense and wastes no words; the paid/price-disclosure caveat is placed where it is most salient.

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

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

With no input parameters and no output schema, the description compensates well by enumerating the returned fields and flagging the paid nature of the content. For a simple zero-arg list tool, an agent has everything needed to select and call it.

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 and the baseline is 4. The field list it provides (title, description, tags, page count, price, url) describes the return shape rather than parameters, which is useful but doesn't affect input semantics.

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

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

States a specific verb+resource (retrieving Liquid State's premium trading guides) and enumerates the returned fields, so the agent knows exactly what it gets. However, it never distinguishes itself from the closely related sibling get_briefs, leaving the agent to infer the guides-vs-briefs boundary on its own.

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?

"Use when the user wants an in-depth trading education resource (risk management, position sizing, trend-following, etc.)" gives a clear positive trigger with concrete topical examples. It stops short of any when-not condition or a named alternative such as get_briefs for shorter content.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine context beyond that by disclosing the payload composition (funding rate + price) and the asset scope, which the annotations do not convey. It omits refresh cadence and any rate-limit or freshness caveats.

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

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

Two short sentences, zero waste, with the payload definition front-loaded before the usage hint. Nothing redundant with the title or annotations.

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 read tool with no output schema, the description adequately conveys what comes back and for which assets. The remaining gap is disambiguation from get_market_state, whose scope is not addressed.

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

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

The tool takes zero parameters, so the schema imposes no documentation burden and the baseline is 4. There is nothing for the description to clarify or compensate for on this dimension.

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 payload: funding rate plus price snapshot, scoped to named assets (BTC, ETH, SOL) in a single call. Clear enough for an agent to know what it gets, but it does not differentiate itself from the close sibling get_market_state or from get_derivatives, which likely also surfaces funding-rate data.

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?

"Use for a quick market-wide read" gives an implied use case, but offers no when-not conditions, no prerequisites, and never names an alternative (e.g. get_market_state vs get_derivatives). The agent is left to infer selection from sibling names alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds value beyond that by disclosing the return payload (as_of timestamp, source, citation string) and the derived regime signal, which the agent cannot learn from structured fields since no output schema exists.

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 plus a usage clause; the data inventory is front-loaded and the call-to-action sits at the end where it is easy to find. No sentence is redundant.

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 zero parameters and no output schema, the description carries the full burden of explaining what comes back, and it does: contents, timestamp, source, citation string, and the regime enum values. Nothing an agent needs in order to call this 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?

The tool takes zero parameters, so per the baseline there is nothing for the description to document. The description correctly omits any parameter discussion rather than inventing one.

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 ('Consolidated live crypto market snapshot') and enumerates the exact data bundled in it (funding rates, prices, OI, 24h liquidations, regime signal). It does not, however, distinguish itself from near-neighbor siblings like get_market_overview and get_derivatives, which sound like they cover overlapping ground.

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 a clear triggering condition: 'Use when the user asks about current crypto market conditions.' No exclusions or alternatives are named, which matters here because get_market_overview and get_derivatives plausibly compete for the same queries, but the context itself is explicit rather than 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: results are dynamic — founding and yearly plans appear only 'while /pricing has them on sale, checked when you call the tool' — and it deliberately withholds the price values themselves. It stops short of describing response structure or pagination, hence 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?

Three sentences, front-loaded with what the tool returns, then the volatility caveat, then the invocation trigger. Every sentence carries information the agent cannot get from annotations or schema; nothing is redundant.

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 read tool with no output schema, the description covers scope, freshness semantics, and when to call. The one gap is that it doesn't hint at the shape of the pricing response (e.g., per-plan fields, currency display), which an agent might want since no output schema exists.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. It correctly does not waste space restating parameter information.

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 ('What Liquid State costs today') and enumerates the exact content covered: free read-only API/MCP server, The Feed, The Reserve, x402 per-call USDC terms, plus founding/yearly plans when on sale. This clearly distinguishes it from the sibling tools (get_briefs, get_market_overview), none of which deal with pricing.

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 or agent asks about price, plans, or how to pay.' That is a clear context for invocation. It does not name an exclusion or alternative, but no plausible sibling competes for this intent, so the guidance is nearly complete.

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 readOnlyHint=true and openWorldHint=false already declaring the safety profile, the description adds real value beyond annotations: it flags that continuity is not verified (a data-quality caveat the agent cannot get elsewhere) and clarifies that the figures are paper-strategy simulation, not live capital. It stops short of describing freshness, staleness, or the shape of the payload.

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 tight sentences, front-loaded with the identity and payload of the record, followed by two disambiguating caveats. Every sentence carries distinct information and none repeat the name, annotations, or 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?

For a zero-parameter, no-output-schema read tool, the description covers identity, payload, scope exclusions, and a data-quality caveat, and notes that the prospective stance history is linked in the response. What remains thin is return-value shape (period coverage, units, formatting), which the missing output schema would otherwise have to supply.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly avoids inventing parameter-style guidance for a call that accepts no arguments.

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 (Liquid State's legacy paper-strategy simulation record) and enumerates what it returns: returns, drawdown, and equity observation counts. It distinguishes its scope by negation ('does not measure paid stance outcomes or live capital'), though it never names a sibling tool directly, so differentiation is inferential rather than explicit.

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

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

Usage context is implied rather than stated: the 'does not measure paid stance outcomes or live capital' clause tells the agent when this tool is the wrong choice, and the reference to a linked prospective stance history points at an alternative source. There is no explicit 'use this when' or named alternative.

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