Skip to main content
Glama
Firefox Bridge

Firefox Bridge

by matrodrigs

firefox_history

Read-onlyIdempotent

Search local Firefox browser history by text query and return only origins with read access after the user grants optional permission.

Instructions

Search browser history after the user enables the optional permission. Return only origins with read access.

Input Schema

NameRequiredDescriptionDefault
queryYesSearch text.
maxResultsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

The annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description does add real value by disclosing the optional-permission gate and the fact that results are filtered to origins with read access. It says nothing about result volume, ordering, or what an empty or denied result looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler, and the permission precondition is front-loaded before the result-filtering note. The second sentence is slightly cryptic in isolation but not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining the return shape, and 'only origins with read access' is only a partial hint. It also leaves maxResults undocumented and doesn't say how results are limited or ordered, but for a simple two-parameter search this is roughly the minimum viable level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: 'query' is documented as 'Search text.' while 'maxResults' (integer, 1-100) has no description at all. The tool description adds no parameter meaning whatsoever, so the maxResults semantics are missing from both structured fields and prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: 'Search browser history'. That is clear enough to act on. However, it never distinguishes itself from the sibling firefox_tab_history, which is a plausible source of confusion for an agent picking between the two.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states one precondition: the user must have enabled the optional permission. Beyond that, it offers no when-to-use guidance relative to siblings such as firefox_tab_history or firefox_bookmarks, and no guidance on what a query may contain or what to do when access is denied.

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