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

No annotations are supplied, so the description carries the full burden. It does disclose genuinely useful behavior: resolved items are excluded, security incidents are capped at 30 days, voting items persist only "until they close" or until the network upgrades, and each alert carries a deadline, expiry date, affected audience and source link. What it omits is any statement of cost, rate limits, freshness/caching, or what an empty result means — the description also never explicitly frames the call as a safe read.

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?

Dense but well ordered: identity and inclusion/exclusion rule first, then the enumerated sources, then the per-alert shape, then the filter, then concrete use queries. Every clause carries information; nothing is padding.

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 no annotations, the description does the necessary work by describing the per-alert fields (deadline, expiry, affected party, source link) and the freshness/liveness rules. Paging behavior is left to the schema, which documents it fully, so completeness is nearly there — only the response envelope shape and any cost/latency expectations are unaddressed.

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 all three parameters are already documented, including the level enum's severity-floor semantics and limit/offset paging. The description's "Filter by level (critical/important/ecosystem/all)" merely restates the enum and says nothing about limit or offset, so it adds no meaning beyond the schema — 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?

States a specific verb and resource ("Get the NEAR Radar") and then enumerates the exact contents — protocol upgrades with validator votes, CODE_RED/security nearcore releases, House of Stake votes and timelocks, HSP drafts, 30-day security incidents, dated events. The inclusion criteria ("what is changing on NEAR now and needs action, and nothing that has already resolved") distinguish it clearly from sibling feeds such as get_breaking_changes, list_incidents or list_proposals.

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 explicit trigger phrases ("what is about to change or break on NEAR", "is there a protocol upgrade", "what is House of Stake voting on") plus a negative condition (nothing already resolved), which is real usage guidance. It stops short of naming the overlapping siblings (get_breaking_changes, get_protocol_status, list_proposals) to say when those should be preferred instead.

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