obscura-mcp
Officialobscura-mcp
스크래핑 및 AI 에이전트 자동화를 위한 경량 Rust 헤드리스 브라우저인 Obscura용 MCP 서버 어댑터입니다.
Obscura의 네이티브 CDP 기능을 깔끔한 MCP 인터페이스를 통해 제공합니다. Chrome 의존성이나 무거운 브라우저 자동화 도구가 필요하지 않습니다.
설치
npm install -g obscura-mcp설치는 즉시 완료됩니다. 브라우저 바이너리(~80 MB)는 처음 사용할 때 지연 다운로드됩니다.
설치 후 다음 중 하나를 수행하세요:
obscura-mcp install을 실행하여 진행 상황을 확인하며 바이너리를 다운로드하거나,그냥
obscura-mcp를 실행하세요. 자동으로 바이너리를 다운로드하고 서버를 시작합니다.
바이너리는 ~/.obscura/bin/에 캐시되며 npm 업그레이드 후에도 유지됩니다.
사용자 지정 바이너리 경로를 사용하려면:
export OBSCURA_PATH=/path/to/obscuraRelated MCP server: Algonius Browser
빠른 시작
# Install
npm install -g obscura-mcp
# Verify
obscura-mcp --version
# Download browser binary
obscura-mcp install
# Start MCP server
obscura-mcp --transport stdio도구
browse_url
Obscura의 CDP 엔진을 사용하여 URL을 가져옵니다. 페이지 콘텐츠를 반환합니다.
매개변수:
url(문자열, 필수): 방문할 HTTP 또는 HTTPS URL.dump(문자열, 선택 사항):html,text또는links. 기본값은html입니다.cookies(배열, 선택 사항): 탐색 전에 주입할 쿠키.browse_cookies가 반환하는 것과 동일한 형식을 허용합니다. 실제 브라우저에서 내보낸 쿠키를 전달하여 인증된 페이지에 액세스하세요.stealth(불리언, 선택 사항): 호환성을 위해 허용됩니다. 스텔스 동작은 Obscura 서버에 의해 제어됩니다.
browse_evaluate
URL로 이동하여 페이지 컨텍스트에서 JavaScript를 실행합니다. 평가된 결과를 반환합니다.
매개변수:
url(문자열, 필수): 방문할 URL.expression(문자열, 필수): 평가할 JavaScript 표현식. 예:document.title,navigator.userAgent,document.querySelector('h1').textContent.stealth(불리언, 선택 사항): 호환성을 위해 허용됩니다.
browse_cookies
URL로 이동하여 페이지에 의해 설정된 모든 쿠키를 검색합니다. 각 쿠키의 이름, 값, 도메인, 경로 및 만료 시간을 반환합니다.
매개변수:
url(문자열, 필수): 방문할 URL.stealth(불리언, 선택 사항): 호환성을 위해 허용됩니다.
구성
Claude Desktop / Cline / Continue / 모든 MCP 클라이언트
{
"mcpServers": {
"obscura-mcp": {
"command": "obscura-mcp",
"args": ["--transport", "stdio"]
}
}
}VS Code (Cline 확장 프로그램)
{
"servers": {
"obscura-mcp": {
"command": "obscura-mcp",
"args": ["--transport", "stdio"]
}
}
}전역 npm 설치 후 obscura-mcp는 PATH에 포함되므로 절대 경로가 필요하지 않습니다.
환경 변수
변수 | 기본값 | 설명 |
| — | 사용자 지정 Obscura 바이너리 경로 |
|
| HTTP 전송 호스트 |
|
| HTTP 전송 포트 |
|
| 전송 모드: |
|
| Obscura CDP 시작을 기다리는 밀리초 |
|
| 페이지 탐색 후 기다리는 밀리초 |
|
| CDP 응답을 기다리는 밀리초 |
왜 Obscura인가?
Chrome 없음 — 순수 Rust, 200MB 브라우저 번들 없음
CDP 네이티브 — Chrome DevTools Protocol을 직접 노출
탐지 방지 — 스크래핑 방지 사이트를 위한 내장 스텔스 기능
작은 설치 공간 — ~15MB 바이너리, 밀리초 단위로 시작
라이선스
MIT
Available Tools
3 toolsbrowse_cookiesA
Navigate to a URL and retrieve all cookies set by the page. Returns cookie name, value, domain, path, and expiry for each cookie.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to visit | |
| stealth | No | Accepted for compatibility. Stealth behavior is controlled by the Obscura server. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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.
| 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
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.
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.
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.
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.
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.
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.
3 tool updates
v0.1.0- First observed
browse_cookies - First observed
browse_evaluate - First observed
browse_url
TDQS
Scored across 3 tools
Each tool serves a distinct purpose: retrieving cookies, executing JavaScript, and fetching a URL. There is no ambiguity between the three operations.
All tool names follow the consistent pattern 'browse_<operation>', using snake_case and a common prefix, ensuring predictability.
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.
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
Related MCP Connectors
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Programmatic web-scraping MCP server powered by x402 micro-transactions on Base.
Turn any public website into an MCP server for agents to search, read and navigate.
Related MCP Servers
AlicenseAqualityDmaintenanceA local MCP server that lets AI agents bypass bot detection, geo-restrictions, and JavaScript rendering challenges when scraping the web, backed by ScraperAPI's services285MIT
Algonius Browserofficial
AlicenseNot gradedqualityCmaintenanceAn open-source MCP server that provides browser automation capabilities to external AI systems, enabling navigation, DOM interaction, and web content extraction.20Apache 2.0- AlicenseNot gradedqualityCmaintenanceAn MCP server that enables AI agents to automate browser interactions using Playwright and Cloudflare Workers, supporting tasks like navigation, clicking, typing, and screenshots.9,525 npmApache 2.0
- AlicenseNot gradedqualityDmaintenanceMCP server for web scraping and browser automation, enabling AI agents to extract clean, token-efficient content from web pages.1MIT