Skip to main content
Glama
Sign In
chromaphore-mcp

chromaphore-mcp

Official
by nodriver-project
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Read a URL

fetch
Read-only

Retrieves a URL through the browser using its cookies and fingerprint, returning rendered HTML as Markdown or other content as text; also performs API calls and reports bot blocks.

Instructions

Reads a URL through the browser, with its cookies, fingerprint and network, in a hidden page that never becomes a tab: HTML is rendered and returned as Markdown, anything else as text. A method, headers or a body make it an API call from a page of the URL's origin. Says when a bot challenge or a block got in the way. Needs an open browser (headless is fine).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "fetch"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes
bodyNo
modeNoraw: the response as it is, even HTML.
linksNoAlso list every link on the page.
methodNo
headersNo
max_charsNoHow much of the text to return (default 40,000); the rest is saved to a file.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

The only annotation is readOnlyHint=true, so the description carries most of the behavioral burden and does well: it discloses the hidden-page rendering model, the Markdown-vs-text conversion rule, the origin-scoped API-call behavior, and that bot challenges or blocks are reported rather than silently failing. It does not say what happens on non-2xx responses or where truncated overflow is written, leaving a small gap.

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

Conciseness4/5

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

Front-loaded with the core action and packed with useful detail in a few clauses, with no filler sentences. The colon-and-enumeration structure gets dense in the middle (rendering, API-call mode, block reporting) but remains readable and every clause carries information.

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

Completeness4/5

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

For a 7-parameter tool with a nested object and no output schema, the description covers what an agent most needs: return format, prerequisites, and failure signaling. The remaining gaps (location of the overflow file referenced by max_chars, response handling on non-success statuses) are minor but real.

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

Parameters4/5

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

Schema coverage is only 43% (url, method, headers and body are undocumented in the schema), but the description compensates by explaining that method/headers/body together turn the call into an API request issued from a page of the URL's origin, and by tying the auto/raw mode choice to the Markdown-vs-text rule. It still adds nothing about header encoding or body content type, so it does not fully close the coverage gap.

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

Purpose5/5

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

The definition opens with a specific verb and resource ('Reads a URL through the browser') and immediately scopes it: a hidden page that never becomes a tab, HTML rendered to Markdown, everything else as text. That hidden-page framing implicitly separates it from navigate/tab_* siblings that change visible browser state, so an agent can tell which tool to reach for.

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

Usage Guidelines4/5

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

It gives clear selection context: use it to read content without occupying a tab, use it for API calls when method/headers/body are supplied, and it requires an already-open browser (headless acceptable). It stops short of naming an alternative tool or stating explicit exclusions, so no 5.

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

Deploy Server

Other Tools