markolis

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the substantive point that these are 'real-time' feeds, implying fresh snapshot data rather than historical or cached values. It does not say whether output is a live snapshot, staleness window, or refresh cadence, which matters for a time-sensitive radar.

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 the verb and payload front-loaded, and the five-item list is efficient because each item names a distinct data source. Slightly dense but no filler or redundant restatement of the 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?

With zero parameters and no output schema, the description carries the whole burden of describing return content, and it does enumerate the feeds. But it gives no sense of response shape, units, or how the five feeds are keyed, and it omits sibling differentiation — leaving real gaps for an agent choosing between radar tools.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly conveys that all feeds are returned together with no filtering options.

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 ("Retrieves") and enumerates the concrete feed contents: session clocks, liquidity multipliers, news blackouts, stablecoin velocity, prediction market odds. An agent knows exactly what data comes back. However, it never distinguishes this from the sibling get_market_telemetry or render_market_intelligence_frame, which plausibly overlap.

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 at all — nothing says when macro radar is the right call versus get_market_telemetry or get_prop_guardian_status. The 'real-time' phrasing implies a pre-decision context check, but the agent must infer that entirely.

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, destructiveHint=false, and openWorldHint=false, so the safety and determinism profile is fully covered and the description does not contradict it. The description adds the useful fact that this is an empirically computed telemetry bundle rather than raw prices, but says nothing about computation cost, latency, or data freshness.

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 front-loaded sentence with no filler, and the parenthetical enumeration is an efficient way to convey scope. The jargon is dense ('regime entropy', 'Hurst persistence') but that density serves the reader rather than padding the text.

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-only, non-open-world lookup with rich annotations and no output schema, the description covers what the agent needs to invoke it correctly and previews the return content. The only meaningful gap is sibling disambiguation, which is a usage concern rather than an invocation blocker.

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 one parameter at 100% schema description coverage and concrete ticker examples already in the schema, the schema carries the parameter burden entirely. The description does not clarify the symbol format, default behavior, or supported asset classes beyond what the schema already states, so 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 pairs a specific verb ('Retrieves') with a concrete resource ('empirical quantitative telemetry for an asset') and enumerates the four metric families returned (regime entropy, Hurst persistence, order book positioning, macro catalysts). This is far more specific than a tautology, but it does not distinguish the tool from the sibling get_macro_radar, which plausibly overlaps on the 'macro catalysts' component.

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 statement of preconditions, no exclusion of cases, and no pointer to alternatives among the five siblings. An agent reading only this description cannot tell whether to call this tool or get_macro_radar for macro-related questions.

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, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds real value beyond that by disclosing what the payload contains — drawdown headroom, daily loss usage, Kelly sizing — and the word "live" signals the data is current-state rather than historical. It stops short of describing format, units, or how a breached kill-switch is represented.

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 front-loaded sentence with no filler; the three return metrics are the payload and arrive immediately. Density is high and terms like "Bayesian Kelly allocation sizing" are specialized, but every clause carries information rather than restating the 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?

With no output schema, the description carries the burden of explaining return values, and it names the three metric families but not their shape, units, or safety thresholds. For a zero-parameter read-only tool this is close to adequate, yet an agent still cannot predict what a kill-switch-headroom value looks like or what happens when a limit is exhausted.

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 a 4. The description correctly stays silent on inputs rather than inventing any.

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 ("Returns") and a well-scoped resource ("live systematic risk telemetry for prop challenge pacing"), then enumerates three concrete metrics: trailing drawdown kill-switch headroom, daily loss usage, and Kelly allocation sizing. It implicitly separates itself from siblings like get_market_telemetry and get_macro_radar via the prop-challenge framing, but never names an alternative 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?

"for prop challenge pacing" implies the situation in which an agent should reach for this tool, which is more than nothing. However, there is no explicit when-to-use vs. when-to-skip statement, no mention of the sibling telemetry tools as alternatives, and no prerequisites (e.g., whether a prop account session must be active).

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds only the content scope (26 streams, 5 tiers) and nothing about freshness, size, or payload shape — modest added value against a low bar.

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 front-loaded sentence with no filler or repetition. It is efficient, though its terseness edges toward under-specification rather than optimal density.

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 is the only place an agent can learn what the response actually looks like, and it never says — no mention of per-stream fields, tier structure, or size. Adequate as a one-line summary, insufficient as the sole return-value documentation for a catalog 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 takes zero parameters, so there is no parameter semantics burden on the description; the baseline applies. Nothing in the description misleads about inputs.

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 ('Returns') and resource ('verified product catalog') with concrete scope (26 streams, 5 commercial tiers), which is enough to distinguish it from the market-data siblings. Minor deduction because 'Markolis' and '26-stream' are unexplained domain jargon an agent may not decode.

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, no prerequisites, and none of the four sibling tools are referenced. The agent must infer from the name alone whether to call this before, after, or instead of get_market_telemetry or get_macro_radar.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. Beyond that, the description adds real value: the snapshot is isolated and read-only, results are 'regulatory-compliant,' and with no output schema it names the three returned visual components. It stops short of disclosing freshness, latency, or cost of the LLM path, which would have earned 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?

It is a single sentence, front-loaded with the verb and resource, with no filler or repetition. The parenthetical listing of three visual components is dense but earns its place given there is no output schema; the only mild cost is that the sentence is long and jargon-heavy for a first read.

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 three-parameter, fully schema-documented tool with no output schema, the description carries the right load by describing the returned artifacts rather than leaving them opaque. What is missing is comparative context — when an agent should pick this frame over get_macro_radar or get_market_telemetry — which is the main completeness 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?

Schema description coverage is 100%, so the baseline is 3 and all three parameters — including the use_llm toggle and default_symbol fallback — are already documented in the schema. The description adds only the instrument-class enumeration (FX, metal, commodity, crypto, index), which lightly reinforces default_symbol but does not explain the tradeoff between LLM synthesis and the deterministic institutional summary.

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

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

The description gives a specific verb and resource — querying an isolated read-only market intelligence snapshot — plus the asset classes it covers and the shape of what comes back (analysis plus visualization frame). It falls short of full sibling differentiation: the 'macro causal transmission graph' overlaps conceptually with get_macro_radar, and the description never says how this frame differs from that tool or from get_market_telemetry.

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 rather than stated: the asset-class list and the example query 'Where are retail traders trapped on Gold?' show the intended call pattern, but there is no explicit when-to-use, no when-not-to-use, and no routing advice across the four sibling tools. An agent must infer that this is the visualization-oriented choice versus the plain-data siblings.

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