de en es ja ko ru zh

obscura-mcp

Name: obscura-mcp
Author: Metadrama

Official

by Metadrama

Overview Schema Related Servers Score Discussions

JavaScript

Local

obscura-mcp — ARCHIVED

⚠️ Archived. Upstream ships native MCP since v0.1.4 (obscura mcp). npm package deprecated.

npm version License: MIT

An MCP server adapter for Obscura, a lightweight Rust headless browser for scraping and AI agent automation.

Exposes Obscura's native CDP capabilities through a clean MCP interface — no Chrome dependency, no heavyweight browser automation.

Installation

npm install -g obscura-mcp

The npm package itself is a small Node.js wrapper (~20 KB). The browser binary (~80 MB) is downloaded automatically on first use — no separate install step needed.

The binary is cached at ~/.obscura/bin/ and survives npm upgrades.

Pre-release builds are published under the dev tag:

npm install -g obscura-mcp@dev

To use a custom binary path:

export OBSCURA_PATH=/path/to/obscura

Related MCP server: Algonius Browser

Quick Start

# Install
npm install -g obscura-mcp

# Verify
obscura-mcp --version

# Start MCP server (stdio — primary transport)
obscura-mcp --transport stdio

# Or with HTTP transport
obscura-mcp --transport streamable-http

Most MCP clients (Claude Desktop, Cline, Continue) connect via stdio. The streamable-http transport is also supported for custom integrations.

Tools

Four tools cover browsing, interacting, session persistence, and bulk scraping.

`browse_page` — one-shot page reading

Get content from any page in a single call. Combine output format with optional JavaScript evaluation.

Parameter	Type	Default	Description
`url`	`string`	—	The URL to visit
`format`	`"text"` \| `"markdown"` \| `"html"` \| `"links"` \| `"cookies"` \| `"axtree"` \| `"layout"`	`"text"`	Output format
`eval`	`string`	—	JavaScript expression to evaluate (appended to output)
`cookies`	`array`	—	Cookies to inject `[{name, value, domain?, path?, ...}]`
`user_agent`	`string`	—	Override the browser user-agent string
`headers`	`object`	—	Extra HTTP headers `{key: value, ...}`
`stealth`	`boolean`	`true`	Accepted for compatibility; stealth is controlled by the Obscura server

Examples:

browse_page(url: "https://example.com")
browse_page(url: "https://example.com", format: "markdown")
browse_page(url: "https://example.com", format: "axtree")
browse_page(url: "https://example.com", format: "layout")
browse_page(url: "https://example.com", user_agent: "TestBot/1.0")

`format`	What you get
`"text"`	Plain text — stripped of HTML tags, scripts, styles
`"markdown"`	Clean markdown — uses Obscura's native LP.getMarkdown CDP
`"html"`	Raw HTML markup
`"links"`	All href values — one per line
`"cookies"`	Cookies with name, value, domain, path, expiry
`"axtree"`	Accessibility tree — roles, names, values of all elements
`"layout"`	Viewport metrics — dimensions, scroll offsets, device scale

When eval is provided, the JavaScript result is appended to the format output under a --- eval --- divider.

`browse_interact` — one-shot page actions

Click an element or type text into a page. For multi-step interactions (login → wait → extract), use browse_session instead.

Parameter	Type	Default	Description
`url`	`string`	—	The URL to visit
`action`	`"click"` \| `"type"`	—	Action to perform
`selector`	`string`	—	CSS selector for the target element
`text`	`string`	—	Text to type (required when `action` is `"type"`)
`cookies`	`array`	—	Cookies to inject `[{name, value, ...}]`
`stealth`	`boolean`	`true`	Accepted for compatibility; stealth is controlled by the Obscura server

Examples:

browse_interact(url: "https://example.com", action: "click", selector: "a")
browse_interact(url: "https://duckduckgo.com", action: "type", selector: "input[name=q]", text: "search query")

Both actions create a fresh page, perform the action, and close. The page context does not persist — for sequential interactions (type into a form, then click submit), use browse_session instead.

`browse_session` — multi-step persistent sessions

Create a persistent browser session, interact with it across multiple calls, then close. Sessions auto-close after 5 minutes of inactivity. Multiple sessions can run simultaneously.

