ccn_story_threads_info

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

With no annotations, the description carries the full burden, and it does disclose real behavior: free access, deterministic exact-match linking with no clustering, auditability, and that threads rebuild after each daily edition (useful freshness signal). It omits what a call actually returns, how large the graph is, and whether there are rate or caching constraints.

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 [FREE] tag and the core concept, then supporting detail on linking rules and refresh cadence; nearly every sentence carries information. The entity enumeration (Bitcoin, Solana, Coinbase, Hyperliquid, x402, AgentWorld...) is bulky, and placing raw GET URLs inside a tool description risks being mistaken for instructions rather than output documentation.

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 tool with no output schema, the description needs to convey the response shape, which it only gestures at by pointing to stories.json and /stories/. The agent understands the concept and the linking rule but not the payload structure (thread keys, ordering fields, size), which matters precisely because no output schema exists.

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 with a fully empty schema, so there is nothing for the description to disambiguate. Baseline 4 applies; the description at least makes clear no scoping or filter input is expected.

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 definition explains the underlying dataset well — entity-anchored narrative chains of CCN articles, linked by exact headline match. But it never states the tool's own action or return: the sentence 'Machine-readable graph: GET https://...' reads as an external URL rather than confirming that calling this tool returns that graph. The agent is told what the data is, but not unambiguously what invoking the tool produces.

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 and no routing among closely related siblings such as get_crypto_news, get_ccn_freshness, or get_ccn_synthesis, all of which could be plausible alternatives for news retrieval. Usage is only implied by the concept of threads, leaving the agent to infer the selection criterion.

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