Skip to main content
Glama
deenesjakoruzh
universal-tool-calling-protocol

UTCP-MCP Bridge

Official
by universal-tool-calling-protocol
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

UTCP-MCP 桥接器

你唯一需要的最后一个 MCP 服务器。

一个通用的、一体化的 MCP 服务器，将通用工具调用协议 (UTCP) 的全部功能带入 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？

通用工具调用协议 (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
NameRequiredDescriptionDefault
tool_nameYesThe full name of the tool to call.
argumentsYesA 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
NameRequiredDescriptionDefault
manual_nameYesThe 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
NameRequiredDescriptionDefault
tool_nameYesName 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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault
manual_call_templateYesThe 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
NameRequiredDescriptionDefault
task_descriptionYesA natural language description of the task.
limitNo

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
NameRequiredDescriptionDefault
tool_nameYesName 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.

  1. 7 tool updatesv1.1.0
    • 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

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • proxy-mcp

    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.
    7
    -

  • MCP Tools Hub

    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.
    -

Latest Blog Posts

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