de en es ja ko ru zh

UTCP-MCP Bridge

Name: UTCP-MCP Bridge
Author: universal-tool-calling-protocol

Official

by universal-tool-calling-protocol

Overview Schema Related Servers Score Discussions

Python

Hybrid

UTCP-MCP Bridge

これさえあれば、他のMCPサーバーは不要です。

Universal Tool Calling Protocol (UTCP) の全機能をMCPエコシステムにもたらす、オールインワンのユニバーサルMCPサーバーです。

🚀 クイックスタート

MCPクライアント（Claude Desktopなど）に以下の設定を追加してください：

{
  "mcpServers": {
    "utcp": {
      "command": "npx",
      "args": ["@utcp/mcp-bridge"],
      "env": {
        "UTCP_CONFIG_FILE": "/path/to/your/.utcp_config.json"
      }
    }
  }
}

以上です！ インストールは不要です。このブリッジは自動的に以下の処理を行います：

npx経由で最新バージョンをダウンロードして実行
指定されたパスからUTCP設定を読み込み
すべてのUTCPマニュアルをMCPツールとして登録
ツールエコシステムを管理するための統合インターフェースを提供

Related MCP server: MCP Proxy Server

🔧 設定

.utcp_config.json ファイルを作成し、ツールとサービスを設定します：

{
    "load_variables_from": [
      {
        "variable_loader_type": "dotenv",
        "env_file_path": ".env"
      }
    ],
    "manual_call_templates": [
      {
          "name": "openlibrary",
          "call_template_type": "http",
          "http_method": "GET", 
          "url": "https://openlibrary.org/static/openapi.json",
          "content_type": "application/json"
      }
    ],
    "post_processing": [
      {
          "tool_post_processor_type": "filter_dict",
          "only_include_keys": ["name", "description"],
          "only_include_tools": ["openlibrary.*"]
      }
    ],
    "tool_repository": {
      "tool_repository_type": "in_memory"
    },
    "tool_search_strategy": {
      "tool_search_strategy_type": "tag_and_description_word_match"
    }
}

Claude Code (CLI)

Claude Code (CLI / IDE拡張機能) の場合、ブリッジをユーザースコープのMCPサーバーとして登録します：

claude mcp add-json --scope user utcp '{"type":"stdio","command":"npx","args":["@utcp/mcp-bridge"],"env":{"UTCP_CONFIG_FILE":"/absolute/path/to/.utcp_config.json"}}'

その後、Claude Codeを再起動してください。claude mcp list で確認できます。削除する場合は claude mcp remove utcp --scope user を実行してください。

🧪 ブリッジのローカル開発

@utcp/sdk やその他の typescript-utcp パッケージを開発中で、Claude Codeを通じてテストしたい場合は、開発用スクリプトを使用してください：

cd utcp-mcp
npm install
npm run dev:register     # builds typescript-utcp packages, overlays each into the bridge's node_modules, builds the bridge, and registers it as 'utcp-dev' in Claude Code
# restart Claude Code

# After every edit:
npm run dev:register     # rebuilds, re-registers; restart Claude Code

# When done:
npm run dev:unregister   # removes the MCP entry and restores registry node_modules

どちらのスクリプトも冪等であり、package.json を変更することはありません。オーバーレイ戦略により npm link を回避しています（最近のnpmでは unlink が uninstall --save にエイリアスされており、依存関係が意図せず削除されてしまうため）。

このスクリプトは、typescript-utcpのチェックアウトがこのリポジトリの隣（../typescript-utcp）にあることを想定しています。そうでない場合はフラグで上書きしてください：

--lib-dir <path> — 別のtypescript-utcpチェックアウトを指定します。オーバーレイ手順を完全にスキップするには none を渡します（ブリッジのみを編集する場合に便利です）。
--name <mcp-name> (デフォルト utcp-dev) — 公開済みのブリッジと並行して開発用ブリッジを使用したい場合に便利です。
--config <path> (デフォルト ./.utcp_config.json) — 別のUTCP設定ファイルを指定します。

🛠️ 利用可能なMCPツール

このブリッジは、UTCPエコシステムを管理するために以下のMCPツールを公開します：

register_manual - 新しいUTCPマニュアル/APIを登録
deregister_manual - 登録済みマニュアルを削除
call_tool - 登録済みUTCPツールを実行
search_tools - 説明文からツールを検索
list_tools - 登録済みツール名の一覧を表示
get_required_keys_for_tool - 必要な環境変数を取得
tool_info - ツールの完全な情報とスキーマを取得

📁 UTCPとは？

Universal Tool Calling Protocol (UTCP) を使用すると、以下のことが可能になります：

あらゆるAPIへの接続 (HTTP、OpenAPI仕様、またはカスタムフォーマット経由)
コマンドラインツールの使用 (自動引数解析付き)
テキストおよびファイルの処理 (組み込みユーティリティを使用)
ツールの連結と組み合わせ (シームレスに連携)

このMCPブリッジを使用することで、すべてのUTCPツールがClaude Desktopやその他のMCPクライアントで利用可能になります。

