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

Annotations already cover read-only, idempotent, non-destructive, so the safety bar is met. The description adds genuinely decision-relevant context for a search tool: responses are private/no-store, removal cuts public access, and critically that returned document text is untrusted data and never agent instructions — a real prompt-injection guard for a tool whose output is third-party content.

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?

The purpose is front-loaded, but the bulk of the text is account-level boilerplate (free tier limits, paid-capacity expiry, purchase flows, billing) unrelated to performing a search. Sentences like "Purchase requires an explicit browser action" do not earn their place in a search tool's definition.

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?

Safety, privacy and untrusted-content behavior are well covered, and pagination is handled in the schema. With no output schema, however, the description says nothing about what a hit contains or how results are ordered, which leaves an agent guessing about the return shape.

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 coverage is 100%: q documents length, case/accent insensitivity and FULLTEXT rules, and after documents cursor continuation. The description adds nothing about base_id, q, or after, so the baseline 3 applies.

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?

"Search the full text of your base" gives a specific verb and resource, and "Personal-account operations" hints at the personal scope that separates it from team_search_base and public_search_base. The sibling distinction is only implied by a scope label rather than stated, so it doesn't reach a 5.

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?

Nothing says when to use this instead of search_collection, team_search_base, public_search_base, or ask_base_question. The "Personal-account operations" phrase is the only routing signal, and it is a scope note rather than a use-case rule.

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