Parameter	Type	Required for	Description
`action`	`"create"` \| `"close"` \| `"list"` \| `"goto"` \| `"wait"` \| `"extract"` \| `"click"` \| `"type"`	All	What to do
`session_id`	`string`	All except `create`, `list`	Session ID from `create`
`url`	`string`	`create`, `goto`	URL to navigate to
`selector`	`string`	`wait`, `click`, `type`	CSS selector
`expression`	`string`	`wait` (if no selector), `extract`	JavaScript expression
`text`	`string`	`type`	Text to type
`timeout`	`number`	`wait` (optional)	Max wait in ms (default 30000, max 120000)
`user_agent`	`string`	`create`, `goto`	Override user-agent string for navigation
`headers`	`object`	`create`, `goto`	Extra HTTP headers `{key: value, ...}`
`clear_cookies`	`boolean`	`create`	Clear all browser cookies on session creation

Session lifecycle:

`action`	What it does	Returns
`create`	Opens a new browser tab. Optionally clears cookies.	Session ID
`close`	Releases the tab and all its resources. Idempotent.	Confirmation
`list`	Shows all active sessions with timestamps.	Session list
`goto`	Navigates to a new URL. Page stays alive.	Confirmation
`wait`	Polls until a CSS selector exists or a JS expression returns true.	Confirmation
`extract`	Evaluates JavaScript and returns the result.	Eval result
`click`	Clicks an element by CSS selector.	Coordinates
`type`	Types text into an input field.	Confirmation

Login flow example:

browse_session(action: "create", url: "https://example.com/login")
  → "Created session: session_1"

browse_session(action: "type", session_id: "session_1", selector: "#username", text: "user")
browse_session(action: "type", session_id: "session_1", selector: "#password", text: "pass")
browse_session(action: "click", session_id: "session_1", selector: "#login-btn")

browse_session(action: "wait", session_id: "session_1", selector: ".dashboard", timeout: 10000)
browse_session(action: "extract", session_id: "session_1", expression: "document.title")

browse_session(action: "close", session_id: "session_1")

Multi-article browsing example:

browse_session(action: "create")
browse_session(action: "goto", session_id: "session_1", url: "https://en.wikipedia.org/wiki/JavaScript")
browse_session(action: "extract", session_id: "session_1", expression: "document.title")
browse_session(action: "goto", session_id: "session_1", url: "https://en.wikipedia.org/wiki/Python")
browse_session(action: "extract", session_id: "session_1", expression: "document.title")
browse_session(action: "close", session_id: "session_1")

`browse_scrape` — parallel bulk scraping

Scrape multiple URLs simultaneously using isolated worker processes. Each URL gets its own headless browser worker — built on top of Obscura's native scrape command with obscura-worker.

Parameter	Type	Default	Max	Description
`urls`	`string[]`	—	1000	URLs to scrape in parallel
`eval`	`string`	—	—	JavaScript expression to evaluate per page
`concurrency`	`number`	`10`	`100`	Number of parallel worker processes
`timeout`	`number`	`60`	`300`	Per-worker timeout in seconds

Example:

browse_scrape(urls: ["https://news.ycombinator.com", "https://example.com"], eval: "document.title", concurrency: 25)

Output format (JSON):

{
  "total_urls": 2,
  "concurrency": 25,
  "total_time_ms": 1250,
  "avg_time_ms": 625.0,
  "results": [
    {
      "url": "https://news.ycombinator.com",
      "title": "Hacker News",
      "eval": "Hacker News",
      "time_ms": 612,
      "worker": 0
    },
    {
      "url": "https://example.com",
      "eval": "Example Domain",
      "time_ms": 638,
      "worker": 1
    }
  ]
}

On errors (timeout, network failure, etc.), the per-URL result includes an "error" field instead of "eval":

{
  "url": "https://slow-site.com",
  "error": "timeout",
  "time_ms": 60000
}

This is the tool that directly leverages Obscura's core advantage over headless Chrome: lightweight parallel scraping with built-in stealth. The ~30 MB per-worker memory footprint means 100 concurrent workers use less memory than a single Chrome instance.

Configuration

Claude Desktop / Cline / Continue / Any MCP client

{
  "mcpServers": {
    "obscura-mcp": {
      "command": "obscura-mcp",
      "args": ["--transport", "stdio"]
    }
  }
}

VS Code (Cline extension)

{
  "servers": {
    "obscura-mcp": {
      "command": "obscura-mcp",
      "args": ["--transport", "stdio"]
    }
  }
}

After global npm install, obscura-mcp is on your PATH — no absolute paths needed.

Environment Variables

