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-сервер, который вам когда-либо понадобится.

Универсальный MCP-сервер «все в одном», который привносит всю мощь протокола универсального вызова инструментов (Universal Tool Calling Protocol, 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. Стратегия наложения (overlay) позволяет избежать 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

Мост предоставляет следующие инструменты MCP для управления вашей экосистемой UTCP:

register_manual - Регистрация новых руководств/API UTCP
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 _ui _utcp _mcp _bridge/

🐍 Версия для Python

Для пользователей Python см. автономную реализацию на Python в python_mcp_bridge/

🌐 Веб-интерфейс

Для расширенного управления с помощью веб-интерфейса ознакомьтесь с 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
11
staging-mcpOAuth
dev.riskprofiler
An MCP server that provides a hello tool
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