Skip to main content
Glama
enesjakozh
302ai

302AI BrowserUse MCP Server

Official
by 302ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

🤖 302AI 브라우저MCP 서버 사용🚀✨

미리보기

다음은 몇 가지 사용 예입니다.

지원되는 도구 목록은 다음과 같습니다.

Related MCP server: MCP Web Research Server

✨ 특징 ✨

  • 🔧 동적 로딩 - 원격 서버에서 도구 목록을 자동으로 업데이트합니다.

  • 🌐 다양한 모드가 지원되므로 로컬에서 stdin 모드를 사용하거나 원격 HTTP 서버로 호스팅할 수 있습니다.

🚀 도구 목록

개발

종속성 설치:

지엑스피1

서버를 빌드하세요:

npm run build

자동 재빌드를 사용한 개발의 경우:

npm run watch

설치

Claude Desktop과 함께 사용하려면 서버 구성을 추가하세요.

MacOS의 경우: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows의 경우: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "302ai-browser-use-mcp": {
      "command": "npx",
      "args": ["-y", "@302ai/browser-use-mcp"],
      "env": {
        "302AI_API_KEY": "YOUR_API_KEY_HERE"
      }
    }
  }
}

Cherry Studio와 함께 사용하려면 서버 구성을 추가하세요.

{
  "mcpServers": {
    "Li2ZXXJkvhAALyKOFeO4N": {
      "name": "302ai-browser-use-mcp",
      "description": "",
      "isActive": true,
      "registryUrl": "",
      "command": "npx",
      "args": [
        "-y",
        "@302ai/browser-use-mcp"
      ],
      "env": {
        "302AI_API_KEY": "YOUR_API_KEY_HERE"
      }
    }
  }
}

ChatWise와 함께 사용하려면 다음 내용을 클립보드에 복사하세요.

{
  "mcpServers": {
    "302ai-sandbox-mcp": {
      "command": "npx",
      "args": ["-y", "@302ai/browser-use-mcp"],
      "env": {
        "302AI_API_KEY": "YOUR_API_KEY_HERE"
      }
    }
  }
}

설정 -> 도구 -> 버튼 추가 -> 클립보드에서 가져오기 선택으로 이동하세요.

여기에서 302AI_API_KEY를 찾으세요

튜토리얼 사용

디버깅

MCP 서버는 stdio를 통해 통신하므로 디버깅이 어려울 수 있습니다. 패키지 스크립트로 제공되는 MCP Inspector를 사용하는 것이 좋습니다.

npm run inspector

검사기는 브라우저에서 디버깅 도구에 액세스할 수 있는 URL을 제공합니다.

✨ 302.AI 소개 ✨

302.AI 는 종량제 서비스, 바로 사용 가능한 솔루션, 오픈 소스 생태계를 제공하는 기업 중심의 AI 애플리케이션 플랫폼입니다.✨

  1. 🧠 언어 모델, 이미지 모델, 음성 모델, 비디오 모델을 포함하되 이에 국한되지 않는 최신의 가장 포괄적인 AI 기능과 브랜드를 통합합니다.

  2. 🚀 기초 모델을 기반으로 심층적인 애플리케이션을 개발합니다. 단순한 챗봇이 아닌 실제 AI 제품을 개발합니다.

  3. 💰 월 이용료 없음, 모든 기능은 사용량에 따라 지불, 완전 개방, 매우 낮은 장벽과 높은 잠재력을 달성.

  4. 🛠 팀과 중소기업을 위한 강력한 관리 백엔드 - 한 사람이 관리하고, 여러 사람이 사용합니다.

  5. 🔗 모든 AI 기능은 API 액세스를 제공하고, 모든 도구는 오픈 소스이며 사용자 정의가 가능합니다(진행 중).

  6. 💡 탄탄한 개발팀을 갖추고 있으며, 매주 2~3개의 신규 애플리케이션을 출시하고 매일 업데이트되는 제품을 선보입니다. 참여를 원하시는 개발자분들은 언제든지 문의해 주세요.

Available Tools

2 tools
createBrowserAgentTaskA

Create a browser agent task, and return the task id. This agent can handle continuous complex tasks, and you do not need to break down the tasks. Just input them directly. Clearly return the task_id to the user for use in the next request.

ParametersJSON Schema
NameRequiredDescriptionDefault
taskYesThe task that you want to execute, natural language.

TDQS

A4/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. Describes creation and return of task_id, and that agent handles continuous complex tasks. Does not disclose potential side effects, authentication needs, or failure behavior.

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?

Three sentences, each earning its place: purpose, capability note, and output instruction. No redundant phrasing, front-loaded with key 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?

Given simple tool with one parameter, no output schema, and sibling tool, description sufficiently covers creation and follow-up usage. Lacks details on error handling or timeouts, but adequate for complexity.

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 has 100% coverage with a single 'task' parameter described as natural language. The description mildly reinforces this ('Just input them directly') but adds no extra semantic detail 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?

Clearly states 'Create a browser agent task' with verb+resource, and distinguishes from sibling tool getBrowserAgentTaskResult which retrieves results. Emphasizes handling of complex tasks without need for breakdown.

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?

Explicitly says 'you do not need to break down the tasks. Just input them directly,' providing clear when-to-use guidance. Also indicates to return task_id for use with sibling tool, but lacks explicit when-not-to-use or alternatives.

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

getBrowserAgentTaskResultA

Get the result of the browser agent task. If no results are obtained, clearly return the task_id to the user for use in the next request.

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesThe task id that you want to get the result.

TDQS

A3.8/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose key traits like polling behavior, idempotency, or error states. The note about returning task_id is an instruction to the agent, not a disclosure of tool behavior.

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, and no superfluous wording. Every sentence adds value.

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 simple getter tool with one parameter and no output schema, the description covers the core action and provides a fallback instruction. It could mention that results may be pending if the task is still running, but overall adequate.

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?

The only parameter 'task_id' is fully described in the schema ('The task id that you want to get the result.'). The description adds no extra meaning, but schema coverage is 100%, so baseline 3 is appropriate.

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?

Clearly states the tool's action: 'Get the result of the browser agent task.' The sibling tool 'createBrowserAgentTask' indicates creation, so this retrieval tool is distinct and well-defined.

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?

Includes explicit guidance on handling no results: 'If no results are obtained, clearly return the task_id to the user for use in the next request.' While it doesn't mention when to use versus the sibling, the context implies use after creation.

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.

  1. 2 tool updatesv1.0.0
    • First observedcreateBrowserAgentTask
    • First observedgetBrowserAgentTaskResult
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one creates a task, the other retrieves its result. There is no overlap or ambiguity.

Naming Consistency4/5

Both tools use camelCase and follow a verb_noun pattern, but one ends with 'Task' and the other with 'TaskResult', introducing minor inconsistency. Still understandable.

Tool Count3/5

With only 2 tools, the server feels minimal. While it may suffice for the specific purpose of managing browser agent tasks, it is on the low end of reasonable scope.

Completeness2/5

The tool set covers creation and result retrieval, but lacks any management operations (e.g., list, cancel, retry). This limits the agent's ability to handle errors or task lifecycles.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches