HYPERneobroker.com

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral context by specifying the data source, update frequency, and free access, which sets expectations about data freshness and API limits. No contradiction with 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 concise, information-dense sentences front-load the core purpose and then cover parameters and data source. Every sentence earns its place with no repetition or 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 tool with zero required parameters, a 100% documented schema, and no output schema, the description provides all essential context: data source, update schedule, defaults, and parameter format. Nothing critical is missing for correct invocation.

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 both parameters are already documented. The description repeats the base default and adds an example for symbols, but does not materially extend the schema's meaning. It adds marginal clarity but no substantive new 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?

The description clearly identifies the resource (FX exchange rates for 30+ currencies) and its scope, distinguishing it from siblings like get_price or get_perp_prices by naming the currency domain. Although it lacks an explicit verb, the tool name and title supply 'Get', and the meaning is completely 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?

It provides useful context—ECB reference rates via Frankurter, updated each business day, free data—which implicitly signals when to use it, but it does not name any alternatives or state when-not-to-use conditions. An agent must infer that other pricing tools cover different asset classes.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: data is live/real-time, free, and includes specific return fields. It also clarifies the scope of the data (Hyperliquid and trade.xyz equity perps), which helps set 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 single, information-dense sentence that front-loads the core purpose (live perpetual futures), then lists sources, data fields, and filtering option. Every word earns its place; no fluff or repetition.

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 read-only tool with one optional parameter and no output schema, the description is largely complete: it lists the returned metrics, the data sources, and a filtering example. Minor missing details include default behavior when no coin is provided and the response format, but these are not critical given the low complexity and strong annotations.

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 schema already fully describes the single optional 'coin' parameter with 100% coverage, so the baseline is 3. The description adds value by giving concrete examples (BTC, ETH, XYZ100) and mentioning 'market filter', which enriches the meaning of the parameter beyond the schema's generic 'Optional coin or market filter' text.

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 uses a specific verb implied by the tool name to retrieve live perpetual futures data, and explicitly names the data sources (Hyperliquid, trade.xyz) and the exact metrics returned (price, 24h change, funding rate, open interest, 24h volume). This clearly distinguishes it from sibling tools like get_price or get_prediction_markets.

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 implies usage when perpetual futures data is needed and explains the optional coin filter with examples, but it does not explicitly state when to use this tool versus alternatives like get_price or get_fx_rates. Usage context is implied rather than spelled out, and no exclusions or alternative routing guidance is given.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by specifying that this is a snapshot and by listing the exact metrics returned, including the $100k benchmark.

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, information-dense sentence front-loads the tool's purpose and then enumerates the key output fields without any filler. Every element contributes 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?

With no parameters and no output schema, the description carries the full burden of explaining what the tool returns; it does so by listing the core portfolio fields. The paper-desk context and benchmark also provide enough framing for correct 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?

The tool has zero parameters, so the baseline is 4. There is no parameter information needed beyond what the empty schema already conveys.

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 uses a specific verb and resource ('Paper desk portfolio snapshot') and enumerates the exact contents: equity, cash, buying power, day P&L, and total P&L vs the $100k starting stack. This clearly distinguishes it from sibling tools like get_positions or get_price.

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 conveys clear context: this is the aggregate portfolio snapshot for the paper desk, which implies it is the right choice when needing portfolio-level balances and P&L. It does not explicitly name alternatives or exclusions, but the scope is specific enough that an agent can infer when to use it.

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 the tool read-only, idempotent, and non-destructive, so the description need not repeat that. It adds meaningful context: the data source (Alpaca paper account) and that only currently open positions are returned with market value and unrealized P&L. It does not discuss ordering, pagination, or error behavior, but given the simple getter this is acceptable.

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 sentence of roughly 20 words, with the core resource stated up front and the output fields following. Every word adds value, with no redundancy or 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 zero-parameter, read-only getter with no output schema, the description covers the source, scope (open positions), and output metrics. The only minor gap is a clear routing direction versus get_portfolio, but the tool is simple enough that this is not a critical omission.

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?

There are no input parameters, so the schema fully covers the interface. The baseline for 0 params is 4, and the description correctly avoids inventing or documenting arguments that do not exist.

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 ('open positions on the HYPERneobroker.com paper trading desk') and enumerates the returned fields (ticker, qty, market value, unrealized P&L). This makes the tool's purpose clear and naturally sets it apart from sibling getters like get_fx_rates or get_price. It does not explicitly contrast with get_portfolio, but the per-position detail is sufficient for basic 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 provides no when-to-use or when-not-to-use guidance and does not mention alternatives. In particular, it fails to help an agent decide between this and the sibling get_portfolio. The usage context is only implied by the words 'open positions', with no explicit 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 read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds that the data is free/public (no auth barrier), that it is live, and which fields are returned — useful context beyond the annotations. No contradiction 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?

One dense sentence front-loads the key outcome (live prediction markets, fields, sources), then tucks optional search and access information into a compact second clause. Every word adds value 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 one-optional-param, read-only tool with no output schema, the description covers the source universe, the returned data fields, the optional query semantics, and the free/public access condition. It does not describe the list shape or what happens with no query, but the field listing and 'optional' wording handle most of the needed context.

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 schema already fully documents 'query' as an optional topic string (100% coverage), yielding a baseline of 3. The description adds concrete example topics ('election', 'bitcoin', 'nfl'), which helps an agent form valid queries; it does not clarify behavior when the query is omitted.

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 ('prediction markets'), scopes it to two named sources (Polymarket, Kalshi), and lists the returned data fields (YES price, volume, close date). This clearly separates it from sibling market-data tools like get_fx_rates and get_perp_prices.

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 is implied: use this when you need live prediction-market quotes from Polymarel/Kalshi. There is no explicit when-to-use, when-not-to-use, or comparison to sibling tools, so the agent must infer routing from the tool name and resource.

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 read-only, non-destructive, and idempotent behavior. The description adds real behavioral context not present in annotations: equities are delayed ~15 minutes, crypto is real-time, and crypto access is free forever. This is meaningful operational information for an agent deciding whether this tool's data is suitable for a task.

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 just three short sentences, each carrying useful information: what the tool returns, which asset classes are supported, and a key limitation vís a-í-vis latency and pricing. The most important scoping information is front-loaded, and there is no repetition of the tool name or of schema content.

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 price-lookup tool with strong annotations and full schema coverage, the description supplies enough context to call it correctly: supported symbols, asset types, latency, and cost/access note. It does not describe the response format, but with no output schema that is a modest gap, not impairing the core invocation decision.

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 schema already documents the symbol parameter 100% with a list of valid example tickers and required status. The description adds the asset-class framing and latency qualifiers, but it does not add new parameter syntax or formatting details. With full schema coverage, the baseline 3 is appropriate because the description reinforces rather than augments 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?

The description states the tool's scope clearly: current prices for stocks, crypto, gold, and indices, with concrete examples for each. This makes the tool easy to identify, though it does not explicitly contrast itself with sibling tools. At the same time, the asset-class list itself differentiates it from get_fx_rates and get_perp_prices.

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 implies the right use case by listing supported asset classes, so an agent can infer it should use this tool for AAPL, BTC, GOLD, or SPX. It provides no explicit 'use get_fx_rates for FX' or 'use get_perp_prices for perps' guidance, though the sibling names make the alternatives visible. This is clear context but with no exclusion or rerouting, so it gets a 3.

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