🌟 特徴

✅ インストール不要 - npx経由で動作
✅ ユニバーサルな互換性 - あらゆるMCPクライアントで動作
✅ 動的設定 - 再起動なしでツールを更新可能
✅ 環境の分離 - プロジェクトごとに独自の設定が可能
✅ 包括的なツール管理 - ツールの登録、検索、呼び出し、検査が可能
✅ Webインターフェース利用可能 - web _ui _utcp _mcp _bridge/ を参照

🐍 Python版

Pythonユーザーの方は、python_mcp_bridge/ にあるスタンドアロンのPython実装をご覧ください。

🌐 Webインターフェース

Web UIを使用した高度な管理については、web_ui_utcp_mcp_bridge/ をご確認ください。

Available Tools

7 tools

call_toolCall a UTCP ToolB

Calls a registered tool by its full namespaced name.

ParametersJSON Schema

Name	Required	Description	Default
`tool_name`	Yes	The full name of the tool to call.
`arguments`	Yes	A JSON object of arguments.

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description only says 'calls' without disclosing side effects, return values, permissions, or invocation behavior (synchronous vs. asynchronous).

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?

Single sentence, no fluff, front-loaded with the verb 'calls' and the object 'tool'. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no description of return behavior; fails to explain how this tool fits with registration siblings, e.g., that the tool must already be registered. Incomplete for a generic invoker.

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 coverage is 100%, so baseline is 3. The description adds little beyond schema (only 'full namespaced name' for tool_name, which is already implied by 'full name'). Insufficient to raise score.

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?

The description clearly states it calls a registered tool by its full namespaced name, distinguishing it from browsing or registration tools like list_tools and register_manual.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to use this tool versus alternatives like tool_info or search_tools; no prerequisites or conditional usage mentioned.

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

deregister_manualDeregister a UTCP ManualC

Deregisters a tool provider from the UTCP client.

ParametersJSON Schema

