Liquid State — Crypto Market Intelligence

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 describes the output fields (headline, category, coins, summary, url, publishedAt) and the default/range for limit. It does not mention side effects, but as a 'get' operation, it is clearly non-destructive. Lacks explicit mention of read-only or auth, but this is not misleading.

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 concise, with two sentences: one stating the purpose and output, the other giving usage guidance. It is front-loaded with the primary function and includes essential details without fluff.

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

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

Given the simple nature of the tool (a get with one optional parameter), the description is complete. It lists the output fields, provides usage context, and specifies the parameter behavior. No output schema is provided, but the description covers what is returned.

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 parameter 'limit' is described with a clear meaning, valid range (1-50), and default value (15). The schema already documents the parameter, and the description adds useful constraints and default behavior.

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 tool retrieves recent crypto market-intelligence briefs and lists the specific fields returned. It distinguishes itself from sibling tools by focusing on briefs/news rather than derivatives, guides, or market overview.

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 the tool: 'Use when the user wants recent crypto news/analysis or what's moving markets.' This provides clear guidance and implicitly differentiates it from sibling 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?

With no annotations, the description carries the full burden. It discloses that the data is 'live' and sourced from OKX, and that the call targets one asset at a time. However, it does not mention rate limits, potential error conditions (e.g., invalid symbol), or whether the call is safe/read-only. For a simple fetch tool this is adequate but not comprehensive.

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 purposeful. The first defines the tool's exact scope and fields, the second gives direct usage guidance. No filler or repetition of schema information.

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

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

For a tool with one parameter and no output schema, the description covers the return value contents, the data source, and use cases. It would benefit from a note on response format or behavior for unsupported symbols, but given the simplicity, it is nearly complete.

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 already explains the symbol parameter with examples. The description adds context that it is a single asset and ties it to the derivative data, but does not add materially 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?

The description names a specific verb ('get'), a specific resource ('perpetual-futures derivatives for one crypto asset from OKX'), and enumerates the exact data fields returned (funding rate, open interest, long-account %, last price). This clearly differentiates it from siblings like get_market_overview or get_market_state, which sound broader in 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?

The description provides explicit when-to-use guidance: 'Use when the user asks about funding, open interest, positioning, or the perp price of a specific coin.' It does not, however, mention when not to use it or name alternative sibling tools, so it stops short of full exclusionary 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly flags that content is paid and price is always disclosed, and it enumerates the fields returned, giving a solid sense of output. Auth and side effects are not mentioned, but a zero-parameter catalog read needs little additional 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?

Two tight sentences with no filler: the first lists what the tool returns, the second covers the paid-content caveat and the use condition. Information is front-loaded and every clause earns its place.

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

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

With no output schema, the field enumeration sufficiently tells an agent what to expect in the response. The use trigger and pricing caveat fill out the context needed for a simple, zero-parameter list tool, 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?

The tool has zero parameters, so there is no ambiguity for an agent to resolve. Baseline 4 applies because the schema is trivially complete and the description does not need to compensate for any parameter documentation gaps.

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 the resource (Liquid State's premium trading guides) and enumerates the returned fields (title, description, tags, page count, price, URL). 'Premium' and 'education resource' clearly separate it from lighter sibling offerings like get_briefs or market data tools.

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 an explicit 'Use when...' trigger tied to in-depth trading education topics such as risk management and position sizing. It does not explicitly name alternative tools or list when-not-to-use conditions, so it stops short of a 5.

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 provided, the description carries the full burden of behavioral disclosure. It conveys a read-only snapshot via 'snapshot' and lists the data included, but it does not explicitly state that no state changes occur, mention data freshness, or note any rate-limit concerns.

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 two sentences with no filler. It front-loads the core content and follows with a direct use-case statement, making every sentence 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?

For a zero-parameter tool with no output schema, the description provides sufficient information to invoke it correctly: the asset scope and the data returned. It could be stronger by clarifying how it differs from get_market_state or get_derivatives, but the low complexity reduces the need for more.

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, and the input schema is empty, so there is no parameter semantics for the description to clarify. The baseline of 4 applies because no parameter documentation burden 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?

The description clearly identifies the tool as returning a funding rate and price snapshot for BTC, ETH, and SOL, which is a specific verb+resource combination. However, it does not explicitly distinguish itself from the sibling get_market_state, so it falls just short of full differentiation.

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 states 'Use for a quick market-wide read,' giving clear situational guidance. It does not provide when-not-to-use guidance or name alternatives, but the usage context is explicit enough for an agent to decide.

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 provided, the description carries the full burden. It discloses the tool's read-only nature implicitly and details the returned data: as_of timestamp, source, citation string, and various market metrics. It also states the derived regime signal. It does not mention rate limits or data freshness caveats, but the snapshot behavior is well described.

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 compact and front-loaded, leading with the core purpose ('Consolidated live crypto market snapshot designed for AI citation'), then itemizing contents and return fields, and closing with a usage directive. Every sentence adds value with no 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?

Given the tool has no parameters and no output schema, the description provides enough detail about the return contents and intended use case for an agent to call it correctly. It could be slightly more complete by mentioning likely alternatives for specialized derivative queries, but overall it is sufficient.

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

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

The tool has zero parameters and the schema is an empty object, so there is nothing for the description to add about parameter semantics. The baseline of 4 for no-parameter tools applies, and the description does not need to compensate for any schema gaps.

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 tool returns a consolidated live crypto market snapshot with a specific list of components (funding rates, prices, open interest, liquidations, regime signal). It distinguishes itself via 'designed for AI citation' and includes return fields, though it does not explicitly differentiate from siblings like get_market_overview or get_derivatives.

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 an explicit usage condition: 'Use when the user asks about current crypto market conditions.' This gives clear context for when to invoke the tool, but it does not mention when not to use it or name alternative sibling tools for related requests.

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 provided, the description carries the full burden of behavioral disclosure, and it does this well: it reveals that this is paper trading rather than live capital, that it updates daily, that strategies are deterministic and rule-based, and that losses are never hidden. This gives the agent important context about trustworthiness and limitations.

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 two sentences, front-loads the core resource identity, and then packs the most useful details — metrics, update cadence, paper-trading nature, and when to use it — without wasted words.

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 zero-parameter read-only lookup tool, this description is complete: it names the tracked entities, the metrics included, the update frequency, and the credibility caveat. No output schema exists, but the described content is sufficient for an agent to invoke the tool and set expectations for 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?

The tool has zero parameters, so the schema is empty and parameter documentation is not needed. The description sufficiently explains what the returned resource contains, so this meets the baseline for a parameterless tool.

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 identifies a specific resource — Liquid State's public paper-strategy track record — and states exactly what data it contains (return %, max drawdown %, days live). This clearly differentiates it from sibling tools like get_market_overview or get_briefs, which concern broader market or content resources.

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 explicitly states when to use the tool: when the user asks whether Liquid State's calls or strategies actually work, or wants a verifiable track record rather than a claim. It gives clear usage context, though it does not explicitly name alternatives or state when not to use it.

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