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

Annotations already establish the safe read-only/idempotent profile, so the description earns credit by adding genuinely non-obvious behavior: the economy, machine-analysis and interconnection views are metadata-only until a lineage-filtered rebuild removes denied derivatives, and 'availability never implies publication readiness' with statuses, gates, counterevidence, limitations and right-to-reply state remaining attached. Those are real constraints an agent could not infer from the schema. It stops short of describing return shape or how the limit interacts with results.

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-loading the view list is the right structure and the second sentence carries real caveat value, but the definition is a single dense paragraph of stacked jargon ('named-key fat-object joins', 'topic-surface-only', 'denied derivatives') that an agent must parse as one unbroken clause chain. The content earns its place; the packaging does not.

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 four-parameter, no-output-schema, read-only tool, the description covers the decisive question (which view to read and what restrictions apply) and flags the gating semantics an agent must not misreport. The shortfall is moderate: status/priority filtering behavior and limit/pagination semantics are left entirely to the schema, and no indication of what a returned story or dossier 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?

With only 50% schema coverage, the description compensates well where it matters most: every one of the seven 'view' enum values is given meaning beyond its bare name, which the schema does not do. However, it says nothing about 'limit' (default 10, max 50) or about how 'status' and 'priority' apply per view beyond the terse schema descriptions, so two of four parameters remain unenriched.

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 ('Read one evidence-first reporting surface') and then enumerates all seven views with a one-clause characterization of each, so an agent can tell 'wire' from 'investigations' from 'editorial-readiness' immediately. The remaining gap is that neither the resource nor the views are related to any sibling (get_signal, whats_happening, research_catalog), and the framing language ('evidence-first reporting surface', 'named-key fat-object joins') is domain jargon that doesn't map cleanly to a plain noun.

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 directed: 'without scraping a page or guessing a filename' hints at when this replaces file/page access, and the per-view glosses let an agent pick a view. But there is no explicit when-not guidance, no statement of how this differs from get_signal, list_signals or whats_happening, and no prerequisites or sequencing advice.

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