Crypto Pulse

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: it is free (no payment), timestamps are in UTC, and the response includes entry counts plus leaderboard top. It does not discuss rate limits or how fresh the round data is.

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 sentence with the cost signal ('FREE ... No payment') front-loaded and the returned fields enumerated without filler. Nothing in it is redundant with the schema or annotations.

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

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

With no input parameters and no output schema, the description carries the burden of describing the return value, which it does by listing the four data groups. Remaining ambiguity is minor, e.g. how many rows 'top of leaderboard' contains.

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; the 4 baseline applies. It correctly avoids inventing arguments and instead describes the parameterless return surface.

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?

Names a specific resource (the current Crypto Pulse Prediction Arena round) and enumerates exactly what it returns: open/cutoff/close UTC times, entry acceptance status, entry counts, and leaderboard top. That clearly separates it from arena_submit_prediction, though the partial overlap with arena_leaderboard is never addressed by name.

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 mention of 'whether entries are accepted' implicitly signals this is the pre-submission status check, and 'FREE ... No payment' clarifies it is a cost-free read. But there is no explicit when-to-use, no exclusions, and no mention of arena_leaderboard as the alternative for full standings.

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 and closed-world, so the description's added value is the ordering behavior: ranked by average absolute % error after scoring, and by earliest submission for complete entries before close. That directly affects how the agent should read the output. It doesn't mention cost limits beyond 'FREE' or how incomplete entries are handled in the returned list.

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

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

Two dense sentences with the default surfaced early and no filler beyond the 'FREE' tag, which does convey a real constraint. The semicolon-joined ranking clause is compact but slightly crammed.

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 ordering and does so for both pre- and post-close states. It doesn't sketch what fields a leaderboard row contains (rank, error values, entry identity), which would help an agent use the result without a probing call.

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 documents the YYYY-MM-DD format, so the baseline is 3. The description adds the one thing the schema lacks: the default value when round is omitted, which is operationally significant for a zero-required-param 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?

States a specific resource (arena leaderboard) scoped to a round, with the default made explicit. It also names the ranking basis (average absolute % error across BTC/ETH/SOL), which separates it cleanly from siblings like arena_current_round and arena_submit_prediction.

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 'default: current entry round' note tells the agent it can call with no arguments for the common case, and the two-state ranking note implies when results are meaningful (before vs. after close). It stops short of explicitly naming an alternative tool or a when-not-to-use condition.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful non-schema context: manual sponsor-funded prize payout after review, free entry with no purchase required, and the assurance that the server never handles bot private keys. That is material behavioral context an agent could not get from structured fields.

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?

Everything is packed into a single front-loaded sentence with no filler, and the most decision-relevant facts (free, daily UTC rounds, scoring method) come first. It is dense to the point of being a run-on, but no sentence is wasted.

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 informational tool with no output schema, the description covers the rule domains an agent needs: cadence, assets, cost, scoring metric, payout process, and key-handling policy. Only minor gaps remain, such as prize sizing or tie-breaking, which are arguably outside a summary's scope.

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 and the schema is fully covered, so there is nothing for the description to compensate for. Baseline of 4 applies; no parameter semantics are needed or missing.

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 establishes this tool as the source of the Crypto Pulse Prediction Arena rules, enumerating the concrete rule domains (round cadence, asset coverage, entry cost, scoring, prizes, key handling). It is easy to distinguish from siblings like arena_current_round or arena_leaderboard, which return state rather than policy. It stops short of an explicit 'returns the rules' framing, but the intent 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?

Usage is only implied: an agent can infer this should be consulted before submitting predictions or interpreting scores. There is no explicit statement of when to call it versus arena_current_round, and no exclusions or prerequisites are named.

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?

Adds substantial context beyond the annotations: the operation is free, the server never receives private keys, and signing is ed25519 with base58 encoding over a canonical message. It also clarifies the upsert nature (submit *or* update). It stops short of disclosing rate limits, cutoff behavior at round close, or what a rejected signature does.

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 dense sentences with the key incentive ('FREE') front-loaded, followed by the trust model and the signing procedure in execution order. No filler or repetition of the schema.

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

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

