Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BeefChicken MCP Call the GitHub API to list my starred repositories"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
BeefChicken MCP は、任意の openapi.yaml を配置するだけで、対象の Web API を Claude や Cursor などの MCPクライアント から直接呼び出せるようにする汎用 MCP サーバー（プロキシ）です。
特定のAPIに依存する実装コードは一切不要。APIキーを直接指定できないクライアント向けに 簡易 OAuth 2.1 サーバー まで同梱しているため、Claude.ai (Web版) にもそのまま接続できます。
graph LR
subgraph Client [AIクライアント]
Claude[🤖 Claude.ai / Cursor 等]
end
subgraph Proxy [BeefChicken MCP]
MCP[⚡ MCPサーバー<br/>Workers / Node.js / Docker]
OAuth[🔐 内蔵 OAuth 2.1]
end
subgraph Target [接続先API]
Spec[📄 docs/openapi.yaml]
API[🌐 対象Web API<br/>Stripe / GitHub / 社内API]
end
Spec -->|ビルド時/起動時に静的JSON化| MCP
Claude -->|MCPプロトコル / OAuth| MCP
MCP -->|ネイティブfetch| APIRelated MCP server: OpenAPI MCP Server
MCPサーバーを作るために、TypeScriptやPythonでツール定義やリクエストハンドラをガリガリ書く必要がある。
APIの仕様変更のたびにコードを修正・テストして再デプロイするのが大変。
Claude.ai (Web版) で自作ツールを使いたいが、OAuth 2.1 認証サーバー構築のハードルが高い。
🧩 コード記述 0 行: docs/openapi.yaml を繋ぎたいAPIの仕様書に差し替えるだけ！
🔐 Claude.ai (Web版) 即対応: 簡易 OAuth 2.1 サーバー内蔵で、Web版Claudeのカスタムコネクタも一発接続。
⚡️ サーバー維持費 0 円: Cloudflare Workers に数秒でデプロイ（Docker / Node.js にも対応）。無料枠内ならタダでMCPサーバーがあなたのものに。
📥 デプロイすら不要な最短経路: Claude Desktop 等のローカルクライアントなら、cloneもビルドも不要。npm から npx beefchicken-mcp で即起動。
📦 超軽量＆ゼロパースオーバーヘッド: OpenAPI 仕様書はビルド時（Workers）・起動時（Docker）・デプロイ前の npm run generate（Node.js）のいずれかで静的 JSON へ変換済み。リクエスト処理中の YAML パースは一切不要。
機能 / 特徴 | 手動実装 (TS/Python SDK) | 一般的なMCPフレームワーク (FastMCP等) | BeefChicken MCP |
コード記述 | 必要 (多) | 必要 (少) | 不要 (0行・YAML置くだけ) |
OpenAPI対応 | ❌ 要手動変換 | ⚠️ 要ハンドラ実装 | ✅ ファイル差し替えのみ |
OAuth 2.1 サーバー内蔵 | ❌ 自作が必要 | ❌ 自作が必要 | ✅ 内蔵 (Claude Web即対応) |
Cloudflare Workers | ⚠️ 要調整 | ⚠️ 要調整 | ✅ 完全対応 (ボタンデプロイ) |
実行時フットプリント | - | 中〜大 | 極小 (静的JSON化) |
🧩 設定ファイルの差し替えだけで完結: コードを1行も書かずに任意の Web API を MCP ツール化。
🎯 専用プロキシに徹した設計: 複雑なハンドラ記述を排除し、仕様書通りの純粋なプロキシとして動作。
📦 静的JSON変換: 実行時の YAML パーサーや $ref 解決ロジックを非搭載にし、Worker バンドルサイズを最小化。
🔌 ネイティブ fetch 中継: 余計な HTTP クライアントライブラリを挟まずレスポンスをダイレクト中継。
🛡️ Stateless & Robust: SSE 長時間保持に依存しない responseMode: 'json' 構成。タイムアウト制限に強い堅牢設計。
📦 4通りの配布形態: Cloudflare Workers / Node.js / Docker イメージ（GHCR）/ npm CLI（npx beefchicken-mcp）。用途に応じて選択可能。
⚠️ 本番公開前の注意点: 本サーバー自体にはレート制限がありません。公開時は Cloudflare の Rate Limiting Rules やリバースプロキシ等で制御してください。また同梱の OAuth 2.1 サーバーは簡易実装です。詳細は 認証ドキュメント を確認してください。
docs/openapi.yaml を繋ぎたい API の OpenAPI 3.0 仕様書に差し替えます。
💡 ヒント: Stripe や GitHub などの標準 OpenAPI は公式や APIs.guru 等から入手できます。
npm install
npm run generate # docs/openapi.yaml を解析し、src/generated/tools.json を自動生成ローカル MCP クライアント（Claude Desktop 等）の場合 — 最短:
npx beefchicken-mcp --openapi /絶対パス/to/openapi.yamlnpm パッケージとして配布しているため、cloneもデプロイも不要です（この経路では手順1の npm install / npm run generate も不要で、指定した仕様書を起動のたびにオンメモリで解析します）。クライアント設定への具体的な登録方法は手順4を参照してください。
Cloudflare Workers の場合:
npx wrangler deploy成功すると https://beefchicken-mcp.<あなたのサブドメイン>.workers.dev/mcp が発行されます（D1設定等の詳細は デプロイ手順 参照）。
Node.js の場合:
API_BASE_URL=https://api.example.com npm run node:devDocker の場合:
docker run -p 3000:3000 \
-e HOST=0.0.0.0 \
-e ALLOWED_HOSTS=127.0.0.1,localhost \
-e API_BASE_URL=https://api.example.com \
-v $(pwd)/docs/openapi.yaml:/app/docs/openapi.yaml:ro \
ghcr.io/watanabebashi/beefchicken-mcpイメージは GHCR から配布されており、ビルドは不要です。自分の openapi.yaml をマウントすると、コンテナ起動時にそれを解析して tools.json を生成します（マウントしない場合は同梱のサンプル仕様書が使われます）。タグは latest（最新リリース）・vX.Y.Z（特定バージョン固定）・edge（main ブランチの最新ビルド）から選べます。ローカルの変更を試したい場合は、従来どおり docker build -t beefchicken-mcp . でビルドできます。
発行された URL に対し Authorization: Bearer <対象APIのAPIキー> ヘッダーを付けて MCP クライアントに設定します。
Claude Desktop / Claude Code のように MCP サーバーをサブプロセスとして起動するクライアントには、デプロイ不要で npx 経由で直接接続できます。設定ファイル（例: claude_desktop_config.json）に以下を追加してください。
{
"mcpServers": {
"my-api": {
"command": "npx",
"args": ["beefchicken-mcp", "--openapi", "/絶対パス/to/your-api-openapi.yaml"],
"env": {
"API_KEY": "<対象APIのAPIキー>",
"API_BASE_URL": "https://api.example.com"
}
}
}
}--openapi に対象APIの OpenAPI 仕様書への絶対パスを指定すると、起動のたびにオンメモリでツール定義を生成します（事前の npm run generate は不要）。フラグを省いた位置引数（["beefchicken-mcp", "/絶対パス/to/your-api-openapi.yaml"]）でも同じ動作です。パスを一切指定しなかった場合は、クローン済みリポジトリ内で事前に生成済みの src/generated/tools.json にフォールバックします（無ければ起動時にエラーで停止します）。cwd 相対のデフォルト仕様書は意図的に持ちません。MCPクライアントがサブプロセスを起動する際の cwd は予測できないため、必ず絶対パスで指定してください。
API_KEY は必須です。stdio モードは Web版向けの簡易OAuthサーバーを経由せず、API_KEY の値をそのまま対象APIへの Authorization: Bearer として使います。
リポジトリを clone した状態でクライアントに登録したい場合は、command を npx、args を ["tsx", "src/stdio.ts", "--openapi", "./docs/openapi.yaml"] にし、cwd（対応しているクライアントの場合）をリポジトリのルートに設定しても同じエントリーポイント（src/stdio.ts）が起動します（npm run stdio は npm のバナー出力が標準出力に混ざり stdio の JSON-RPC 通信を壊すため、クライアント設定には使わないでください。手元のターミナルで単体動作を確認する用途に留めてください）。
トピック | 内容 |
🔑 認証 | APIキーの送信方法・設計方針、claude.ai Web版向けカスタムコネクタの接続方法 |
☁️ デプロイ | Cloudflare Workers / Node.js / Docker へのデプロイ手順 |
⚙️ 環境変数 | 全設定項目のリファレンス |
🛠 開発 | ローカル実行・テスト手順・OpenAPI更新・安全性チェック |
MIT License. 詳細は LICENSE を参照してください。
List tasks
| Name | Required | Description | Default |
|---|---|---|---|
| completed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List tasks' conveys a read-only collection operation and little else; it does not mention filtering, pagination, authentication, or any other behavioral traits.
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 is concise at two words, but it is under-specified rather than efficiently complete. It earns its place as a minimal label, yet it does not provide enough structured meaning for a helpful tool definition.
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?
For a tool with one optional parameter and no output schema, the description should at least mention the filtering capability and what the response represents. 'List tasks' leaves critical invocation context unexplained, so the definition is incomplete.
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 0% and the description does not mention the 'completed' parameter at all. The schema only reveals a boolean property, but the description adds no meaning about whether it filters tasks by completion status, leaving the agent to guess.
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 states a specific verb ('List') and resource ('tasks'), making the collection-level intent clear. It is not a tautology, though it does not explicitly differentiate from the sibling tasks_id_get beyond implying a list-versus-single distinction.
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?
There is no guidance on when to use this tool versus tasks_post, tasks_id_get, or tasks_id_delete. The description implies listing as opposed to creating, fetching, or deleting, but provides no explicit usage context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a task
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is a delete (destructive), but gives no information about permanence, idempotency, authorization requirements, or whether deletion cascades to related data. This is a minimal statement of effect, nothing more.
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 is appropriately short for a simple tool and front-loads the action. However, it is closer to under-specification than effective conciseness, as it omits necessary behavioral context that an agent would need.
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 the tool is destructive, has no annotations, and no output schema, the description is incomplete. It does not mention return values, error behavior (e.g., 404 if task not found), or side effects, leaving significant operation details to inference.
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 0%, and the description does not explain what the 'id' parameter refers to beyond the schema's type and required flag. Although the single integer parameter is intuitive from the tool name, the description adds no semantic value over 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 states a specific verb ('Delete') and a resource ('task'), which clearly distinguishes it from the siblings tasks_get, tasks_post, and tasks_id_get. The operation is unambiguous, although it adds no detail about scope or type of task.
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 gives no guidance on when to use this tool versus alternatives like tasks_post for creation or tasks_get for retrieval. There are no exclusions, prerequisites, or conditions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a task
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only implies a read-only action via the verb 'Get'; it does not describe return format, error behavior, authentication needs, or idempotency.
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 is a single, front-loaded sentence with no filler or redundancy. It is appropriately sized for a one-parameter tool, though adding 'by id' would make it slightly more informative without harming conciseness.
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?
With no output schema and no annotations, the description is the only source of context, and it is minimal. It does not mention what a successful response contains, error cases, or any behavioral caveats, leaving the agent with incomplete information for fully reliable invocation.
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 0%, and the description does not explain the 'id' parameter beyond what the schema shows (integer, required). The parameter name is somewhat self-explanatory, but the description adds no meaning about how the id is used or validated.
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 uses a specific verb ('Get') and resource ('a task'), which clearly indicates a retrieval operation and helps differentiate from sibling tools like tasks_post and tasks_id_delete. However, it does not explicitly mention that retrieval is by id, which is only evident from the tool name.
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 provides no guidance on when to use this tool versus its siblings. Sibling tools such as tasks_get, tasks_post, and tasks_id_delete are present, but the description does not mention any of them, nor does it state conditions, exclusions, or alternate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a task
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Create a task' and does not explain side effects, persistence, authentication needs, idempotency, or what the response contains.
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 is an extremely short, front-loaded phrase with zero redundant words. Every word earns its place for such a simple create operation.
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?
Fora one-parameter create operation, the schema plus description provide enough to make a basic call. However, the definition is only minimally complete: it provides no response expectations, no behavioral notes, and no relationship to the sibling tools.
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 0% and the description adds no parameter-level meaning. The required 'title' parameter is left entirely to the schema, with no explanation of what a valid taskt itle should look like beyond being a string of at most200 characters.
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 a specific verb and resource: 'Create a task'. This unambiguously identifies a creation operation and distinguishes it from the sibling tools that get or delete tasks, even without naming them.
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?
There is no guidance about when to use this tool versus alternatives. It does not mention siblings such as tasks_get or tasks_id_delete, nor any conditions, prerequisites, or context that would help an agent choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool maps to a distinct operation: list, create, get by ID, and delete by ID. There is no meaningful overlap, and the names make the resource and action clear.
All tool names follow the same resource_verb pattern, with tasks_id_get and tasks_id_delete clearly indicating the ID path parameter. The consistent snake_case and operation-based suffixes make the set predictable.
Four tools is an appropriate, focused count for a simple task management server. Each tool covers a core operation without unnecessary bloat.
The server covers list, create, read, and delete operations for tasks, but notably lacks an update operation. This is a minor gap since delete-and-recreate is a possible workaround, but update is a standard task lifecycle need.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for Argo RPG Platform — connects AI assistants to campaign data via OAuth2
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Watanabebashi/BeefChicken-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
