Tickerz

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety and idempotency are covered. The description adds useful context: forecasts are only listed after a question closes, the Arena number is frozen at close and never official, and points are calculated without money or prizes. However, it doesn't describe pagination, rate limits, or response format beyond what's implied, and some statements (e.g., 'forecasts are listed only after it closes') are behavioral constraints already implied by the read-only, closed-world nature.

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 dense paragraph that packs multiple concepts (current questions, recent results, standings, points calculation, id behavior, disclaimers) without clear separation or front-loading. It is hard to parse quickly and includes redundant details (e.g., exact points formula, 'Same data as GET /api/arena' which may be unnecessary for an agent). It lacks structure and prioritization.

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 one optional parameter and no output schema, the description provides enough context to know the tool returns Arena data, including questions, recent results, and standings. However, it does not clarify the exact response shape or what fields are returned, and the dense packing makes it incomplete for an agent trying to decide if this tool returns the needed data versus using get_question or open_questions. It covers the domain but leaves gaps in usage and output structure.

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%; the single optional 'id' parameter is fully described in the schema. The description adds context about what happens with id ('with id, one question: forecasts are listed only after it closes'), which clarifies the id's effect but doesn't add syntax or format details beyond the schema. Baseline 3 is appropriate when 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 opens with 'The Arena: predict the number an index lands on,' which does state a specific purpose and distinguishes the tool from siblings like open_questions or get_question by positioning it as a hub for Arena data. However, it immediately dives into mechanics (index, forecast count, close time) without clearly stating the tool's primary function: returning Arena state (current questions, recent results, standings). The name 'arena' and lack of a clean verb+resource opener leave the purpose somewhat buried.

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 alternatives like get_question (for a single question) or open_questions (for active questions). The description says it returns 'the same data as GET /api/arena and GET /api/arena/question/{id}', which implies it can be used for both, but does not clarify when to prefer this tool over those siblings. No exclusions or conditions are stated.

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 readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description does add genuinely useful behavior context the annotations cannot convey: driver is null when no event is open, score equals the last scores_30d point, and links are 'plain unpaid... checked nightly against each venue's product list'. That is meaningful, but it drifts into return-value documentation with no output schema, so it is not a clean disclosure of operational traits.

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 run-on block of roughly 180 words with no paragraph or bullet structure, mixing usage triggers, response anatomy, deprecation policy, and an API cross-reference. The key differentiator is front-loaded, but the remainder is dense and hard to scan, so sentences do not obviously earn their place individually.

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 no output schema, the description compensates by describing the returned shape and the no-open-event null behavior, and it pre-loads the deprecation timeline for heat_7d/peak_heat. But it omits pagination or size bounds for '10 most recent past events', and the REST endpoint reference is a distraction rather than necessary 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?

