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 服务器

🚀 工具列表

发展

安装依赖项：

npm install

构建服务器：

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. 🚀 基于基础模型开发深度应用程序——我们开发真正的人工智能产品，而不仅仅是简单的聊天机器人

  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