crx-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| extension_loadB | Load a Chrome extension and launch the browser. Returns extension ID. |
| navigateA | Navigate to a URL in the browser. |
| snapshotA | Get an accessibility snapshot of the page, popup, or side panel. |
| storage_getB | Read from chrome.storage (local/sync/session). |
| storage_setA | Write to chrome.storage (local/sync/session). |
| eval_service_workerA | Execute JavaScript in the extension Service Worker context. |
| console_logsA | Get console logs from all extension contexts (page, SW, popup, sidepanel). |
| clickB | Click an element by CSS selector. |
| typeB | Type text into an input element by CSS selector. |
| wait_forB | Wait for an element to appear, disappear, or change visibility. |
| manifest_validateA | Validate manifest.json against MV3 requirements (no browser needed). |
| open_popupA | Open the extension popup in a new tab and return accessibility snapshot. |
| open_sidepanelA | Open the extension side panel in a new tab and return accessibility snapshot. |
| dnr_rulesB | List declarativeNetRequest rules (dynamic/session/static). |
| permissions_checkA | Check declared vs granted extension permissions. |
| dnr_matched_rulesA | Get declarativeNetRequest matched rules (which rules fired). Requires declarativeNetRequestFeedback permission. |
| extension_errorsA | Get extension errors from chrome://extensions and recent SW crash logs. |
| send_messageB | Send a message via chrome.runtime.sendMessage() and capture the response. |
| eval_extension_pageA | Execute JavaScript in an extension popup or side panel page context (has access to chrome.* APIs). |
| screenshotA | Take a screenshot of the page, popup, or side panel. Returns base64 PNG. |
| network_requestsB | List captured network requests with optional URL filter. |
| content_script_evalB | Execute JavaScript in the page context (ISOLATED or MAIN world). |
| reload_extensionA | Reload the extension and re-attach to the Service Worker. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 23 tools
Each tool targets a distinct context or action: eval tools are separated by target (extension page, content script, service worker), while screenshot/snapshot differ between visual and accessibility representation. The descriptions clearly delineate the boundaries, so misselection is unlikely.
Tool names mix verb-first patterns (eval_extension_page, open_popup, send_message) with noun-first patterns (manifest_validate, storage_get, dnr_rules), and some use bare verbs (click, type, wait_for). This inconsistency is readable but not predictable, placing it at the mixed-conventions level.
With 23 tools, the server is on the heavier side, fitting the borderline 16-25 range. While each tool has a legitimate purpose in the extension-testing domain, the count feels heavy and could potentially be consolidated (e.g., merging DNR-related tools or grouping eval functions).
The tool surface covers the full lifecycle: loading and reloading the extension, evaluating in all contexts, storage, messaging, DNR, permissions, and UI automation. Minor gaps include no dedicated options-page automation or explicit permission manipulation, but agents can work around these via context eval and manifest validation.