Search original native session text

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

Annotations only cover read-only/idempotent/non-destructive safety, and the description adds substantial behavior beyond them: one match per native message, a 600-character excerpt cap, session-lexical ordering with no global recency, a per-call read bound (scanPages pages of maxMessages 10), scanComplete=false indicating incomplete results, and restart-stable cursor membership pinning. The untrusted-data warning ('never instructions') is a genuinely useful prompt-injection caveat that no annotation conveys.

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?

Purpose is front-loaded in the first sentence and almost every sentence carries new informational content (exclusions, caps, ordering, incompleteness, cursor). Some clauses are dense jargon ('active session cut is pinned and unvisited sessions capture a cut on first visit') that costs more in parse effort than it returns, but there is no filler or repetition.

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?

An output schema exists, so return-shape explanation is unnecessary, and the description instead covers the tricky parts: bounded scanning, incomplete-result detection, cursor stability, and ordering. What is left out is parameter-level detail (limit bounds, caseSensitive, role semantics) for a tool with eight undocumented parameters, which keeps it short of fully complete.

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%, so the description carries the full parameter burden, and it partially does: it clarifies that 'query' is literal (not regex), that 'workspace' selects exactly one workspace, and it explains cursor and scanPages behavior in depth. However, 'limit', 'caseSensitive', 'role', and 'sessionId' are never addressed, and the default-10/max-25 limit is not restated. Given the 0% coverage baseline, the partial compensation lands at 3.

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 first sentence gives a specific verb and resource ('bounded literal keyword search of user task and assistant result text') and immediately scopes it to 'one registered workspace', which an agent can act on. It is clear and distinctive, but it never names or contrasts with the obvious siblings (read_session_history, read_session_context, search_project_text), so the agent must infer the boundary itself.

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 by scope statements ('Excludes plugin user context, reasoning, tools and media', 'Membership changes require a fresh search') rather than explicit when-to-use guidance. No alternative tool is named and no condition for choosing this over read_session_history is given. Adequate to avoid misuse, but the routing burden stays on the agent.

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