Provides read-only market data and portfolio reconnaissance for Coinbase Advanced Trade by mirroring the browser tab's WebSocket frames via Chrome DevTools Protocol.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Chrome Course MCP Collect Brightspace course GAM_623 materials into my documents folder"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local, read-only Model Context Protocol (MCP) server that attaches — as a "ghost" — to an already-open, already-signed-in Coinbase Advanced Trade tab over the Chrome DevTools Protocol (CDP), and performs market-data and portfolio reconnaissance. It opens no socket of its own, holds no credentials, and places no orders. Pass 2 also adds an inert signal layer, PAPER P&L ledger, preview reconciliation, and a stubbed LIVE confirmation tool. Pass 3 adds transport diagnostics and explicit data provenance on every market event and derived value.
Forked from
chrome-course-mcp(a Brightspace page collector). The JSON-RPC stdio shell and theChromeSessionCDP client are reused as-is and extended.
The MCP never logs in, never sees your password/2FA, never touches the Coinbase
REST API, never copies cookies/JWTs out of Chrome, and never opens a second
WebSocket. It simply mirrors what your signed-in browser tab already
receives (Network.webSocketFrameReceived over CDP). That means:
No auth flow to break or leak.
No duplicate connection and no rate-limit risk — you see exactly what
the page sees. If Chrome does not expose WS frames for the current Coinbase
build, coinbase_market_stream marks domFallback:true and samples the
live-changing rendered order book instead; still no Coinbase API, SDK, or
socket is opened by this MCP. DOM fallback events are explicitly
source:"dom", hasSequence:false, confidence:"low", and degraded:true.
Fail-closed: if no Advanced Trade tab is open in the dedicated debug profile, every tool refuses to run rather than acting on an unrelated tab.
Related MCP server: superpowers-chrome
Node ≥ 20
Windows host with Google Chrome
A Coinbase account you can sign in to
Install deps:
npm installThe MCP only ever attaches to a dedicated Chrome profile launched with the DevTools port open — never your everyday profile.
# Launches Chrome on --remote-debugging-port=9222 with a dedicated profile
# (%LOCALAPPDATA%\CoinbaseMCPProfile) and opens Coinbase.
powershell -ExecutionPolicy Bypass -File scripts\launch-chrome-coinbase.ps1Open either https://www.coinbase.com/advanced-portfolio or
https://www.coinbase.com/advanced-trade/spot/BTC-USD.
Log in to Coinbase in this window once (complete any 2FA).
Close the window normally when you're done — the profile persists the session, so next launch you're usually still signed in.
Leave this window open while you use the MCP.
{
"mcpServers": {
"coinbase-mcp-ghost": {
"command": "node",
"args": ["./src/index.js"],
"cwd": "C:\\path\\to\\CoinBase-MCP-Ghost"
// or, if installed globally / linked:
// "command": "coinbase-mcp"
}
}
}This mirrors the old
chrome-course-mcpblock but with the new bin/path.
Generic Chrome primitives (kept): chrome_launch, chrome_open_tab,
chrome_tabs, chrome_navigate, chrome_snapshot, chrome_click,
chrome_type, chrome_select, chrome_press, chrome_screenshot,
chrome_eval, chrome_extract_media.
Coinbase recon/data tools (new, read-only):
Tool | What it does |
| Fail-closed attach to the Advanced Trade tab; returns |
| Passive WS/SSE/poll/WebTransport diagnostic. Attaches before same-tab navigation, checks page and worker targets, and writes a |
| One-shot deep recon → |
| Prefers sequenced WS frames when available. If unavailable, uses loud DOM fallback only, with degraded provenance and no sequence-gap claims. |
| Reads the in-memory ring buffer (counts, last tick/trade, recent N events). |
| Reads balances + open orders from the DOM (not an API). |
| Execution scaffold. |
| Reads the PAPER position/P&L ledger and advisory half-Kelly sizing output. |
| Stubbed third LIVE factor; records the phrase but never arms live submission. |
| Pure intended-order vs preview-shaped diff. No clicking, no DOM interaction. |
Config lives in config/default.json (env vars CMCP_* override):
{ "mode": "OBSERVE_ONLY", "symbol": "BTC-USD",
"debugUrl": "http://127.0.0.1:9222",
"tabUrlContains": ["coinbase.com/advanced-trade", "coinbase.com/advanced-portfolio"],
"maxNotionalUsd": 0, "killSwitch": true }Mode | Behavior |
| Read-only recon/data. |
|
|
| Not wired. Requires config flag + env var + |
The kill switch (killSwitch: true, default) is a manual circuit breaker
checked first on every order path. maxNotionalUsd: 0 means even simulated
fills above $0 are rejected until you deliberately raise it.
See EXECUTION_DESIGN.md for the full execution design and kill-switch flow,
and knowledge-base/ for the strategy rationale distilled from the
reference library.
npm run check # syntax-checks every source + test file
npm run smoke # offline core invariants always run;
# the live CDP suite runs automatically if a debug tab is upThe live smoke suite asserts: coinbase_attach → signedIn === true;
coinbase_market_stream 30s → live tick/L2/signal data and 0 gaps;
coinbase_portfolio_snapshot balances parse; coinbase_place_order (dryRun)
returns a structured response (+ a journal line in PAPER mode).
Pass 2 live recon is in recon/btc-usd-2026-06-10T20-48-37-731Z/. In that run,
CDP exposed no Coinbase WS frames, while the rendered BTC-USD order book changed
live; the network map records that explicitly.
Pass 3 transport diagnostic is in recon/btc-usd-2026-06-10T21-26-02-366Z/.
Verdict: WS TAP VIABLE: NO for this Chrome/Coinbase build. Early attach
before navigation captured no WebSocket, EventSource message, or WebTransport
frames on page or worker targets; it did observe Coinbase brokerage
REST/text/event-stream endpoints. Because those stream bodies are not exposed
as sequenced exchange frames through CDP here, downstream signals remain
degraded when sourced from DOM fallback.
No trading. No Place Order / Preview Order click anywhere.
No credentials / auth. No API keys, JWTs, HMAC, or cookie extraction.
No Coinbase SDK or REST client dependency.
No second WebSocket. We mirror the page's own feed.
Design references live in knowledge-base/: Harris for order-book
microstructure, Grinold-Kahn and Chan for IC/Kelly sizing, Lopez de Prado for
overfitting discipline, Kahneman for operator bias guardrails, and Kleppmann for
append-only stream handling.
Click an element by CSS selector or visible text. Useful for control panels and file-manager buttons.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| exact | No | ||
| tabId | No | ||
| waitMs | No | ||
| debugUrl | No | http://127.0.0.1:9222 | |
| selector | No | ||
| urlContains | No | ||
| titleContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It only says 'Click an element' but omits critical details: whether it waits for visibility, behavior on multiple matches, side effects (navigation, form submission), error handling, or tab selection logic. This is insufficient for safe and correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, and the primary action is front-loaded. However, it lacks structure: no parameter list, no usage examples, and the second sentence adds minimal value ('Useful for...'). Could use bullet points or parameter grouping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no schema descriptions, and no output schema, the description is highly incomplete. It only covers 2 parameters superficially. Missing details on tab selection, wait behavior, url/title filtering, and return value (if any) leave the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameter roles. It only mentions 'CSS selector' (selector) and 'visible text' (text), leaving 6 parameters (exact, tabId, waitMs, debugUrl, urlContains, titleContains) undefined. The agent cannot infer their purpose, especially tabId/filtering parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Click an element') and the two main targeting methods ('by CSS selector or visible text'). It distinguishes this from sibling tools like chrome_press (keyboard) and chrome_type (text input) by focusing on clicking, and provides a usage context ('control panels and file-manager buttons').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like chrome_press (keyboard actions) or chrome_select (selection from dropdowns). The description lacks when-not scenarios, prerequisites, or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate JavaScript in the selected tab. Use for small, explicit inspection or panel automation snippets.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | No | ||
| waitMs | No | ||
| debugUrl | No | http://127.0.0.1:9222 | |
| expression | Yes | ||
| urlContains | No | ||
| titleContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It fails to disclose behavioral traits such as destructive potential, permission requirements, or execution context (e.g., page scope), which is critical for a JavaScript evaluation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that prioritizes action and context. It is appropriately sized and front-loaded, though it could add more detail without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0% parameter coverage, the description should explain return values and parameters. It lacks essential information about what the tool returns (JavaScript result) and how to configure the 6 parameters, making it incomplete for complex use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 6 parameters. It does not explain tabId, waitMs, debugUrl, urlContains, or titleContains, leaving the agent without guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Evaluate JavaScript' and the resource 'in the selected tab', distinguishing it from siblings like navigation or clicking tools. It also specifies the tool's scope (small, explicit inspection or panel automation snippets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implicit usage guidance ('small, explicit inspection or panel automation snippets'), but does not explicitly state when not to use or provide alternatives, relying on sibling tool names for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract media, document, iframe, and link candidates from a selected Chrome tab.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | No | ||
| debugUrl | No | http://127.0.0.1:9222 | |
| urlContains | No | ||
| titleContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'extract', implying a non-destructive read operation, but fails to mention that a debug URL is required, potential permissions, or what 'candidates' implies. The description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main action and resource. However, it is too brief to cover necessary details, which is a trade-off that reduces effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% schema coverage, no output schema, and no annotations, the description is severely incomplete. It does not clarify the return value, filtering options, or the role of debugUrl, leaving the agent with insufficient information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (tabId, debugUrl, urlContains, titleContains). It offers no additional meaning beyond the schema's bare structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Extract' and the resource 'media, document, iframe, and link candidates from a selected Chrome tab.' It distinguishes the tool from siblings like chrome_screenshot or chrome_snapshot, which have different focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Given sibling tools exist, the lack of usage context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch a Chrome window with the DevTools Protocol enabled, or open a new tab if it is already running.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | about:blank | |
| waitMs | No | ||
| debugUrl | No | http://127.0.0.1:9222 | |
| extraArgs | No | ||
| chromePath | No | ||
| userDataDir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that DevTools Protocol is enabled and that it can open a new tab, but omits key behaviors: what happens to existing Chrome instances, side effects (e.g., leftover processes), permission requirements, or response format. Incomplete for a launch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, well front-loaded, but under-specifies. It sacrifices necessary detail for brevity, making it suboptimal for an agent to invoke correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (browser launch with DevTools, 6 parameters, no output schema), the description is severely incomplete. It lacks return value details, error handling, parameter explanations, and any behavioral nuance beyond the basic action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no parameter information. All six parameters (url, waitMs, debugUrl, extraArgs, chromePath, userDataDir) are completely undocumented, leaving the agent blind to their meanings and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool launches a Chrome window with DevTools enabled or opens a new tab if already running. This provides a specific verb and resource, and hints at dual behavior, which distinguishes it from siblings like chrome_navigate, though not fully from chrome_open_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (launch new vs open tab) but gives no explicit guidance on when not to use or alternatives. Among siblings like chrome_open_tab, there is no differentiation advice, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a new tab through an existing Chrome DevTools Protocol endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | about:blank | |
| debugUrl | No | http://127.0.0.1:9222 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full transparency burden. It states the tool uses an existing endpoint but doesn't disclose failure conditions (e.g., if debugUrl is unreachable), what happens if the endpoint is invalid, or whether the tool returns the tab ID for subsequent operations. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (one sentence), but conciseness is not a virtue when it sacrifices key information. The sentence is front-loaded and clear, but could be expanded to include parameter guidance and usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0% parameter coverage, the description fails to provide essential completeness. The agent needs to know what the tool returns (e.g., tab ID) to chain with other tools like chrome_navigate. The description omits all context necessary for effective use in a multi-tool workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description does not explain any parameters. The schema includes url (default about:blank) and debugUrl (default http://127.0.0.1:9222), but the description omits all parameter details. The agent cannot infer the meaning or expected format of these inputs from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it opens a new tab using an existing Chrome DevTools Protocol endpoint. The verb 'Open' and resource 'new tab' are specific and distinct from sibling tools like chrome_navigate (navigate existing tab) and chrome_tabs (list tabs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Doesn't mention that the endpoint must already be running (e.g., from chrome_launch) or that chrome_open_tab is for creating a new tab while chrome_navigate is for navigating an existing one. The agent receives no contextual hints for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a keyboard key to the selected page, optionally after focusing an element.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| tabId | No | ||
| waitMs | No | ||
| debugUrl | No | http://127.0.0.1:9222 | |
| selector | No | ||
| urlContains | No | ||
| titleContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions optional element focusing but fails to explain side effects (e.g., does it simulate keydown/keyup?), prerequisites (e.g., requiring a selected page), or the meaning of parameters like tabId, debugUrl, waitMs, urlContains, and titleContains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise and front-loaded with the main action. However, it is under-specified for a tool with 7 parameters; a more structured approach (e.g., bullet points) could improve clarity without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description is incomplete. It does not explain return values, error conditions, or how to configure target selection via urlContains/titleContains. The complexity of the tool demands more comprehensive documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only hints at 'key' and 'selector' via 'focusing an element', but does not describe tabId, waitMs, debugUrl, urlContains, or titleContains. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: sending a keyboard key to the selected page, with optional element focusing. It distinguishes from sibling tools like chrome_type (which types strings) and chrome_click (mouse clicks) by specifying 'keyboard key'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (sending a single key press) but provides no explicit guidance on when not to use it or alternatives. For example, it does not contrast with chrome_type for text input or chrome_click for keyboard-based clicks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a PNG screenshot of the selected page.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | No | ||
| debugUrl | No | http://127.0.0.1:9222 | |
| fullPage | No | ||
| outputPath | Yes | ||
| urlContains | No | ||
| titleContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full behavioral burden. It only states it captures a screenshot, without disclosing side effects, storage implications (outputPath required), or how it selects the page (tab selection via tabId/urlContains/titleContains). This is insufficient for a tool with multiple parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (8 words), but this brevity sacrifices essential information. It is under-specified rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no output schema, no annotations), the description is far too incomplete. It provides no information about return values, parameter roles, or configuration options, making it difficult for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter beyond the schema. The agent must infer meanings of parameters like tabId, debugUrl, fullPage, outputPath, urlContains, titleContains from their names alone, which may be ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('capture a PNG screenshot') and the resource ('selected page'). It is specific but does not explicitly differentiate from the sibling tool 'chrome_snapshot', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'chrome_snapshot' or other browser tools. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a select dropdown by CSS selector or label text, matching option value or visible text.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | ||
| tabId | No | ||
| value | Yes | ||
| waitMs | No | ||
| debugUrl | No | http://127.0.0.1:9222 | |
| selector | No | ||
| urlContains | No | ||
| titleContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states what the tool does without disclosing behavioral traits such as waiting behavior, error handling, or what happens on element not found. The `waitMs` parameter is not explained, and there is no mention of side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and method. It is concise with no redundancy, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema or annotations, the description leaves many details uncovered. It does not explain the return value, error behavior, or how parameters like tabId or urlContains affect execution. The description is insufficient for complete agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to three parameters (selector, label, value) by explaining that the selector or label identifies the dropdown and value matches option text or value. However, five parameters (tabId, waitMs, debugUrl, urlContains, titleContains) are unaddressed, and with 0% schema description coverage, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set a select dropdown') and the method ('by CSS selector or label text, matching option value or visible text'), distinguishing it from sibling tools like chrome_click or chrome_type which handle different UI interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The purpose is clear, but there is no mention of prerequisites, limitations, or when not to use it, which leaves some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize the selected page with visible text, links, buttons, inputs, selects, and forms for automation planning.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | No | ||
| debugUrl | No | http://127.0.0.1:9222 | |
| maxElements | No | ||
| urlContains | No | ||
| maxTextLength | No | ||
| titleContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states what elements are summarized but does not disclose side effects, required permissions, or whether the operation is read-only. The lack of behavioral context beyond the extraction list is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the verb and resource. However, it could be slightly restructured for clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 undocumented parameters and no output schema, the description should explain expected output format and parameter usage. It only lists extracted elements, leaving the agent without enough context to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 6 parameters with 0% description coverage in the schema, and the tool description does not mention any parameter. The agent receives no guidance on what tabId, debugUrl, maxElements, etc., control. This is a critical deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'summarize' and the resource 'selected page' with specific elements (text, links, buttons, etc.). It distinguishes from siblings like chrome_screenshot or chrome_click, though it doesn't explicitly contrast them. Overall, purpose is clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for automation planning' implies when to use the tool, but there is no explicit guidance on when not to use it or mention of alternative tools. Usage context is implied but not fully developed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Chrome tabs exposed by the local Chrome DevTools Protocol endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| debugUrl | No | http://127.0.0.1:9222 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states a read operation (listing tabs) but does not describe side effects, the format of returned data, or any requirements (e.g., authentication, running debug endpoint).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the key action and subject. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having only one optional parameter and no output schema, the description lacks essential context: return format, error conditions, and prerequisites (Chrome DevTools endpoint must be active). This makes it incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'debugUrl' parameter or its default value. The agent must rely entirely on the parameter name, which is insufficient for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'Chrome tabs', and specifies the source as 'local Chrome DevTools Protocol endpoint', which helps distinguish it from sibling tools like chrome_open_tab or chrome_navigate. However, it does not explicitly differentiate against other listing tools like chrome_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., Chrome must be running with remote debugging), expected use cases, or 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.
Type into an input or textarea by CSS selector, label text, placeholder, name, id, or aria-label.
| Name | Required | Description | Default |
|---|---|---|---|
| clear | No | ||
| label | No | ||
| tabId | No | ||
| value | Yes | ||
| submit | No | ||
| waitMs | No | ||
| debugUrl | No | http://127.0.0.1:9222 | |
| selector | No | ||
| urlContains | No | ||
| titleContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention important behaviors such as clearing the field (clear parameter), submitting a form (submit parameter), waiting after typing (waitMs parameter), or handling tab selection (tabId parameter). The tool's interaction with other parameters like debugUrl is also omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence but front-loads the action and target. However, given the tool's complexity (10 parameters), it is too brief and lacks structure. A more detailed breakdown would improve usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, no schema descriptions, no annotations, and no output schema. The description only covers the basic function and ignores return values, side effects, dependencies (e.g., on tabs), and error cases. It is highly insufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It hints at selector and label parameters by listing identification methods, but it does not explain other parameters like clear, submit, waitMs, tabId, debugUrl, urlContains, or titleContains. Many parameters remain opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (type) and target (input or textarea), along with various element identification methods. However, it does not differentiate from sibling tools like chrome_press or chrome_click, which could be used for similar interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for filling text fields but provides no explicit guidance on when to use this tool versus alternatives (e.g., chrome_select for dropdowns, chrome_press for keyboard shortcuts). No prerequisites or conditional usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach (fail-closed) to an already-open, already-signed-in Coinbase Advanced Trade tab in the debug profile. Returns { attached, signedIn, tab, probeResults }. Never falls back to an unrelated tab.
| Name | Required | Description | Default |
|---|---|---|---|
| debugUrl | No | http://127.0.0.1:9222 | |
| urlContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on full responsibility for behavioral transparency. It discloses the return value shape and the 'fail-closed' behavior, indicating failure conditions. It does not contradict any implied behavior, and it adds useful context beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences. It front-loads the core action and return format, and every word serves a purpose. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no output schema, and no annotations, the description covers the basic purpose and return value but lacks explanation of parameter semantics and explicit failure scenarios. It is minimally adequate but leaves gaps for an agent to infer details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it does not explain the purpose or usage of either 'debugUrl' or 'urlContains'. Default values are provided but without context, the agent cannot easily understand how to set these parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('attach'), the resource ('already-open, already-signed-in Coinbase Advanced Trade tab'), and the behavior ('fail-closed'). It distinguishes this tool from siblings by specifying the exclusive context of an existing tab, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (attaching to an existing tab) and implies not to use it for opening new tabs. The phrase 'Never falls back to an unrelated tab' sets a boundary, but it does not explicitly mention prerequisites or alternatives, which would strengthen it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stubbed LIVE ladder third factor. Records an explicit confirmation phrase for audit but never arms or submits live orders.
| Name | Required | Description | Default |
|---|---|---|---|
| phrase | No | Must be CONFIRM_LIVE_STUB_ONLY to be accepted by the stub; still cannot arm LIVE. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses the stub behavior: it records confirmation for audit and never arms or submits live orders, providing complete transparency about its limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste, front-loaded with the key term 'Stubbed' and clear action verbs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple stub with one parameter, but it omits any indication of return value or success/error behavior, which could be useful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds critical constraint beyond the schema: phrase must be 'CONFIRM_LIVE_STUB_ONLY' and explains the stub's acceptance behavior, fully compensating for any lack of enum or format specification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a stub that records a confirmation phrase for audit but never arms or submits live orders, effectively distinguishing it from real order tools like coinbase_place_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage only for audit recording when a stub confirmation is needed, but does not explicitly state when not to use or list alternatives. Context from sibling tools suggests real orders go elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Passive transport diagnostic for Coinbase real-time data. Attaches before same-tab navigation, observes WS/SSE/poll/WebTransport on page and worker targets, writes a recon network-map + WS TAP VIABLE verdict. Never clicks or opens a Coinbase socket.
| Name | Required | Description | Default |
|---|---|---|---|
| debugUrl | No | http://127.0.0.1:9222 | |
| durationMs | No | ||
| outputRoot | No | ||
| urlContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are present, the description carries full responsibility for behavioral disclosure. It clearly states the tool is passive, attaches before navigation, observes multiple transport types, and writes a verdict. The explicit claim 'Never clicks or opens a Coinbase socket' adds safety assurance. However, it omits details about side effects like file creation or network activity, preventing a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the core purpose. It avoids unnecessary words. However, it could benefit from a brief list of parameters or a more structured format to improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (observing multiple transports, writing output) and no output schema, the description fails to explain the format of the verdict or network map, the tool's lifecycle (e.g., how duration works), or how the output is stored (outputRoot parameter). This leaves significant ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about the four parameters (debugUrl, durationMs, outputRoot, urlContains). The agent receives no guidance on parameter formats, defaults, or how they affect behavior, making it difficult to invoke correctly. This is a critical gap given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Passive transport diagnostic for Coinbase real-time data' and specifies the actions: attaches before navigation, observes transports, writes a verdict. It also explicitly distinguishes itself from interactive tools by stating 'Never clicks or opens a Coinbase socket', making its purpose highly specific and differentiated from siblings like chrome_click or coinbase_place_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for passive diagnostic scenarios but does not explicitly state when to use it over alternatives like coinbase_market_stream or coinbase_confirm_live. No exclusions or comparative guidance are provided, leaving the agent to infer usage context from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mirror the page's own Coinbase WebSocket frames over CDP for durationMs, normalize into Tick/L2Update/Trade/Candle (decimal.js), fan out to an in-memory ring buffer + append-only JSONL journal, and detect sequence gaps. Read-only; opens no socket of its own.
| Name | Required | Description | Default |
|---|---|---|---|
| debugUrl | No | http://127.0.0.1:9222 | |
| durationMs | No | ||
| urlContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: mirroring CDP frames, normalization types, fan-out mechanisms, sequence gap detection, and read-only nature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and dense with information. Every phrase adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits what the tool returns to the caller (e.g., whether it returns a stream handle, success status, or nothing). Given no output schema, the description should clarify the invocation result. Error cases are also not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds value by implying 'durationMs' and the URL context. It doesn't explicitly describe debugUrl or urlContains, but a knowledgeable user can infer their roles. The description compensates partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources: 'mirror... Coinbase WebSocket frames', 'normalize into Tick/L2Update/Trade/Candle', 'fan out to ring buffer + JSONL journal', and 'detect sequence gaps'. It clearly distinguishes from sibling tools like coinbase_place_order and portfolio snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to capture and process Coinbase market data via CDP mirroring. It states 'Read-only; opens no socket of its own', giving context. However, it lacks explicit when-to-use and when-not-to-use guidance compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the in-memory PAPER trading ledger: running position, realized/unrealized P&L, recent simulated fills, and advisory half-Kelly sizing from measured PAPER outcomes. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly declares 'Read-only' and enumerates returned data. Without annotations, this provides good behavioral context, though it could mention any required state (e.g., paper trading active).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence concisely lists contents and states read-only nature. No wasted words, front-loaded with action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers key return data and read-only nature. Lacks mention of prerequisites (e.g., paper mode must be running), but overall adequate for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description does not need to elaborate. Baseline score of 4 is appropriate for zero-parameter tool with full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it reads the in-memory PAPER trading ledger and lists specific data: position, P&L, fills, half-Kelly sizing. It differentiates from sibling tools like coinbase_place_order (write) and coinbase_portfolio_snapshot (live).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for paper trading status but offers no explicit guidance on when to use versus alternatives (e.g., coinbase_portfolio_snapshot). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EXECUTION SCAFFOLD (dryRun hardcoded true). Validates a would-be order against config risk limits (mode/killSwitch/maxNotionalUsd). OBSERVE_ONLY rejects all; PAPER logs a simulated fill at best bid/ask. NEVER clicks the order form. No real order is ever placed in this pass.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | ||
| type | Yes | ||
| dryRun | No | ||
| baseSize | No | ||
| quoteSize | No | ||
| limitPrice | No | ||
| timeInForce | No | GTC | |
| clientOrderId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden and fully discloses behavioral traits: dryRun is hardcoded true, validates against risk limits, observe-only rejects, paper mode logs simulated fill, and never clicks the order form. No hidden behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no redundant sentences. However, it could be structured more clearly by separating the core purpose from behavioral details. Currently it reads as a block of text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, parameter coverage, and the complexity of the tool (8 parameters, risk validation), the description is complete for behavioral understanding but leaves a significant gap in parameter semantics, which is critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter's meaning or usage beyond what the schema provides. It omits details on parameters like side, type, baseSize, etc., leaving the agent to infer from schema types and enums alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a dry-run scaffold that validates orders against risk limits without ever placing a real order. It distinguishes itself from sibling tools like coinbase_confirm_live and coinbase_paper_ledger by emphasizing it never executes real trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: it is for validating would-be orders in a dry run mode and never places real orders. It implies that for actual order placement, alternative tools should be used, but does not name them explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read balances + open orders directly from the Advanced Trade DOM (never from an API), using the discovered selectors with a stability-ranked fallback chain. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| debugUrl | No | http://127.0.0.1:9222 | |
| urlContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'read-only' and a 'stability-ranked fallback chain' but does not detail failure modes, required permissions, or the implications of the fallback chain. Partial transparency but missing critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences and front-loaded with the primary action. However, the term 'stability-ranked fallback chain' is jargon that could be simplified without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal annotations, the description should provide a complete picture. It lacks details on the output format, scope of data (e.g., all accounts?), and behavior of the fallback chain. Incomplete for an agent to reliably invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description adds no explanation for the two parameters (debugUrl, urlContains). The agent must rely on parameter names and defaults, which is insufficient for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the specific resource ('balances + open orders') from a defined source ('Advanced Trade DOM'). It distinguishes itself from API-based tools by emphasizing 'never from an API', 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for real-time DOM data but does not explicitly specify when to use this tool over siblings like coinbase_market_stream or coinbase_paper_ledger. No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot deep reconnaissance of the live Advanced Trade page. Writes ./recon/-/ (dom-map.json, network-map.json, behavioral.json, screenshots/, RECON_REPORT.md). Read-only; never submits an order.
| Name | Required | Description | Default |
|---|---|---|---|
| debugUrl | No | http://127.0.0.1:9222 | |
| outputRoot | No | ||
| urlContains | No | ||
| sampleSeconds | No | ||
| networkSeconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly states the tool is read-only and creates local files (dom-map, network-map, behavioral.json, etc.), which is key behavioral context. It lacks some details like network usage or auth requirements, but the core safety profile is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficient sentences. The first sentence states the primary purpose, and the second details outputs and behavior (read-only). Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits crucial context about parameters, making it difficult for an agent to invoke correctly without additional knowledge. It also lacks guidance on when to use this tool versus sibling reconnaissance tools like coinbase_snapshot_state. The output files are listed but no return value schema is provided, and the tool's purpose (deep reconnaissance) is clear but not fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters have no descriptions in the schema. The tool description does not explain any of the five parameters (debugUrl, outputRoot, urlContains, sampleSeconds, networkSeconds), leaving the agent to infer meaning from names alone. This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs deep reconnaissance of the live Advanced Trade page and specifies the output files. It distinguishes itself from sibling tools like coinbase_place_order and coinbase_portfolio_snapshot by emphasizing its read-only investigative nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is a 'one-shot' reconnaissance and 'never submits orders', implying use before trading. However, it does not explicitly state when to use this tool versus alternatives like coinbase_snapshot_state or coinbase_attach, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pure preview-vs-intent diff for future safety checks. Accepts intended order fields and a preview-shaped object; performs no clicking or DOM interaction.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | ||
| preview | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is read-only and performs no DOM interaction, which is a key behavioral trait. However, it does not describe what the diff returns (e.g., fields that differ, errors) or any edge-case behavior, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 20 words split into two focused sentences. The first sentence states the core purpose, and the second clarifies inputs and constraints. Every word adds value, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, no annotations, and complex nested object parameters, the description is too brief. It does not explain the return value (e.g., what the diff looks like), error cases, or how to interpret results. The agent lacks sufficient information to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two object parameters with 0% description coverage, so the description must compensate. It provides minimal additional meaning by labeling 'intent' as 'intended order fields' and 'preview' as 'preview-shaped object', but does not explain their structure or required fields. This is insufficient for an agent to construct valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'preview-vs-intent diff' for safety checks, and explicitly distinguishes itself from sibling tools by stating it performs no clicking or DOM interaction. The verb 'diff' combined with the input specification makes the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('for future safety checks') and what it does not do ('no clicking or DOM interaction'), implying it should be used before action-oriented tools. However, it does not explicitly mention when not to use it or name specific alternatives, which would elevate the score to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current in-memory ring-buffer state collected by coinbase_market_stream (counts, last tick/trade, recent N events).
| Name | Required | Description | Default |
|---|---|---|---|
| n | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the nature of the data (in-memory ring-buffer state) and includes counts, last tick/trade, and recent events, implying a read-only operation. However, it does not clarify side effects, whether the stream must be active, or the behavior when the buffer is empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 20 words, front-loaded with the key purpose. Every word earns its place, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers what it does and the key parameter shape. It mentions the nature of the return data (counts, last tick/trade, recent events). However, it lacks context about dependencies (e.g., needing an active stream) and the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'n' with no description (0% coverage). The description clarifies that 'n' controls the count of recent events, adding meaning beyond the raw schema. This is sufficient for a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Return'), the resource ('in-memory ring-buffer state'), and the context ('collected by coinbase_market_stream'). It specifies what is included (counts, last tick/trade, recent N events), which distinguishes it from sibling tools like coinbase_market_stream (which likely starts the stream) and coinbase_portfolio_snapshot (portfolio data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like coinbase_market_stream or coinbase_portfolio_snapshot. There is no mention of prerequisites (e.g., requiring the stream to be active) or 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0chrome_clickchrome_evalchrome_extract_mediachrome_launchchrome_navigatechrome_open_tabchrome_presschrome_screenshotchrome_selectchrome_snapshotchrome_tabschrome_typecoinbase_attachcoinbase_confirm_livecoinbase_diagnose_transportcoinbase_market_streamcoinbase_paper_ledgercoinbase_place_ordercoinbase_portfolio_snapshotcoinbase_reconcoinbase_reconcile_preview_intentcoinbase_snapshot_stateEach tool has a clearly distinct purpose within its domain (Chrome automation or Coinbase trading). There is no overlap; descriptions clearly differentiate similar actions like 'chrome_click' and 'chrome_select' or 'coinbase_recon' and 'coinbase_attach'.
All tools follow a consistent prefix_naming convention: 'chrome_verb' for Chrome tools and 'coinbase_verb_noun' for Coinbase tools. The use of snake_case is uniform, and the pattern is predictable across the entire set.
22 tools is on the higher side but still reasonable given the combination of two distinct domains (Chrome automation and Coinbase trading). Each tool serves a specific purpose, though some users might find the Coinbase tools excessive for a 'Chrome Course' server.
The Chrome automation tools cover essential actions (navigation, clicking, typing, JS evaluation, screenshots, tabs), though a few common operations like scrolling are missing. The Coinbase tools provide extensive coverage for trading research (market streaming, portfolio reading, dry-run orders, diagnostics), making the overall surface fairly complete for its intended use.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Automate cloud Chrome—navigate, click, type, screenshot, run code, record screen video
Automate cloud browsers to navigate websites, interact with elements, and extract structured data.…
Hosted real Google Chrome MCP with per-user persistent state. Navigate, click, type, screenshot.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CrispyW0nton/CoinBase-MCP-Ghost'
If you have feedback or need assistance with the MCP directory API, please join our Discord server