Variable	Default	Description
`OBSCURA_PATH`	—	Path to custom Obscura binary
`OBSCURA_STEALTH`	—	Enable stealth mode (anti-detection)
`OBSCURA_PROXY`	—	Proxy URL for all traffic
`OBSCURA_USER_AGENT`	—	Default user-agent override
`MCP_HTTP_HOST`	`127.0.0.1`	HTTP transport host
`MCP_HTTP_PORT`	`3000`	HTTP transport port
`MCP_TRANSPORT`	`stdio`	Transport mode: `stdio` or `streamable-http`
`OBSCURA_STARTUP_TIMEOUT_MS`	`15000`	Milliseconds to wait for Obscura CDP to start
`OBSCURA_NAVIGATION_WAIT_MS`	`3000`	Milliseconds to wait after page navigation
`CDP_REQUEST_TIMEOUT_MS`	`10000`	Milliseconds to wait for CDP response

Development

Built with TypeScript, compiled to dist/, tested with Vitest.

git clone https://github.com/Metadrama/obscura-mcp
cd obscura-mcp
npm install
npm run build
npm test

All 36 integration tests run against a real Obscura binary (auto-downloaded on first run). Tests use StdioClientTransport and cover every tool, format, and action.

Why Obscura?

No Chrome — pure Rust, no 200 MB browser bundle
CDP-native — exposes Chrome DevTools Protocol directly
Anti-detection — built-in stealth for scraping-resistant sites
Tiny footprint — ~15 MB binary, starts in milliseconds

License

MIT

Available Tools

3 tools

browse_cookiesA

Navigate to a URL and retrieve all cookies set by the page. Returns cookie name, value, domain, path, and expiry for each cookie.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to visit
`stealth`	No	Accepted for compatibility. Stealth behavior is controlled by the Obscura server.

TDQS

A3.5/5.0

Behavior3/5

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

While annotations are absent, the description explains the stealth parameter's acceptance for compatibility and that actual behavior is server-controlled, adding some transparency. However, it does not disclose potential side effects like network requests, cookie setting by the page, or any required permissions.

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

Conciseness5/5

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

The description consists of two efficient sentences: the first states the purpose, the second details return fields. No wasted words, perfectly front-loaded.

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

Completeness3/5

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

Given no output schema and simple parameters, the description covers the core purpose and return structure. However, it omits error handling (e.g., invalid URL), edge cases (empty cookie set), and lacks usage context relative to siblings, leaving some gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds value for the stealth parameter by clarifying it is accepted but not effective, but for the url parameter it merely restates the schema. Overall, moderately helpful beyond schema.

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 description clearly states the verb 'Navigate' and 'retrieve', the resource 'URL' and 'cookies', and specifies the scope 'all cookies set by the page'. It also lists the returned fields, making the tool's function unambiguous and distinct from sibling tools like browse_url or browse_evaluate.

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

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool versus its siblings (browse_url, browse_evaluate). There is no mention of prerequisites, limitations, or alternative use cases, leaving the agent to infer the appropriate context.

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

browse_evaluateA

Navigate to a URL and execute JavaScript in the page context. Returns the evaluated result as a string. Supports extracting data, clicking elements, filling forms, and reading page state.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The URL to visit
`expression`	Yes	JavaScript expression to evaluate in the page context. The result is JSON-stringified. Examples: 'document.title', 'navigator.userAgent', 'document.querySelector("h1").textContent'
`stealth`	No	Accepted for compatibility. Stealth behavior is controlled by the Obscura server.

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so the description carries full burden. It reveals the tool modifies page state (via clicking/filling forms) and returns stringified results, but omits details on side effects (e.g., session changes, error handling).

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

Conciseness5/5

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

Two sentences with no wasted words. The first sentence states the primary action, the second lists capabilities, making it efficient and front-loaded.

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?

Given no output schema and no annotations, the description covers the main purpose and common use cases. However, it lacks details on return format for failures or async evaluation, slightly limiting completeness.

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 100% (baseline 3). The description adds value for the 'stealth' parameter by explaining compatibility and server control, and the 'expression' examples help, but overall schema already defines parameters clearly.

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 description clearly states the tool navigates to a URL and executes JavaScript, listing specific capabilities like extracting data, clicking elements, filling forms, and reading page state. It distinguishes from siblings (browse_cookies, browse_url) by focusing on script evaluation.

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

Usage Guidelines3/5

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

The description lists supported actions but does not explicitly guide when to use this tool versus alternatives. It lacks when-not guidance or mention of sibling tools, leaving context implied.

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

browse_urlA

