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 브리지

당신이 필요로 하는 마지막 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

두 스크립트 모두 멱등(idempotent)하며 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)을 사용하면 다음이 가능합니다:

HTTP, OpenAPI 사양 또는 사용자 지정 형식을 통해 모든 API에 연결
자동 인수 파싱을 사용하여 명령줄 도구 사용
내장 유틸리티로 텍스트 및 파일 처리
여러 도구를 원활하게 연결 및 결합

이 MCP 브리지를 사용하면 모든 UTCP 도구를 Claude Desktop 및 기타 MCP 클라이언트에서 사용할 수 있습니다.

🌟 기능

✅ 설치 불필요 - npx를 통해 작동
✅ 범용 호환성 - 모든 MCP 클라이언트와 작동
✅ 동적 구성 - 재시작 없이 도구 업데이트
✅ 환경 격리 - 각 프로젝트마다 고유한 구성 가능
✅ 포괄적인 도구 관리 - 도구 등록, 검색, 호출 및 검사
✅ 웹 인터페이스 제공 - web _ui _utcp _mcp _bridge/ 참조

🐍 Python 버전

Python 사용자는 python_mcp_bridge/의 독립형 Python 구현을 참조하세요.

🌐 웹 인터페이스

웹 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
staging-mcpOAuth
dev.riskprofiler
An MCP server that provides a hello tool
Developer Tools
1
test-mcp B
dev.riskprofiler
An MCP server that provides a hello tool
Developer Tools
11
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
C
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)
45
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