Name	Required	Description	Default
`manual_name`	Yes	The name of the manual to deregister.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It indicates a mutation, but does not mention side effects (e.g., idempotency, failure behavior if manual doesn't exist, or impacts on other tools). This leaves the agent uncertain about the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no wasted words. It is front-loaded with the verb. However, it could benefit from a bit more context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description provides minimal context. It lacks information on return values, error conditions, or prerequisites (e.g., the manual must be registered). The sibling 'register_manual' likely has a similar description, missing a chance to differentiate.

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 description coverage is 100% for the single parameter. The description adds no meaning beyond the schema's parameter description ('The name of the manual to deregister.'). Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'deregisters' and the resource 'tool provider', making the action clear. It implicitly distinguishes from the sibling 'register_manual' by being the inverse operation. However, it conflates 'manual' with 'tool provider' slightly, which could be more precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., when not to use it, or prerequisites like checking if the manual is already registered). The agent receives no context for decision-making.

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

get_required_keys_for_toolGet Required Variables for ToolB

Get required environment variables for a registered tool.

ParametersJSON Schema

Name	Required	Description	Default
`tool_name`	Yes	Name of the tool to get required variables for.

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must disclose behavior but only states a vague action. It omits details such as what happens if the tool is not found, whether the result is a list or single value, and any error conditions. This is insufficient for an agent to predict outcomes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no unnecessary words. It is front-loaded and efficient, though it could be restructured to include more context without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is minimally adequate. However, it lacks details about return format, error behavior, and usage context, which would make it complete for an agent.

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 coverage is 100% and the parameter 'tool_name' is well described in the schema. The description adds no extra meaning beyond the schema, 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?

The description specifies the verb 'get' and resource 'required environment variables' for a registered tool, clearly distinguishing it from sibling tools like 'call_tool' (executes tool) and 'list_tools' (lists available tools).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. For instance, it doesn't mention it should be used before calling a tool to ensure environment variables are set, nor does it reference sibling tools like 'tool_info' that might provide similar information.

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

list_toolsList All Registered UTCP ToolsA

Returns a list of all tool names currently registered.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description must fully convey behavior. It states it returns names but does not disclose whether this is a read-only operation, performance implications, or if it includes all registered tools. Minimal behavioral context.

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?

Single sentence, front-loaded with the action and result. No unnecessary words.

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 list tool with no parameters and no output schema, the description is mostly sufficient. It could be improved by hinting at alternative tools for details, but it covers the essential purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the description doesn't need to explain them. It adds value by naming the output (tool names). Baseline for 0 params is 4.

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?

The description clearly states it returns a list of all tool names. It uses specific verb 'returns' and resource 'tool names', and distinguishes from siblings like 'search_tools' (filtered) and 'tool_info' (detailed info).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'search_tools' or 'tool_info'. The description does not explain the scope or limitations (e.g., only names).

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

register_manualRegister a UTCP ManualB

Registers a new tool provider by providing its call template.

ParametersJSON Schema

Name	Required	Description	Default
`manual_call_template`	Yes	The call template for the UTCP Manual endpoint.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as idempotency, side effects (e.g., overwriting existing registrations), or authorization requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, concise and front-loaded. However, it sacrifices detail; but for a simple tool, this is acceptable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema or annotations, the description should provide more context (e.g., what happens on success, prerequisite steps). It only covers the bare minimum.

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 description coverage is 100% for the single parameter, so the bar is lower. The description adds no extra meaning beyond the schema's 'The call template for the UTCP Manual endpoint.'

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?

The description clearly states the action 'Registers a new tool provider' and specifies the mechanism 'by providing its call template'. This distinguishes it from sibling tools like deregister_manual (opposite) and list_tools (listing).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives (e.g., when is registration needed? What about updating?). It only states the action without context.

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

search_toolsSearch for UTCP ToolsC

Searches for relevant tools based on a task description.

ParametersJSON Schema

Name	Required	Description	Default
`task_description`	Yes	A natural language description of the task.
`limit`	No

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description does not disclose how the search works (e.g., semantic vs keyword), what results are returned, or any potential side effects. The short description omits important behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, making it concise. However, it sacrifices completeness for brevity and could include more useful information without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description does not specify the return format or structure, which is problematic since no output schema exists. It is minimally adequate for a simple tool but lacks completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 50% of parameters with descriptions, but the tool description adds no extra meaning. The 'limit' parameter lacks explanation, and 'task_description' format is not elaborated.

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?

The description clearly states the tool searches for tools based on a task description, which differentiates it from siblings like list_tools and call_tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as list_tools or tool_info. The description lacks context for decision-making.

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

tool_infoGet Tool InformationB

Get complete information about a specific tool including all details.

ParametersJSON Schema

Name	Required	Description	Default
`tool_name`	Yes	Name of the tool to get complete information for.

TDQS

B3.2/5.0

Behavior2/5

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

Annotations lacking; description does not reveal behavioral traits such as whether tool info is cached, operation speed, or authentication requirements. 'Complete information' is ambiguous, leaving the agent uncertain about return structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise but lacks specificity; could be improved by front-loading key qualifiers.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without output schema, the description should clarify that the response contains fields like name, description, parameters, etc., but it does not. Tool complexity is low, but description under-specifies return value.

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 sole parameter 'tool_name' is already fully described in the schema (100% coverage). The description adds no additional semantic insight beyond the 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?

The description clearly states the action (Get) and the target (tool information), and specifies granularity (complete info for a specific tool), distinguishing it from list_tools and search_tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus its siblings; missing use-case context like 'use this when you need all details of a single tool'.

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. Dates show when Glama detected each change.

7 tool updatesv1.1.0May 7, 2026
- First observedcall_tool
- First observedderegister_manual
- First observedget_required_keys_for_tool
- First observedlist_tools
- First observedregister_manual
- First observedsearch_tools
- First observedtool_info

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool targets a distinct operation: calling, registering, deregistering, listing, searching, retrieving keys, and getting info. No two tools overlap in purpose.

Naming Consistency4/5

Most tools follow verb_noun pattern (e.g., call_tool, list_tools), but tool_info uses noun_noun instead of get_tool_info, introducing a minor inconsistency.

Tool Count5/5

With 7 tools covering registration, deregistration, listing, searching, calling, and info retrieval, the count is well-scoped for a bridge server.

Completeness5/5

The tool set covers the full lifecycle: register, deregister, list, search, call, and retrieve necessary information (keys and details). No obvious gaps for the intended purpose.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
test-mcp B
dev.riskprofiler
An MCP server that provides a hello tool
Developer Tools
11
staging-mcpOAuth
dev.riskprofiler
An MCP server that provides a hello tool
Developer Tools
1
Project Gumball A
com.gumballtools
One MCP server exposing every tool in the Gumball portfolio.
Developer Tools
251

Related MCP Servers

mcp-toolkit-hub
Agent Orchestration Developer Tools
lokkaflokka
A
license
Not graded
quality
C
maintenance
MCP hub server that aggregates tools from multiple domain packages into a single globally-available interface.
Updated 2 months ago (2026-07-17 13:51 UTC)
1
MIT
MCP Proxy Server
Developer Tools Agent Orchestration
ptbsare
A
license
Not graded
quality
B
maintenance
Aggregates multiple backend MCP servers into a single unified interface with optional web management UI for tool control and configuration.
Updated a year ago (2025-07-27 04:40 UTC)
41
193
MIT
proxy-mcp
Agent Orchestration Developer Tools
Rixmerz
F
license
A
quality
D
maintenance
Universal MCP proxy server that discovers, searches, and executes tools across all configured MCP servers from a single entry point.
Updated 7 months ago (2026-02-19 14:32 UTC)
7
-
MCP Tools Hub
Developer Tools
lapaduga
F
license
Not graded
quality
B
maintenance
MCP server with a web interface for viewing and calling tools via REST API, enabling easy tool management through a browser.
Updated 2 months ago (2026-06-27 19:57 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/universal-tool-calling-protocol/utcp-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server