search_transcripts

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

The description discloses one genuinely useful behavioral trait beyond the name: the tool reads from the SQLite cache and will not rebuild it, implying results may be stale or empty on a cache miss. However, with no annotations provided, the description carries the full burden and does not state read-only guarantees, cache-miss behavior, or any side effects.

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?

A two-clause description with the primary action front-loaded and zero filler. The behavioral warning about not rebuilding the cache is appended efficiently in the second clause; every word earns its place.

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 tool with 6 parameters, no annotations, and 0% description coverage, this is too thin. While an output schema covers return values, the interplay of search_mode, case_sensitive, context_segments, and podcast_id is unexplained, leaving an agent guessing at valid invocations. The core purpose is clear, but the surrounding context a caller needs is largely absent.

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 0%, and the description contributes no parameter-level meaning. Ambiguous values such as search_mode='auto' and context_segments are left undefined, and with no enum constraints in the schema the agent has no way to know valid modes or semantics. The description must compensate for the low coverage but does not.

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 — searching transcript segments within the SQLite cache — and adds the explicit caveat that it will not rebuild the cache, which differentiates it from the rebuild_cache sibling. An agent understands exactly what object this operates on and can distinguish it from related search tools like search_mentions.

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?

The 'won't auto-rebuild cache' clause implies a usage context (use this when searching existing cached data, not when fresh data is needed), but no alternative tools are named directly and no explicit when-to-use/when-not-to-use guidance is given. Routing to rebuild_cache or search_mentions is left to inference.

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