Schema description coverage is 100% (symbol, with a 'e.g. BTC or GME' example), so the schema carries parameter meaning. The description's only parameter-adjacent signal is the mention of 'GET /api/asset/{symbol}', which adds no new semantics beyond the schema's ticker definition. 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 ('One asset in depth') and enumerates the returned artifact set (snapshot, scores_30d, events, venues). The opening 'Use when someone asks about one coin or stock' distinguishes it from the index/board siblings, so the agent can route without opening a schema.

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 concrete triggering questions ('why $X is moving', 'whether its volume is unusual') that map cleanly to this tool rather than arena or board. However, it never names a sibling alternative or an exclusion, so the when-not is inferred rather than stated.

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 annotations covering the safety profile (readOnly, idempotent), the description still adds substantial behavior: the dataset size and provenance, the matching criteria, the 1/7/30-day output windows, and the specific null-with-reason cases (stocks, quiet days, small/dominated/indistinguishable groups). This is exactly the kind of context annotations cannot convey.

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 use-case trigger is front-loaded, which is good, but the second sentence ('What historically happened after a move like this asset's current one.') repeats the first, and the methodology sentence is long enough to obscure the operative facts. Some consolidation would help.

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?

There is no output schema, so the description must (and does) explain the return shape: median, spread, and share beating Bitcoin over three horizons versus an ordinary day, plus the null-and-reason paths. Nothing needed to interpret a response 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?

Only one parameter (symbol) and schema description coverage is 100%, so the schema already carries the semantics. The description adds no syntax or format guidance for the symbol beyond what the schema provides, 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 states a specific analytical operation: what historically happened after a move like this asset's current one, computed from 3,213 attention spikes. It's clearly distinct from siblings like arena, asset, or methodology. It loses a point only because the opening clause and the follow-up sentence restate the same idea rather than sharpening 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?

Explicit trigger: 'Use when someone asks what usually happens after a spike like the one an asset shows today.' It also describes failure conditions (stocks return null, quieter days return null). It does not name a sibling alternative for related questions, so it stops short of full routing 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?

Beyond the annotations (readOnly/idempotent/non-destructive), it discloses non-obvious traits: assets are mixed crypto+equity sorted by score, breadth counts crypto only regardless of class, score is null for assets still building a 14-day baseline, heat/heat_1h are deprecated aliases kept until 2026-12-31, and no prices are returned due to vendor licensing.

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?

Front-loaded with the use case before the field details, and every clause carries information given there is no output schema. It is dense and parenthetical-heavy, which slightly hurts readability, but nothing is truly 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 no output schema, the description must carry return-value semantics, and it does: score/score_1h scale, vol_mult definition, updated_at, breadth bands (lone/mid/crowd), and the null-score rule. An agent has everything needed to call and interpret 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?

Schema coverage is 100% so the enum is already documented, but the description adds real meaning: the default (omit for every asset), the fact that mixing happens by default, and that breadth ignores the class filter. It goes beyond the schema baseline.

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 opens with concrete trigger scenarios (unusual crypto/US stock activity, coins far above normal volume) and then names the resource precisely: 'Current Tickerz Terminal: all tracked assets with the 24h move...'. It is unmistakably a market-anomaly board, distinct from asset, arena, or get_index siblings.

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?

Explicit when-to-use is given via the opening scenarios, plus guidance on the class filter ('send class crypto or equity to get one kind, or filter on each asset's class'). It does not name alternative tools or state when-not-to-use, 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?

Annotations already declare a safe read (readOnlyHint, idempotentHint, non-destructive), but the description goes far beyond them: it explains null levels under source terms, partial UTC days and partial_change_pct, live-source completion at 00:00 UTC with on-chain stamping after 12:00, the definition of thin (<70% of the 28-day median once 14 days exist), and that forecast is display-only. This is unusually rich behavioral 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?

Purpose is front-loaded, but the body is a dense single-paragraph run-on with no bullets or field grouping, making it hard to scan. Much of the length is defensible given there is no output schema to explain return fields, yet the presentation is inefficient.

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 must carry the return-shape burden and does so thoroughly: it documents definition, periods with band and signed z, first_print semantics, partial days, seal, proof fields (covers_period, digest_sha256, bitcoin_height, ots_url, status), and forecast sub-fields. Nothing an agent needs to interpret the response 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 schema fully documents the single ticker parameter, so the baseline is 3. The description adds value by enumerating the entire valid ticker set (LAYOFFS, YESNO, TRENCHES, MINTS, GIGS, WAGE, JOBS, UNEMP, CPI, CORECPI) where the schema only gives two examples, reducing invalid inputs for a parameter with no enum.

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 opening clause states a specific verb and resource: 'Use for the history, rules, source and proof of one index named by list_indices.' It explicitly ties the tool to a sibling (list_indices) that supplies the ticker, so an agent can distinguish this single-index detail lookup from the list tool without opening a schema.

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 by the requirement that the ticker come from list_indices and by the enumerated valid tickers, giving a routing hint. However, there is no explicit when-to-use vs. when-not guidance (e.g., pointing to list_indices for enumeration or to arena/board for related views), so context must be inferred.

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, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: a no_kit fallback for unsupported indices, a licensing gate for real-money settlement, a 'not advice' disclaimer, and a 600-character cap on the paste output. 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?

The body is one enormous run-on sentence enumerating roughly fifteen returned fields inside the same breath as the usage guidance. The use case is front-loaded, but the middle is an undifferentiated field glossary that is hard to scan and would be better as a structured list or deferred to an output 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?

With no output schema, the description carries the burden of describing the return shape, and it does enumerate question, period, strikes, settle_time_utc, settle_rule, tie_rule, fallback, proof, recount, license and paste. This is sufficient for an agent to know what it gets back, though the presentation density hurts usability rather than leaving gaps.

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 sole ticker parameter is fully documented in the schema (including the four supported tickers and the optional dollar sign). The description restates the ticker set without adding new syntax or format meaning, 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 opening clause states a clear triggering condition and verb ('list, write or settle a prediction market') and names the resource (a Tickerz index market kit), plus an endpoint equivalence (GET /api/indices/{ticker}/listing.json). It is distinguishable from get_index/get_question because it produces a pasteable market rather than raw data, though the purpose statement is nearly swallowed by the following field dump.

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 when-to-use trigger ('when someone wants to list, write or settle a prediction market on a Tickerz index') and a boundary case ('Any other index returns no_kit with the reason'). It stops short of naming which sibling to use instead (get_index, get_rule, methodology) for adjacent needs, so it is clear context without alternative routing.

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 (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely useful behavior beyond that: crowd split only appears once answers close, and the outcome is 'the first stored Activity score at or after the resolve time; void when none lands within 3 hours'. It does not cover auth or rate-limit behavior, keeping it short of 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 front-loaded correctly ('One question by id...'), but the remainder is a dense run-on paragraph mixing payload fields, OpenTimestamps mechanics, and a REST-equivalence note. Much of the content is justified by the absent output schema, yet the phrasing is packed enough to impede fast parsing.

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 full burden of describing the return payload, and it does so thoroughly: statement, nulls, answer, crowd split, outcome/void rule, right/wrong, and the proofs[] structure with the digest equality check. Only minor details like auth or error behavior are 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?

There is a single parameter with 100% schema description coverage, so the schema already documents that id is a uuid sourced from open_questions. The description adds only the trivial 'by id' framing, so baseline 3 is correct.

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+scope: 'One question by id, open or resolved', which an agent can distinguish from the sibling list tool open_questions. However, it never names open_questions or any alternative explicitly, so the differentiation is left to inference.

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 id must come from open_questions or the REST list endpoint (that hint actually lives in the schema, not the description). There is no explicit when-to-use/when-not or named alternative, so an agent must infer the lookup-by-id workflow.

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 readOnly, idempotent, non-destructive, closed-world, so the safety burden is lifted; the description adds substantive behavior beyond them: the Ed25519 publisher signature, independent recount co-signatures, provider snapshot hashes, settleable status, and the verification endpoint. It does not discuss error cases or missing-signature behavior.

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 leading "Use when..." clause is well front-loaded, but the first sentence is an overstuffed run-on enumerating every return field, which taxes readability. The verification and endpoint URLs earn their place; the field list could be tightened.

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 return-shape burden and does so thoroughly (ticker, period, scaled-integer value, status enum, rule version/hash, signatures, feed account), plus verification instructions and the REST equivalent. Nothing an agent needs to call or interpret this tool 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 coverage is 100%, so baseline is 3, but the description adds real meaning: it clarifies that period is optional and that a month is expressed as YYYY-MM-01, which goes beyond the schema's pattern and "newest when left out" note. Ticker semantics are already fully covered by 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 a specific resource (the signed Tickerz print for an index) and enumerates exactly what that artifact contains (signature, co-signatures, hash, Solana feed account), so the agent knows this is not the plain index lookup. It never names a sibling (e.g., get_index or receipts) to sharpen the boundary, so it stops 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?

"Use when a contract, a venue or a person needs the signed Tickerz print" gives concrete selection context, and the follow-up URLs tell the agent how to verify the result. There is no explicit when-not guidance or named alternative tool, which keeps it below 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond that: it discloses the return payload structure (rule + version + sha256 hash of canonical JSON), explains the settleable flag and its conditions (source's terms allow it and grade is not display), and even maps the response to a REST endpoint — all of which help an agent reason about downstream use without contradicting 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?

The description is a single dense, front-loaded sentence that leads with the usage trigger, which is good structure. However, it packs a long enumeration of rule fields plus a settleable explanation into one unwieldy sentence, which reduces scannability and makes it harder to isolate the key call conditions — efficient in word count but not in information architecture.

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 does so thoroughly by enumerating the rule components, version, hash, and the settleable flag with its conditions. The main gap is that it does not mention error or not-found behavior for an invalid ticker, so it is not fully complete for a tool an agent may call speculatively.

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 describes the single ticker parameter including the 'with or without the dollar sign' detail, so the schema already does the heavy lifting. The description does not add parameter-level syntax or format guidance beyond what the schema provides, so a baseline 3 is appropriate.

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 (retrieve the machine-readable rule for a Tickerz index) and enumerates exactly what the rule contains — source, query, transform, aggregation, cadence, unit, decimals, precision, revision policy, grade, settlement rights with terms page and quoted clause, version, and hash. This is precise enough to distinguish it from siblings like get_index or methodology without opening their schemas.

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?

Opens with an explicit when-to-use condition — 'Use when someone needs to know exactly how a Tickerz index is counted before relying on it' — which is a clear contextual trigger. However, it does not name alternatives (e.g., methodology, get_index) or state when NOT to use this tool, so the routing guidance is incomplete.

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 establish readOnly, idempotent, non-destructive, and closed-world. The description adds genuinely new behavioral context beyond them: data is served 'from a stored copy' with read_at indicating staleness, and the 'live' flag communicates whether on-chain state has been written yet. That staleness/state caveat is the kind of disclosure annotations cannot carry.

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 length is defensible because no output schema exists, so the return-field enumeration earns its place. However, it is delivered as one long run-on sentence stringing status values, signing cadence, settlement rules, and account details together, which impedes front-loaded scanning after the first clause.

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 full burden of explaining return values and does so thoroughly (per-index value, period, status, cadence, settlement eligibility, read threshold, rule version/hash, Solana account). Combined with the staleness note and the get_report fallback, an agent has enough to call and interpret the tool, though the settling-rule and status enumerations remain terse.

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 input schema declares zero parameters at 100% coverage, so there is nothing parameter-level for the description to compensate for. Baseline 4 applies; the description correctly does not invent or describe inputs, and instead spends its words on the response shape.

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 opening clause states a clear verb and resource ('every Tickerz oracle feed at once'), and the tool is distinguishable from get_report, which is named as the alternative for scenarios where the Solana program is not yet live. The bulk of the description enumerates return fields, which is output detail rather than purpose, but the core purpose 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?

It gives an explicit trigger ('when a contract, a venue or a person wants every feed at once') and names a concrete alternative with a condition: when 'live' is false, read signed reports via get_report instead. It stops short of covering other sibling tools (get_index, list_indices) that an agent might weigh, but the primary routing decision is 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?

Annotations already declare this a safe, idempotent, closed-world read, so the bar is low — yet the description goes well beyond them, disclosing Bitcoin timestamping for immutability, provisional/partial_day semantics, the thin and sampled_payers flags with their exact threshold logic, late-arriving sources, and sources whose terms withhold levels from the API.

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 trigger sentence is front-loaded well, but the body is a dense, run-on wall of edge cases (thin/sampled_payers math, p25/p75, partial_change_pct) that reads like response documentation compressed into one paragraph. Much of it is relevant only because no output schema exists, but it is still longer than an agent needs to select and call a no-argument list tool.

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 has to carry the entire return-value burden, and it does: it explains the per-index fields, the 30-day window, banding, timing caveats and source restrictions. Nothing an agent needs in order to interpret results 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 the schema leaves nothing to explain; per the zero-parameter baseline this is a 4. There is no argument syntax the description could add value on.

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?

Concrete examples ('how many memecoins launched on pump.fun', 'what memecoin launchpads earned in fees') plus 'Every Tickerz Index: what it counts, its source, the newest day...' make the verb (list all) and resource (Tickerz indices) unmistakable. It never names the sibling get_index, however, so the agent gets no explicit routing signal for the single-index case.

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 someone asks...' enumerates many concrete trigger questions, which is strong positive guidance for invocation. There is no when-not guidance and no alternative tool is named, so the agent must infer that get_index handles single-index lookups.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by explaining that the response is Markdown text and that structuredContent contains the same text as JSON with model, url, markdown, and section headings, which is useful beyond 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?

The description is concise and front-loaded: the first sentence states the tool's purpose and source, the second clarifies no proprietary parameters, and the third describes the output format. Each sentence earns its place without unnecessary detail.

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 no-parameter, read-only tool, the description is complete. It covers what the tool returns, the serialization structure of the output, and the public source URL. The absence of an output schema is mitigated by the explicit structuredContent description.

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 input schema has zero parameters, so the baseline is 4. The description explicitly says 'No proprietary parameters,' confirming there are no hidden inputs and that the tool is parameter-free.

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 (Public Sigma-1 methodology) and the produced result (text), and distinguishes it from the sibling tools by its standalone methodology focus. However, it lacks an explicit verb like 'retrieve' or 'get', and does not directly contrast itself with the sibling 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 provides no guidance about when to use this tool versus alternatives such as open_questions or get_question. The only contextual clue is the title and the standalone nature of the description, which is insufficient for an agent deciding among siblings.

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 annotations only marking it as a write (readOnlyHint=false), the description carries substantial extra load: a 48-hour processing window, the two possible outcomes (built as a ticker or a posted rejection reason), a dedicated response URL, the fact that submissions are never shown publicly, a 3-per-day rate limit, and 'Free'. This is exactly the behavioral context annotations cannot supply.

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 long, but front-loads the trigger condition and every subsequent sentence adds a distinct behavioral fact (timeline, outcomes, privacy, rate limit, cost). There is mild redundancy in the closing marketing line about /launch, but overall it is dense and well-ordered.

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 submission tool with no output schema, the description covers what happens after the call, the return value ('count of numbers named so far'), rate limits, privacy, and cost. An agent has everything needed to set expectations and call correctly.

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 parameters are already documented. The description mostly restates the schema (one line, 3-160 chars, source location, ticker format) rather than adding new meaning; it also loosely says '2 to 12 letters or digits' where the schema allows maxLength 13, a minor mismatch. Baseline 3 is appropriate.

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 frames this as a request/submission tool for counts Tickerz does not yet publish, and even equates it to POST /api/indices/requests. It distinguishes itself from siblings like get_index/list_indices by targeting unpublished numbers, though the core verb ('request a new ticker to be built') is conveyed narratively rather than stated crisply up front.

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 an explicit trigger ('when someone wants a number counted that Tickerz does not publish yet, or a market needs a number nobody sells') and names an alternative route for on-chain counts via /launch. The condition that selects this tool over alternatives is spelled out, not inferred.

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 (readOnly, idempotent, non-destructive), and the description adds substantial behavioral context beyond that: accepting_answers is true until 4 hours after open, the crowd split stays null until then, and the three nulls are frozen at creation. It omits pagination/volume limits, so 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?

The purpose is front-loaded in the first clause, but the body is a single dense run-on paragraph packed with domain-specific terms. Every sentence carries information, yet the wall-of-text structure hurts readability without a clear field-by-field breakdown.

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 must carry the return-value burden, and it does explain the returned fields (score, volume multiple, three nulls, Tickerz answer, calibration hit rates). It is highly complete for a complex domain tool, missing only edge cases like empty/open-empty states.

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% for the single symbol parameter, so the schema already documents it as an optional ticker. The description's 'Optional symbol filter' adds no syntax or format detail beyond what the schema provides, making the baseline 3 appropriate.

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 opening clause states a specific resource and state: the referee's questions still awaiting answers, explicitly mapped to GET /api/questions?state=open. It is distinguishable from the single-question sibling get_question, though heavy domain jargon ('referee', 'Tickerz') slightly obscures the plain purpose.

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 notes an optional symbol filter and that it is 'not advice', but gives no explicit when-to-use or when-not guidance and never routes the agent to alternatives like get_question, base_rate or board for related data. Usage must be inferred from the 'still waiting on their answer' phrasing.

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, idempotent, closed-world. The description adds value beyond that: receipts become null until due, cursor semantics via next_before/next_before_id, and a deprecation horizon (peak_heat until 2026-12-31). Strong added context despite annotations doing the safety profile.

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 dense paragraph mixing return-shape details, cursor semantics, filter behavior, deprecation notes, and cross-endpoint references. Front-loaded usage is good, but the wall of clauses about null receipts and cursor edge cases is hard to parse; it should be broken into bullets or short sections.

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?

No output schema, yet the description enumerates the return fields (receipts, benchmark, score_at_open, peak_score, driver, proof_url, next_before/next_before_id, peak_heat alias) and cursor contract, so an agent can consume the response. Would reach 5 with clearer field/key naming for the proofs rows.

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%, so baseline is 3. The description goes further, explaining interaction between 'before' and 'before_id' (skip vs. include same-time events) and clarifying that 'symbol' filters in the query so 'limit' counts only that ticker. Adds real semantic value on top of 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+resource: closes events with their receipts, newest first. Distinguishes from siblings like arena, base_rate, board by describing a concrete track-record surface with named fields. An agent can tell what this returns without opening anything.

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?

Opens with an explicit when-to-use trigger ('Use when someone asks how past attention spikes turned out, or wants a track record they can check, losses included') and mentions 'Same store as GET /api/receipts'. Does not name an alternative sibling to use instead, so it falls short of 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?

Far beyond the annotations, it discloses handle claiming (first address owns it), the one-time handle_key secret and its cross-address effect, one-forecast-per-handle-per-question with 'latest before close stands', hidden-until-close behavior, the exact grading formula, the 3-graded standings threshold, referee limits (1 per caller, 3 per address, first stands, already_answered true), 4-hour close with OpenTimestamps batches, 24-hour grading, and no-login/no-money constraints. Nothing here contradicts the readOnly=false / idempotent=true hints.

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 'Two kinds of forecast' front-loading and the closing 'Both:' sentence give it a usable skeleton, and most sentences carry non-obvious rules (grading, close timing, repeat handling) that cannot be found in the schema. It is dense with long multi-clause sentences, though, which makes skimming harder than it needs to be.

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 return-value burden and does cover the key outputs (handle_key shown once, already_answered true, public standings, named agent answers). It does not describe the shape of a normal success response (e.g. confirmation or forecast id), which is the remaining gap for an 8-parameter, two-mode 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?

Schema coverage is already 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema cannot express: handle_key must accompany every later forecast under a handle, probability must agree with answer, and agent names are never counted in the crowd split. That relational context lifts it above the baseline.

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?

Opens with an explicit taxonomy ('Two kinds of forecast. 1) Arena (numeric) ... 2) Referee (attention question)') and names the specific resources involved (question_id, handle, value, answer, probability). An agent can immediately tell this tool apart from siblings like arena or open_questions because the description states which ids come from which sibling.

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 explicit routing conditions: Arena ids come from the arena tool, Referee uuids come from open_questions, and ticker can substitute for question_id. That is strong mode-selection guidance, but it never states when an agent should prefer this tool over alternatives or what to do if an id matches neither source.

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