Firefox DevTools MCP
Server Quality Checklist
Latest release: v0.9.15
- Disambiguation4/5
Most tools target distinct resource+action pairs (navigate, close, list, select, click, hover, fill, drag, upload, etc.). A few near-overlaps exist, such as get_firefox_info vs get_firefox_output and screenshot_page vs screencast_start, but their descriptions clarify the difference.
Naming Consistency4/5The dominant pattern is verb_noun, often with a by_uid suffix for element interactions (click_by_uid, hover_by_uid, etc.). Minor inconsistencies include list_pages vs new_page (plural vs singular) and the longer resolve_uid_to_selector, but the overall convention is clear.
Tool Count2/5At 31 tools, this exceeds the 25+ threshold for a heavy tool set. While many tools cover distinct features, several are auxiliary helpers (clear_snapshot, resolve_uid_to_selector, get_firefox_info) that could potentially be merged or removed without losing core functionality.
Completeness4/5The tool surface covers a broad range of browser automation needs: page lifecycle, element interaction, snapshots, screenshots, downloads, dialogs, history, viewport control, extensions, screencasts, and script execution. Minor gaps exist (no explicit wait/condition, no direct text extraction, no iframe handling), but agents can generally work around them.
Average 3.8/5 across 31 of 31 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 64 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'HTML5 drag events', which adds a small implementation detail, but does not disclose side effects, requirements for the source/target elements, or what behavior occurs after the drag. With readOnlyHint=false, the mutation nature is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core functionality with zero wasted words. Very concise and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two fully documented parameters, so the description is minimally sufficient. However, it lacks broader context such as usage scenarios, potential side effects, or behavior when the drop target is invalid, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both parameters (fromUid and toUid), so the description adds no extra semantic value. Baseline of 3 is appropriate since the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (drag) and the target (another element), which is specific enough to distinguish from sibling tools like click, hover, and fill. However, 'to another' is slightly vague without referencing the toUid parameter, but the schema resolves this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites (e.g., element must be draggable or have a valid drop zone). The description does not mention any exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotation readOnlyHint=false. It does not mention that hovering may trigger events, require the element to be visible, or what happens when the UID is invalid. With annotations present, the bar is lower, but this description still fails to disclose any additional operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no extra words or redundancy. It front-loads the core action and is appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a complete schema and a readOnlyHint annotation, the description lacks any guidance on usage context, potential side effects, or behavior on failure. It is a minimal restatement of the tool's purpose and does not fully equip an agent to decide when or how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the uid parameter fully with the description 'Element UID from snapshot', and the tool description repeats 'by UID' without adding extra meaning. Since schema_description_coverage is 100%, the baseline is 3, and the description does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Hover over element by UID.' This specifies a concrete verb (hover) and resource (element), and it distinguishes itself from sibling tools like click_by_uid, fill_by_uid, and drag_by_uid_to_uid by the unique action it performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply states the action, leaving the agent to infer applicability from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only annotation is readOnlyHint=false, which indicates a write operation. The description does not add further behavioral details such as whether existing text is overwritten, whether input events are triggered, or any element requirements. It adds no value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the action and resource. Every word earns its place, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two fully described parameters, the description is minimally viable. However, it lacks important context such as side effects (e.g., whether it clears existing content) and how it differs from fill_form_by_uid, leaving clear gaps for an agent relying solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema, so schema coverage is 100%. The description's 'text input/textarea' and 'by UID' add slight domain context but do not significantly enhance meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fill') and resource ('text input/textarea') with a clear mechanism ('by UID'). It distinguishes from sibling tools like fill_form_by_uid, which fills multiple fields, by targeting a single element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as fill_form_by_uid or click_by_uid. The description merely states what it does without any contextual or exclusionary information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=false, and the description merely restates the mutating nature of the action ('Upload file'). Beyond this, it discloses no additional behavioral traits such as whether the file must exist, whether change events are triggered, or what happens on failure. It adds no value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of seven words, front-loaded with the verb and object. It contains no filler or redundant information, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter interface, the absence of an output schema, and the existing parameter descriptions, the terse description is largely sufficient. However, it lacks any mention of potential error conditions or prerequisites (e.g., file existence), which a safety-conscious agent might expect. Still, for a straightforward upload action, it is almost complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both uid and filePath described (one as 'File input UID from snapshot', the other as 'Local file path'). The description itself does not add any semantic detail beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Upload') and resource ('file input by UID'), clearly distinguishing it from sibling tools like fill_by_uid or click_by_uid. It conveys exactly what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. The description does not mention situations where it should be preferred over fill_by_uid or fill_form_by_uid, nor does it mention any prerequisites or exclusions. The only implicit hint is the term 'file input' in the schema, but the description itself offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false already signals that this is a mutating operation, and the description's 'Close tab' is consistent with that. However, the description adds no beyond-annotation context about edge cases (e.g., closing the last tab), side effects, or error behavior, so it meets the minimum but doesn't enrich the agent's understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately states the action and target. There is no redundant information, fluff, or nested structure. It is perfectly front-loaded and appropriate for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (one parameter, no output schema), the description lacks key contextual details such as how to obtain the tab index (e.g., via list_pages) or what happens if the index is invalid. There is no mention of tie-ins to sibling tools, leaving the agent to infer the workflow. For a minimal one-liner, it's adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a 100% description for pageIdx ('Tab index to close'), and the description's 'by index' adds no additional meaning. Since schema coverage is high, the baseline is 3, and the description does not improve clarity beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close tab by index' has a specific verb (close) and resource (tab), and the method (by index) distinguishes it from sibling tools like select_page or navigate_page. It is immediately clear what the tool does and how it differs from other page-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as after calling list_pages to obtain the tab index, or in contrast to other tab-manipulation tools. There are no prerequisites, exclusions, or explicit usage context—only a functional statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the description doesn't need to state that it performs a mutation. However, the description adds no additional behavioral context, such as what happens to the dialog or whether it only works for certain dialog types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler, entirely front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, this description provides the core verb and object but lacks context about the difference from accept_dialog or any side effects. It is minimally adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters and the schema is empty, so the description doesn't need to explain parameters. A baseline of 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (dismiss) and the target (browser dialog). The verb 'dismiss' distinguishes it from the sibling 'accept_dialog', which implies accepting the dialog instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool or when to prefer accept_dialog. The description only states what it does, leaving usage context entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, and the description adds no behavioral detail beyond the purpose. It does not mention side effects, failure behavior, or requirements (e.g., fields must exist), so it provides little extra transparency beyond the structured annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with the verb and object front-loaded. It contains no wasted words, though it could include a brief note about using it for multiple fields. It is appropriately short for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, 100% schema coverage, no output schema), the description adequately conveys what it does. The combination of description and schema provides sufficient context for an agent to invoke it correctly, though it lacks explicit linkage to the single-field sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the 'elements' array and its 'uid'/'value' fields fully documented in the schema. The description adds only the notion of 'multiple fields', which is already implied by the array structure, so it does not meaningfully augment the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill multiple form fields at once' clearly identifies the verb ('fill'), resource ('form fields'), and scope ('multiple', 'at once'). It distinguishes from sibling tool fill_by_uid, which likely handles a single field, by emphasizing the batch nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'at once' implies the tool's use for batch form filling, but there is no explicit guidance on when to choose this over fill_by_uid or any exclusions. The usage context is merely implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation. The description adds the specific return format (base64 PNG), which is helpful context. However, it does not disclose behavior when saveTo is set, such as whether a file path is returned or whether the output is no longer base64 in that mode.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states verb, resource, and format with no filler or redundant content. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but there is no output schema and the description only covers the default base64 return. It does not clarify what the response contains when saveTo is provided, even though the parameter schema explains the file-saving side. With no output schema, the description should have compensated for this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single saveTo parameter fully described in the input schema. The description adds no additional parameter detail, but the schema carries the burden, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'Capture' with resource 'page screenshot' and output format 'base64 PNG'. It clearly distinguishes from sibling tools like screenshot_by_uid, which targets an element (UID) rather than the whole page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus siblings like screenshot_by_uid or take_snapshot. It does not mention prerequisites, exclusions, or preferred contexts, so the agent is left to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: false already signals potential mutability, but the description adds no behavioral depth. It fails to disclose risks like arbitrary side effects, network calls, or page navigation, which are critical for an arbitrary JS execution tool. This lack of transparency could mislead agents into unsafe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one functional sentence plus a usage recommendation. Both parts are informative and there is no filler, making it well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a powerful tool like arbitrary script execution, the description lacks essential context such as return value handling, execution context, or safety considerations. The schema covers parameters but not the behavioral context. Given the tool's complexity and risk, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter documented. The description itself adds no parameter-level detail, but the schema already provides adequate semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a JS function in the page, using a specific verb and resource. It also implicitly distinguishes itself from sibling UID-based interaction tools by advising to prefer those for interactions, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly steers users away from using this tool for interactions ('Prefer UID tools for interactions'), which is a clear exclusion. While it doesn't state when to use it positively, the implication is that it's for custom scripting beyond standard interactions, which is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. While "buffer" hints at an internal tracking list rather than files, it does not explicitly state whether downloading files are affected, whether the action is irreversible, or what the side effects are. This is a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, but given the lack of annotations, the description should provide more behavioral context (e.g., whether it clears the internal buffer only, whether it deletes files). The word "buffer" implies non-destructive-to-files, but this is not explicit, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter semantics. The baseline for 0 params is 4, and the description adequately covers the no-parameter nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb "clear" and identifies the resource as the "tracked downloads buffer," making the tool's function clear. It distinguishes itself from siblings like list_downloads (which lists) and set_download_behavior (which sets behavior).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you want to reset the downloads tracking buffer, but it does not explicitly state when to use this tool vs alternatives or mention any exclusions. No alternatives are referenced from the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the action (clearing a cache) and adds 'Usually not needed' as a usage hint. With readOnlyHint=false, the agent knows it's a mutation, but the description doesn't disclose potential side effects (e.g., whether clearing affects existing snapshots or requires specific conditions). This is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the main action and a pragmatic qualifier. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool without an output schema, the description covers the core action and a usage hint. However, it doesn't elaborate on what 'snapshot cache' entails, when clearing becomes necessary, or what impacts it has on the broader snapshot workflow, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to explain any. Per the baseline for 0-param tools, the score is 4; no additional parameter meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear snapshot cache') with a specific verb and resource, distinguishing it from sibling tools like take_snapshot, which creates snapshots. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Only guidance is 'Usually not needed,' which hints at rarity but does not explain when the tool should actually be used, what prerequisites exist, or when to avoid it. No explicit context or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that 'UIDs become stale', a key behavioral trait beyond the readOnlyHint: false annotation. This adds meaningful context about side effects of navigation, though it doesn't elaborate on other state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The description is front-loaded with the action and includes an important caveat in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description covers purpose, parameter, and a notable side effect. It is sufficiently complete for the agent to understand the basic operation, though it could mention what happens to the current page state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the direction parameter fully described (enum back/forward). The tool description reiterates this but adds no extra parameter detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Navigate history back/forward' with a specific verb and resource, distinguishing it from sibling tools like navigate_page. The addition of 'UIDs become stale' further clarifies the scope and consequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies it is for history navigation, but does not name or exclude other navigation tools, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false already indicates a mutating operation. The description adds that it targets the selected tab, which is useful context, but does not disclose the full scope of navigation behavior (e.g., whether it waits for page load or the return value).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy, front-loading the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter navigation tool, the description combined with the schema covers the essential behavior. It is not missing critical information for basic use, though it does not specify return values or error behavior, which is acceptable given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the url parameter as 'Target URL' with 100% coverage. The description merely repeats 'URL' without adding format, validation, or semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Navigate) and resource (selected tab) and specifies the destination (URL). This clearly differentiates it from siblings like new_page (which opens a new tab) and navigate_history (which navigates history).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that a tab must already be selected, but it does not explicitly state when to use this over alternatives such as new_page or navigate_history. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=false annotation already signals mutation, and the description adds that it returns a tab index. However, it does not disclose side effects such as whether the new tab becomes active, whether the URL is validated, or any failure modes. The description provides the essential behavior but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action. No wasted words; every element contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers what it does and what it returns. It could mention whether the new tab is activated or if any restrictions apply, but for a basic 'new tab' operation this is nearly complete. The lack of an output schema is partially compensated by the explicit 'Returns tab index'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'url' parameter with 100% coverage. The description's 'at URL' phrase adds no further detail about URL formatting, required scheme, or behavior when omitted. Since schema coverage is high, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Open new tab at URL. Returns tab index.' This is a specific verb+resource combination that distinguishes it from sibling tools like navigate_page (which likely navigates the current tab) and list_pages. The output is also specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to create a new tab at a given URL) but does not explicitly contrast it with alternatives like navigate_page or select_page. It lacks any exclusions or 'instead of' guidance, so usage context is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint covers the read-only nature. The description adds the failure condition 'Fails if stale' and implies that the tool returns a CSS selector, which are useful behavioral details beyond the annotation. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the purpose and add one critical behavioral note. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter utility with readOnly annotations, the description covers the core purpose and a key failure mode. It lacks an explicit note about what 'stale' means, but the schema covers the UID source. The implied return value (CSS selector) is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'uid' as 'UID from snapshot' (100% coverage). The description does not add any additional meaning to the parameter beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resolve UID to CSS selector' uses a specific verb ('Resolve') and clearly states the resource (UID) and the output (CSS selector). This distinguishes the tool from sibling tools that operate on UIDs (e.g., click_by_uid) rather than resolving them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any statement about prerequisites, context, or explicit alternatives. 'Fails if stale' is a warning, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the effect of each behavior (silent save, cancel, reset) and mentions the requirement of a recent Firefox, adding transparency about the tool's operation. It doesn't state persistence or effects on existing downloads, but the core traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and then provide key details. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool without output schema, the description explains the modes, the dialog effect, and a prerequisite. It lacks persistence semantics and potential side effects, but overall it is sufficient for straightforward usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the enum values already explained in the parameter description. The tool description adds marginal detail like 'save silently to the default download directory' and dialog avoidance, but the parameter semantics are largely redundant with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool controls download handling with three explicit modes (allow, deny, reset) and notes it avoids the native save-file dialog. This verb+resource framing is specific and differentiates from download-list tools like list_downloads, though it doesn't name alternative tools explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting download policy but does not explicitly state when to prefer this over sibling tools like accept_dialog. 'Requires a recent Firefox' gives a prerequisite, and 'Avoids the native save-file dialog' provides context, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the agent knows it's a mutation. The description adds no additional behavioral details such as side effects, failure modes, or timing. It merely restates the dblClick parameter, which is already in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and no wasted words. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action with two well-documented parameters and no output schema, the description is complete enough. It covers the purpose and the optional double-click behavior without requiring additional detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both uid and dblClick. The description adds minimal extra meaning beyond the schema, only framing dblClick as a double-click toggle, which duplicates the schema description. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Click element by UID') with a specific verb and resource, and it distinguishes from sibling tools like hover_by_uid and fill_by_uid. Mentioning 'Set dblClick for double-click' further clarifies the tool's behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage from the action name but provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or alternatives, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, indicating a mutating action. The description adds that promptText is for prompt dialogs, but does not disclose other behavioral details such as blocking behavior or what happens if no dialog is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and then the parameter guidance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description provides enough context to operate. It could mention the contrasting dismiss_dialog tool, but the essentials are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description's mention of 'provide promptText for prompts' closely mirrors the schema's 'Text for prompt dialogs.' It adds no substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Accept browser dialog,' which is a specific verb and resource. It effectively distinguishes itself from sibling tools like dismiss_dialog, and the mention of promptText clarifies the dialog type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when you need to accept a dialog—and instructs to provide promptText for prompt dialogs. However, it does not explicitly contrast with dismiss_dialog or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond the readOnlyHint annotation by listing the specific type of configuration data returned. It describes what information is accessible, which helps the agent set expectations about the tool's output, though it does not detail any potential limitations or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the main action and includes specific examples. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema, read-only), the description provides sufficient context for selection and invocation. It names key configuration elements, though a more explicit note about the return format could slightly improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description has no need to explain parameter semantics. The absence of parameters is clear from the schema, and the description adds no extraneous information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves configuration information about the current Firefox instance, specifying concrete items like binary path, environment variables, and output file location. It distinguishes itself from the sibling tool get_firefox_output by focusing on configuration rather than output content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. While the purpose is clear, there is no mention of similar tools like get_firefox_output or when it would be preferable to use this one over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already declares readOnlyHint=true, so the safety profile is known. The description adds useful context by specifying what types of output are included (stdout/stderr, MOZ_LOG, warnings, crashes, stack traces) and that it returns recent output from a capture file. This enhances understanding without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary purpose. Each sentence earns its place: the first defines the tool, the second explains the source, and the third advises on filtering. No redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only log retrieval tool with fully documented parameters and a readOnly annotation, the description is sufficiently complete. It covers what the tool returns and mentions filtering. It could explicitly state the return format, but that is not critical given the simplicity and existing schema documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters (grep, lines, since). The description adds only generic references to 'filters' and 'recent output', which aligns with the schema but does not provide additional detailed parameter semantics beyond what is already present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Retrieve Firefox output (stdout/stderr including MOZ_LOG, warnings, crashes, stack traces)'. It specifies the resource (Firefox output from a capture file) and distinguishes it from sibling tools like get_firefox_info, which likely retrieves metadata rather than logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing Firefox output logs and provides basic guidance on using filters ('Use filters to focus on specific content'), but it does not explicitly contrast with alternatives or state when not to use the tool. No strong when-to-use vs. when-not-to-use guidance is given beyond the implied purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false already indicates a mutating operation, so the description is not required to restate that. It does add the WebDriver BiDi command and source type support, but it does not disclose side effects such as the temporary-by-default nature of the install or requirements like signed extensions for permanent installs. These are partially covered in the schema, so the description adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the primary purpose and then list the supported input formats. There is no fluff or redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full parameter schema and no output schema, the description sufficiently conveys the operation and options. It could be more complete by mentioning that installs are temporary by default or noting the permanent install requirement, but these details are in the schema. Overall, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all four parameters, including an enum for type. The description simply reiterates the three source types without adding new semantic details. Therefore, it meets the baseline but does not go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (install) and resource (Firefox extension), mentions the underlying WebDriver BiDi command, and distinguishes itself from the sibling uninstall_extension. It also enumerates the three supported source types, leaving no ambiguity about its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear when to use the tool (to install an extension) and the accepted source formats, but it does not explicitly state when not to use it or mention alternatives. The sibling context provides implicit guidance, but no explicit exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It clearly discloses that all current tabs will be closed, which is a significant side effect. It also flags the requirement for MOZ_REMOTE_ALLOW_SYSTEM_ACCESS=1 when setting prefs. Since annotations only provide readOnlyHint=false, the description adds meaningful behavioral context, though it omits details about restart timing or 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences that are front-loaded with the core action. Each sentence contributes essential information: the action, the configurable aspects, and the key side effect. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a restart tool with six parameters and no output schema, the description covers the main purpose, the side effect, and a key operational requirement. However, it lacks details on whether the restart is synchronous/asynchronous, what the return value is, and how it affects the existing Firefox automation session. This leaves some ambiguity but is adequate for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the description does not need to explain each parameter. The text mentions 'binary path, environment variables, and other options,' but this merely echoes the schema. No additional meaning is added beyond the structured definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Restart Firefox with different configuration' and details specific configurable aspects like binary path and environment variables. This clearly distinguishes it from sibling tools which focus on page navigation, screenshots, or extension management, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for restarting Firefox with new settings but does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions. For example, it doesn't clarify that to change a single preference without restart, one might use other tools. This leaves the agent to infer from context rather than providing direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds the crucial behavioral detail that the output is base64 PNG. This complements the annotation by specifying the return format, which is beyond what the annotation provides. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence that fully conveys the tool's purpose and output format. There is no redundancy or unnecessary detail, making it highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-documented parameters and a read-only annotation, the description plus schema provide sufficient context. The return format (base64 PNG) is stated, and the saveTo behavior is explained in the parameter schema. Slight gap: the description does not define the exact response structure, but that's minor for a screenshot function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters (uid and saveTo), achieving 100% coverage. The outer description adds no additional parameter semantics, so it relies on the schema as expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Capture), the target (element screenshot by UID), and the output format (base64 PNG). It distinguishes from sibling screenshot_page by specifying 'element' and 'by UID', making the tool's unique scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for element-level screenshots, but it does not explicitly state when to prefer this over screenshot_page or other alternatives. There are no explicit exclusions or references to sibling tools, leaving usage context partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false already discloses that this is a mutating operation. The description adds no further behavioral context (e.g., side effects on screenshots or layout). It is a simple setter, so the lack of extra detail is acceptable, but no additional value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the tool's purpose. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two well-described parameters, no output schema, and a mutating annotation, the description is complete. It provides the essential information (action, target, unit) without unnecessary elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions ('Width in pixels', 'Height in pixels'), so the description adds no new semantic meaning. The description only states the purpose, and the schema already handles parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set viewport dimensions in pixels' uses a specific verb ('Set') and resource ('viewport dimensions'), with units specified. It clearly distinguishes from sibling tools by focusing on viewport sizing, which no other tool addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is clear: use when needing to adjust viewport size. No explicit exclusions or alternatives are mentioned, but there is no overlapping sibling tool, so the context is sufficient. Minor gap: no mention of whether this affects the current page or future navigations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the readOnlyHint annotation: downloads are 'tracked since startup' (not historical), and the output includes status and saved file path. Since annotations already establish read-only safety, the description needs only to add scope and output details, which it does effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence: 'List downloads tracked since startup, including status and saved file path.' No wasted words. Every part contributes essential information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must clarify return values; it does so by mentioning status and saved file path. It also defines scope ('since startup'). With four optional parameters already documented in the schema, this is adequately complete. A small gap is that ordering or pagination behavior is not mentioned, but this is minor for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters (limit, format, status, urlContains) are already fully documented. The description does not add additional semantic meaning about parameters; it only mentions output fields. Since the schema carries the parameter burden, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific and clear: 'List downloads tracked since startup, including status and saved file path.' It uses a strong verb ('list'), names the resource ('downloads'), and adds scope ('since startup') and key output details. This clearly distinguishes it from sibling tools like clear_downloads, which is a mutation, and navigate_page, which has a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it lists downloads, which is obviously the intended use. There are no explicit exclusions or alternatives, but there are no direct alternatives for listing downloads among the siblings. The context is clear enough for an agent to know when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint:false in annotations, the description adds important behavioral context: output is saved to downloads directory, the tool returns an ID for later use, and recordings can run concurrently. It also implies side effects (file creation) beyond the annotation. It lacks details like audio capture or cleanup, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each adding valuable information: action and output, return value and usage, concurrency capability. It is front-loaded with the primary purpose and has no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 optional parameters, no output schema, and minimal annotations, the description covers the essential workflow: start recording, save to downloads, get ID for stop. It doesn't explain return format or recording format, but those are implied by the schema and sibling stop tool. The description is complete enough for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters already have descriptions. The tool description adds context like 'current page viewport' which aligns with width/height defaults, but doesn't elaborate on individual parameters. For high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start recording a screencast (video)') and the resource ('current page viewport'), with output details ('saving to a file in the downloads directory'). It distinguishes itself from sibling tools like screenshot_page (still image) and screencast_stop (stop action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when a video recording of the viewport is needed) and provides workflow guidance: 'Returns a screencast id to pass to screencast_stop' and 'Multiple recordings can run at once.' It doesn't explicitly mention alternatives, but the 'video' keyword differentiates from screenshot tools well enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false already signals a mutation operation. The description adds that it finalizes the video file and returns the saved file path, providing useful behavioral context beyond the annotation and clarifying side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and followed by the return value. No redundant or extraneous information exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, the description covers purpose, return value, and relation to screencast_start. It lacks explicit error handling (e.g., no active recording), but the schema mitigates ambiguity, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a complete description of the single parameter, including its source from screencast_start and optionality. The tool description adds no new parameter details, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (stop) and resource (an in-progress screencast recording), and distinguishes it from siblings by referencing screencast_start and finalizing the video file. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It establishes clear context by naming screencast_start as the originating tool, indicating this is its termination counterpart. The parameter schema further clarifies when the optional id is needed. However, it doesn't explicitly mention alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the key behavior of selecting the active tab and the precedence rule for index. The annotation readOnlyHint=false already signals mutation, and the description adds valuable context about how criteria resolve conflicts, going beyond what the annotation provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that clearly conveys the purpose and a key rule. No superfluous words, front-loaded with the action and selection criteria.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple selection tool, the description covers the mechanism and the precedence rule. It does not mention return values or error cases, but given the absence of an output schema and the clarity of the function, this is sufficient for an agent to understand expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with concise descriptions (e.g., 'Tab index (0-based, most reliable)'), so the description adds little beyond the schema. The precedence rule is already implied by 'most reliable' in the schema, offering minimal additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool selects the active tab using three criteria (index, URL, or title). This distinguishes it from sibling tools like navigate_page or close_page, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that selection is by index, URL, or title, and explicitly states index takes precedence when multiple criteria are given. It does not explicitly mention alternatives or when not to use, but the context is unambiguous and the precedence rule offers practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds valuable behavioral information: snapshots have stable UIDs and must be retaken after navigation. This helps the agent understand the lifecycle of the data. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that convey the core purpose and a critical usage hint. Every word adds value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the number of optional parameters and the absence of an output schema, the description provides enough context for the tool's role in the workflow: it produces snapshots with UIDs for subsequent interaction. It could mention integration with sibling tools, but the current level is sufficient for an agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters are fully documented in the input schema with descriptions, achieving 100% schema coverage. The description itself does not add extra parameter information, which is acceptable given the schema's thoroughness, but it also doesn't enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a DOM snapshot and highlights the key feature of stable UIDs, which distinguishes it from sibling tools like screenshot_page. The verb 'Capture' accurately describes the action, and 'DOM snapshot' specifies the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Retake after navigation' provides clear context on when to use the tool, implying that snapshots become stale after navigation. However, it does not explicitly mention alternatives or when not to use it, so it doesn't earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, indicating a mutating operation. The description adds the requirement of a valid extension ID but does not disclose side effects (e.g., removal of extension data) or error behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the purpose and underlying command, the second provides a prerequisite. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description covers purpose and parameter provenance adequately. No output schema exists, but the description does not mention potential errors or return values, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the 'id' parameter with example. The description goes beyond schema by specifying how to retrieve the ID (from install_extension or list_extensions), which aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Uninstall' with the resource 'Firefox extension', clearly stating the action. It distinguishes from sibling tools like install_extension and list_extensions by its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence provides explicit guidance on how to obtain the required extension ID via install_extension or list_extensions. It doesn't explicitly state when not to use it, but the action is unique among siblings and the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral context by specifying that the selected tab is marked and listing the fields returned. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences immediately convey purpose and output details with no filler. Every phrase is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool, the description is complete: it says what is listed, which fields are included, and how the selected tab is distinguished. No output schema is needed for such a simple result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is trivially 100%. Baseline for zero-parameter tools is 4; the description doesn't need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List open tabs' with specific output fields (index, title, URL) and notes the selected-tab marker. This distinguishes it from sibling tools like navigate_page, close_page, and select_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is clear: use this tool when you need to view open tabs. It doesn't explicitly cite alternatives or exclusions, but the intended use is evident given the simple scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BAM-DevCrew/maxerviker-firefox-devtools-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server