For a 6-param mutation with no output schema, the description covers the critical preconditions (canonical message source, key custody, signature format). It omits what a successful submission returns and any timing constraint relative to round settlement, which an agent would still want.

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 83%, so the schema already documents roundId, wallet, price, signature and botName. The description adds genuine meaning for `signature` — that it is ed25519 base58 over the canonical message sourced from arena_rules/arena_current_round — which is not derivable from the schema alone.

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 pair (submit or update) and resource (signed BTC/ETH/SOL price prediction) scoped to the arena round, plus whether the round is current or supplied. This is unmistakable against siblings like arena_leaderboard or get_market_spots, which are read-only market/ranking 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?

Explicitly tells the agent to sign the canonical message obtained from arena_rules / arena_current_round, which is a real prerequisite chain naming siblings. It does not state exclusions (e.g. whether updates are allowed after round close), so it falls short of a full when/when-not guide.

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 declaring read-only/open-world, the description adds critical behavior: the $0.02 USDC cost on Solana, x402 payment flow, that the call returns payment requirements and an HTTP URL, and that data is fetched by GET after payment. That is substantial context beyond structured fields.

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-loads paid purpose and cost, then explains the payment handoff and free alternative in a compact form. The x402/Solana USDC detail is repeated across sentences, slightly reducing efficiency.

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 paid two-step external HTTP tool with no output schema, it explains cost, payment requirements, URL return, and alternative preview. It still leaves the exact post-GET payload unspecified, but the key invocation path is covered.

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

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

Schema description coverage is 100% and the single optional asset enum is fully documented in the schema. The description itself does not add syntax or meaning for the asset parameter, 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?

States a specific paid live 'full pulse' and enumerates the four data sources it combines, so the resource is concrete. It explicitly distinguishes itself from get_market_sample as the free preview, though it does not explicitly route around get_market_spots.

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

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

Gives a clear alternative for a free preview ('call get_market_sample first') and the paid condition is front-loaded. It stops short of spelling out all sibling choices, notably when get_market_spots alone would suffice.

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 readOnly and openWorld annotations, it discloses that data may be up to 15 minutes old, that this is a free sample, and that the JSON shape matches the paid /v1/pulse endpoint. These are exactly the behavioral traits an agent needs to decide whether freshness matters.

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 front-loaded with the free-sample purpose, then lists contents, staleness, and the alternative in a compact set of sentences. Every sentence 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 and zero parameters, the description carries the burden of explaining return content, and it does so by enumerating the included data and noting the shared JSON shape with the paid endpoint. Staleness is also disclosed, making the definition complete 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?

There are zero input parameters, so the baseline is 4 per the rubric. The schema is empty and requires no parameter explanation, but the description does not need to add parameter semantics.

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

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

The description clearly states this is a free crypto market pulse sample and enumerates its contents: spots, Fear & Greed, Hyperliquid funding, DefiLlama TVL/yields, and a plain-English summary. It explicitly contrasts with the paid sibling get_market_pulse, so an agent can distinguish it without inspecting 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?

It directly tells the agent to use get_market_pulse for live paid data, implicitly framing this tool as the free/stale-data alternative. The condition selecting the alternative is explicit, leaving little to inference.

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 only declare readOnly and openWorld, so the description carries the real burden and delivers: the call is PAID ($0.005 USDC) and returns payment requirements plus an HTTP URL for x402. What it does not disclose is the payment mechanics — whether the tool itself settles payment or just hands back a challenge, and whether repeated calls are charged each time.

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

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

Three short sentences, each doing distinct work: what it returns, what it costs, and which sibling to use instead. Cost and the paid flag are front-loaded in capitals so a scanning agent cannot miss the billing implication.

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 exists, and the description compensates by naming what comes back (payment requirements + HTTP URL for x402). Combined with the pricing disclosure and sibling routing, an agent has enough to decide and call correctly; only the x402 handshake sequence remains implicit.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly says nothing about arguments and instead spends its words on cost and return shape, which is the right allocation 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?

States a specific verb and resource ('live BTC/ETH/SOL/HYPE spot prices') with an explicit scope qualifier ('only') and a price point. An agent can immediately distinguish this from get_market_pulse (broader market data bundle) and get_market_sample (free preview).

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 routes the agent: 'Prefer get_market_pulse when you also need Fear & Greed, funding, or DeFi' names the alternative and the exact condition that selects it, and 'Free preview: get_market_sample' gives the zero-cost fallback. Both siblings are addressed with concrete selection criteria.

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