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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description genuinely adds freshness ('refreshed every 5 minutes'), per-block provenance and timestamps, and an explicit failure signal (stale=true if the source did not answer). It does not say what happens when many blocks are stale or how large the payload is. openWorldHint=false is not contradicted: the tool reads a pre-collected cache rather than reaching the open web itself.

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?

Content is front-loaded with 'Collective attention' and briefly closed with the no-signals caveat, but the core is one long run-on catalog of sources separated by commas. Every item is arguably useful for retrieval matching, yet the enumeration is unstructured and could be grouped into attention / network / markets / macro blocks.

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 a fair job by listing the blocks plus source, time, and stale fields. It still leaves the exact response shape and units (e.g. how 'surges' or 'typical moves' are expressed) implicit, which matters for a tool returning this many heterogeneous series.

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?

Zero parameters, so there is nothing to disambiguate; all selectivity is server-side. The description correctly signals a no-argument, fetch-everything tool, which sets the right expectation for an agent.

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 set in concrete terms: Wikipedia pageview surges, Kraken volatility spikes, IODA outages, OONI blocking, UK/OFAC sanctions, German day-ahead power price, BTC funding/OI, mempool fees, ECB rates, HICP, stablecoin supply. An agent knows exactly what data comes back. It never differentiates itself from siblings such as get_prices, get_indices, or get_crisis, 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?

No when-to-use or when-not-to-use guidance, and no alternatives are named. The only steer is the closing caveat 'Data only, no trading signals', which constrains interpretation but does not tell an agent which situations call for this tool over get_prices or get_crisis.

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