history_query

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

With no annotations, the description carries the full behavioral burden and does disclose an important trait: object IDs are profile-scoped and must never be reused across profiles. It does not explicitly say the operation is read-only, whether results are ordered or paginated, or what happens when no matches exist, though the presence of an output schema reduces the need to describe return values.

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?

Two short sentences with no wasted words. The required-parameter constraint and the profile-scoping warning are front-loaded and easy to act on before opening the schema.

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 five-parameter read tool with an output schema, the description covers the key setup requirement and profile-scoping semantics. It is incomplete in that it never routes the agent between this and history_get_recent or describes result ordering/limits beyond the schema's max_results default, which are the main remaining ambiguities.

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 80% and already documents query, start_time, end_time, and max_results well. The description adds value where the schema is silent: profile_id is required, it is an integer obtained from profiles_list, and its namespace is local to that profile. This fills the one gap in the schema rather than repeating it.

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 description states a specific verb and resource ('Search browser history'), which is clear enough for an agent to understand the operation. However, it does not differentiate this tool from the sibling 'history_get_recent' or explain how a search differs from retrieving recent entries, leaving the boundary between the two tools implicit.

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 only implied by 'Search browser history'. The description adds a required prerequisite ('obtain [profile_id] from profiles_list') but never states when to use this tool instead of history_get_recent, history_delete_item, or bookmarks_search. It provides setup guidance rather than decision guidance.

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