ti_daily_brief

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

With zero annotations, the description carries the full disclosure burden and credibly meets it: sources are polled directly via RSS, no Playwright/browser automation, and each item is automatically enriched with TTPs, CVEs, actors, and malware. It does not disclose return format or runtime, but the RSS-vs-Playwright clarification and explicit extraction pipeline are substantive behavioral disclosures beyond the schema.

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?

Four sentences with zero waste: purpose, extraction behavior, filtering options, cadence, and the technical RSS/Playwright note each earn their place. The core purpose is front-loaded ahead of details, and nothing redundantly repeats schema content.

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 3-optional-param aggregation tool, the description covers scope, extraction behavior, filtering, cadence, and technical implementation. With no output schema, the return shape is undisclosed and runtime is not hinted, but an agent has enough guidance to invoke it correctly with appropriate parameter choices.

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 the baseline of 3 applies. The description reinforces the schema by echoing industry/lookback filtering and the all-21-vendors default, but adds essentially no new semantics beyond what the schema already provides via defaults, max bounds, and a concrete industries example.

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 — 'Generate a daily threat intelligence brief' — and gives concrete scope: scanning all 21 vendor and community sources and extracting MITRE TTPs, CVEs, actors, and malware. This clearly differentiates it from the many sibling search/lookup tools like anssi_search or ti_multi_source_ttp_lookup, which target a single source or entity type rather than producing a cross-source daily summary.

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?

'Run this daily to stay current on the threat landscape' is explicit cadence guidance for when the tool is appropriate. It also implies when it is not: a broad aggregation brief rather than a targeted on-demand lookup — but it never names alternatives such as ti_multi_source_ttp_lookup, so exclusions are left to inference. Clear context without explicit when-not-to-use wording.

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