Check the local Firefox connection state and available extension capabilities without granting access, so you can confirm browser readiness before using tools.
Report connection state and extension capabilities without granting access.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description contributes one genuinely new behavioral fact — that calling it does not confer access — but says nothing about what 'connection state' or 'capabilities' actually contain, which matters since there is no output schema.
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?
A single front-loaded sentence with no filler or repetition. It is efficient, though its terseness leaves the return content undefined, which is a completeness issue rather than verbosity.
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?
The tool is simple (no params, no nesting), but with no output schema the description is the only place an agent could learn what 'connection state' and 'extension capabilities' look like in a response. That return-shape information is absent, leaving a real gap for an agent deciding whether this tool answers its question.
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?
The tool takes zero parameters, so there is no parameter semantics to add; the baseline of 4 applies. Nothing in the description conflicts with the empty schema.
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 names a specific verb ('Report') and specific resources ('connection state' and 'extension capabilities'), which is enough to distinguish a status probe from action-oriented siblings like firefox_request_access or firefox_list_tabs. It stops short of naming those siblings, so differentiation relies on the reader inferring it from the phrase 'without granting access'.
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?
The clause 'without granting access' implies this is a safe pre-flight check to run before attempting authorized operations, but the description never says explicitly when to call it or when to prefer firefox_request_access instead. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.