Fetch a URL using Obscura's lightweight CDP engine. To access authenticated pages, pass cookies previously exported from browse_cookies.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to visit
`dump`	No	The format to return content in	html
`cookies`	No	Optional cookies to inject before navigation. Accepts the same format as returned by browse_cookies — an array of objects with at least name and value. Pass cookies exported from a real browser session to access authenticated pages.
`stealth`	No	Accepted for compatibility. Stealth behavior is controlled by the Obscura server.

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided. Description mentions 'lightweight CDP engine' and that stealth behavior is server-controlled, but lacks details on rendering, timeouts, or error handling, leaving significant behavioral aspects unspecified.

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

Conciseness5/5

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

Two sentences, front-loaded with purpose, followed by key guidance. No unnecessary words; every sentence serves a purpose.

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

Completeness3/5

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

While purpose and authentication context are covered, the absence of output schema and lack of details about behavior (e.g., whether it executes JavaScript, timeouts) mean an agent may need more information to use the tool effectively.

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 100% with clear parameter descriptions. The description adds value by contextualizing cookies usage (linking to browse_cookies) and explaining stealth as compatibility, going slightly beyond the schema.

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 description clearly states the tool fetches a URL using Obscura's CDP engine, and it distinguishes from siblings browse_cookies and browse_evaluate by focusing on URL fetching.

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 explicitly tells when to use cookies for authenticated pages and references browse_cookies as the source, but does not provide guidance on when not to use this tool or alternatives beyond cookies.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.1.0May 1, 2026
- First observedbrowse_cookies
- First observedbrowse_evaluate
- First observedbrowse_url

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool serves a distinct purpose: retrieving cookies, executing JavaScript, and fetching a URL. There is no ambiguity between the three operations.

Naming Consistency5/5

All tool names follow the consistent pattern 'browse_<operation>', using snake_case and a common prefix, ensuring predictability.

Tool Count3/5

With only 3 tools, the surface is thin for a browser automation server. It covers basic actions but feels minimal, so it is borderline appropriate.

Completeness3/5

The set covers URL fetching, cookie extraction, and JS execution, but lacks direct interaction tools (e.g., clicking, form filling, waiting). Workarounds are possible via JS, but gaps exist.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

docs
dev.continue
An MCP server for docs.continue.dev
Documentation Access Developer Tools Search
2
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
driflyte-mcp-server
com.driflyte
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Search Web Scraping Knowledge & Memory
211
vercel-mcpOAuth
com.vercel
An MCP server for Vercel
Cloud Platforms Developer Tools CI/CD & DevOps
2

Related MCP Servers

scraperapi-mcp-serverofficial
Web Scraping Browser Automation
scraperapi
A
license
A
quality
B
maintenance
A local MCP server that lets AI agents bypass bot detection, geo-restrictions, and JavaScript rendering challenges when scraping the web, backed by ScraperAPI's services
Updated 2 months ago (2026-07-17 14:31 UTC)
28
5
MIT
Algonius Browserofficial
Browser Automation Web Scraping
algonius
A
license
Not graded
quality
C
maintenance
An open-source MCP server that provides browser automation capabilities to external AI systems, enabling navigation, DOM interaction, and web content extraction.
Updated a year ago (2025-06-25 14:30 UTC)
20
Apache 2.0
Cloudflare Playwright MCP
Browser Automation Web Scraping
haruhi2ux
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI agents to automate browser interactions using Playwright and Cloudflare Workers, supporting tasks like navigation, clicking, typing, and screenshots.
Updated 3 months ago (2026-06-21 06:35 UTC)
6,282
Apache 2.0
krwl3r
Browser Automation Web Scraping
garciarsdiego
A
license
Not graded
quality
D
maintenance
MCP server for web scraping and browser automation, enabling AI agents to extract clean, token-efficient content from web pages.
Updated 6 months ago (2026-03-03 16:39 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Metadrama/obscura-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

obscura-mcp — ARCHIVED

Installation

Quick Start

Tools

browse_page — one-shot page reading

browse_interact — one-shot page actions

browse_session — multi-step persistent sessions

browse_scrape — parallel bulk scraping

Configuration

Claude Desktop / Cline / Continue / Any MCP client

VS Code (Cline extension)

Environment Variables

Development

Why Obscura?

License

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

scraperapi-mcp-serverofficial

Algonius Browserofficial

Cloudflare Playwright MCP

krwl3r

Latest Blog Posts

MCP directory API

`browse_page` — one-shot page reading

`browse_interact` — one-shot page actions

`browse_session` — multi-step persistent sessions

`browse_scrape` — parallel bulk scraping