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-Brücke

Der letzte MCP-Server, den Sie jemals brauchen werden.

Ein universeller All-in-One-MCP-Server, der die volle Leistungsfähigkeit des Universal Tool Calling Protocol (UTCP) in das MCP-Ökosystem bringt.

🚀 Schnellstart

Fügen Sie diese Konfiguration zu Ihrem MCP-Client (Claude Desktop, etc.) hinzu:

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

Das war's! Keine Installation erforderlich. Die Brücke wird automatisch:

Die neueste Version über npx herunterladen und ausführen
Ihre UTCP-Konfiguration vom angegebenen Pfad laden
Alle Ihre UTCP-Handbücher als MCP-Tools registrieren
Eine einheitliche Schnittstelle zur Verwaltung Ihres Tool-Ökosystems bereitstellen

Related MCP server: MCP Proxy Server

🔧 Konfiguration

Erstellen Sie eine .utcp_config.json-Datei, um Ihre Tools und Dienste zu konfigurieren:

{
    "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)

Für Claude Code (die CLI / IDE-Erweiterung) registrieren Sie die Brücke als benutzerbezogenen MCP-Server:

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"}}'

Starten Sie danach Claude Code neu. Überprüfen Sie dies mit claude mcp list. Entfernen Sie es mit claude mcp remove utcp --scope user.

🧪 Lokale Entwicklung an der Brücke

Wenn Sie an @utcp/sdk oder einem anderen typescript-utcp-Paket arbeiten und es über Claude Code testen möchten, verwenden Sie die Entwicklungs-Skripte:

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

Beide Skripte sind idempotent und verändern niemals die package.json. Die Overlay-Strategie vermeidet npm link, was unter modernem npm unlink als uninstall --save aliasiert und die Abhängigkeit stillschweigend entfernen würde.

Das Skript erwartet, dass sich der typescript-utcp-Checkout neben diesem Repository befindet (../typescript-utcp). Überschreiben Sie dies bei Bedarf mit Flags:

--lib-dir <path> — verweist auf einen anderen typescript-utcp-Checkout oder übergeben Sie none, um den Overlay-Schritt vollständig zu überspringen (nützlich, wenn nur an der Brücke gearbeitet wird)
--name <mcp-name> (Standard utcp-dev) — nützlich, wenn Sie die Entwicklungs-Brücke neben einer veröffentlichten Version verwenden möchten
--config <path> (Standard ./.utcp_config.json) — verweist auf eine andere UTCP-Konfiguration

🛠️ Verfügbare MCP-Tools

Die Brücke stellt diese MCP-Tools zur Verwaltung Ihres UTCP-Ökosystems bereit:

register_manual - Registriert neue UTCP-Handbücher/APIs
deregister_manual - Entfernt registrierte Handbücher
call_tool - Führt jedes registrierte UTCP-Tool aus
search_tools - Findet Tools anhand ihrer Beschreibung
list_tools - Listet alle registrierten Tool-Namen auf
get_required_keys_for_tool - Ruft erforderliche Umgebungsvariablen ab
tool_info - Ruft vollständige Tool-Informationen und das Schema ab

📁 Was ist UTCP?

Das Universal Tool Calling Protocol (UTCP) ermöglicht Ihnen:

Verbindung zu jeder API über HTTP, OpenAPI-Spezifikationen oder benutzerdefinierte Formate
Nutzung von Befehlszeilen-Tools mit automatischer Argument-Analyse
Verarbeitung von Text und Dateien mit integrierten Dienstprogrammen
Verkettung und Kombination mehrerer Tools nahtlos

Mit dieser MCP-Brücke werden alle Ihre UTCP-Tools in Claude Desktop und anderen MCP-Clients verfügbar.

🌟 Funktionen

✅ Keine Installation - Funktioniert über npx
✅ Universelle Kompatibilität - Funktioniert mit jedem MCP-Client
✅ Dynamische Konfiguration - Tools aktualisieren ohne Neustart
✅ Umgebungsisolierung - Jedes Projekt kann seine eigene Konfiguration haben
✅ Umfassende Tool-Verwaltung - Tools registrieren, suchen, aufrufen und inspizieren
✅ Weboberfläche verfügbar - Siehe web _ui _utcp _mcp _bridge/

🐍 Python-Version

Für Python-Benutzer siehe die eigenständige Python-Implementierung in python_mcp_bridge/

🌐 Weboberfläche

Für eine erweiterte Verwaltung mit einer Web-Benutzeroberfläche, schauen Sie sich web_ui_utcp_mcp_bridge/ an

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