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. 🚀 基礎モデルに基づいた高度なアプリケーションを開発 - 単純なチャットボットではなく、本物の AI 製品を開発します

  3. 💰 月額料金はゼロ、すべての機能は従量課金制、完全にオープンで、非常に低い障壁と高い可能性を実現します。

  4. 🛠 チームおよび中小企業向けの強力な管理バックエンド - 1 人が管理し、多くの人が使用します。

  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