browser_list_historyRetrieve recent Firefox browsing history entries with an optional limit to inspect past browsing activity or provide context to AI agents.
Read recent history entries (privileged context). PlacesUtils.history.executeQuery is synchronous and returns a result whose root must be container-opened.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max entries (default 20) |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint already declares the safety profile, so the bar is lower. The description adds that this is privileged and that the underlying call is synchronous with a container-opened root, which is useful consumption context, but it is framed as internal API detail rather than agent-facing behavior (ordering, recency window, what 'recent' means).
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 tight sentences with the purpose front-loaded and no filler. The second sentence is somewhat jargon-heavy ('container-opened') but is not wasted, since no output schema exists to explain the result shape.
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?
With no output schema, the description should clarify what is returned and in what order; instead it gestures at an internal result object ('root must be container-opened') that most agents cannot act on without further knowledge. It is adequate for a one-parameter read tool but leaves the return contract murky.
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% for the single 'limit' parameter, including default and maximum, so the schema does the heavy lifting. The description contributes nothing about the limit parameter, making baseline 3 appropriate.
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 ('Read recent history entries') and adds a scope qualifier ('privileged context'). It does not, however, differentiate itself from close siblings like browser_traverse_history or browser_history_manage, so an agent cannot tell purely from the text which history tool to pick.
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?
There is no when-to-use guidance and no named alternative, despite browser_traverse_history and browser_history_manage being obvious confusable siblings. The only contextual hint is the parenthetical 'privileged context', which implies a permission requirement but does not route the agent anywhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.