UTCP: um protocolo alternativo ao MCP para chamada de ferramentas

Introdução

Com a rápida evolução dos agentes de IA, um novo desafio se tornou evidente:
como permitir que modelos chamem ferramentas externas (APIs, CLIs, serviços e streams) de forma padronizada, segura e eficiente?

Grande parte das soluções atuais depende de camadas intermediárias, servidores “wrappers” ou protocolos que exigem infraestrutura adicional. É nesse contexto que surge o UTCP (Universal Tool Calling Protocol), um protocolo aberto que propõe uma abordagem mais direta e simples.

Essa postagem analisa o que é o UTCP, seus diferenciais técnicos, riscos, comparações com alternativas como MCP e onde ele faz mais sentido na prática.

O que é o UTCP?

O UTCP (Universal Tool Calling Protocol) é um protocolo aberto que descreve como ferramentas podem ser chamadas por agentes de IA usando diretamente seus protocolos nativos, sem a necessidade de servidores intermediários.

A ideia central é simples e poderosa:

“Se um humano consegue chamar uma ferramenta, um agente de IA também deveria conseguir sem wrappers adicionais.”

O UTCP atua como um contrato descritivo, informando:

• quais ferramentas existem;
• como elas são chamadas;
• quais parâmetros aceitam;
• quais protocolos utilizam (HTTP, WebSocket, CLI, streaming etc.), todos protocolos suportados Protocols.

Os quatro princípios centrais do UTCP

O UTCP foi concebido em torno de quatro princípios que o tornam atraente:

• Sem wrapper tax: Ferramentas existentes funcionam como estão não há necessidade de reescrever API ou deployar camadas extras.

• Aproveitar infraestrutura nativa: Autenticação, autorização e políticas de segurança são simplesmente reaproveitados da forma como a ferramenta já funciona.

• Comunicação direta e eficiente: Ao evitar servidores intermediários, o agente chama o serviço diretamente o que reduz latência, overhead e complexidade.

• Compatibilidade universal: UTCP suporta diversos protocolos HTTP, WebSockets, gRPC, CLI tornando-o aplicável mesmo em ambientes heterogêneos.

Como o UTCP funciona (de forma prática)

O padrão define três componentes principais:

• Manuais

São documentos JSON padronizados que descrevem todas as ferramentas disponíveis, suas entradas, saídas, a forma de chamá-las e requisitos de autenticação.

• Ferramentas

Definições específicas de cada funcionalidade que o agente pode invocar com seu nome, parâmetros e esquema de resposta.

• Provedores

Os canais de comunicação (HTTP, CLI, WebSockets, etc.) que permitem ao agente falar diretamente com a ferramenta.

O fluxo segue três fases:

Descoberta: O agente busca o manual UTCP (ex. em /utcp).

Comunicação direta: O agente chama o endpoint nativo da ferramenta, conforme descrito no manual.

Processamento do resultado: A resposta é recebida na forma nativa e usada pelo agente sem transformação intermediária.

Esse processo elimina intermediários e centraliza a descoberta e a chamada de ferramentas em um único padrão leve.

O problema que o UTCP resolve

Hoje, a integração entre IA e ferramentas geralmente envolve:

• APIs adaptadas especificamente para IA
• servidores intermediários (middleware)
• duplicação de lógica de autenticação
• aumento de latência
• maior complexidade operacional

Protocolos como MCP, por exemplo, introduzem uma camada adicional de servidor, o que pode ser útil para governança, mas também cria acoplamento e custo.

O UTCP propõe o caminho oposto:

• menos infraestrutura
• menos abstração
• mais proximidade com a ferramenta real

Principais características do UTCP

1. Chamada direta de ferramentas

O agente chama a ferramenta usando o protocolo original, sem tradução intermediária.

Isso reduz:

• latência;
• pontos de falha;
• dependência de infraestrutura extra.

2. Suporte a múltiplos protocolos

O UTCP não se limita a HTTP. Ele pode descrever ferramentas baseadas em:

• REST APIs
• WebSocket
• SSE (streaming)
• CLI (linha de comando)
• gRPC
• outros protocolos customizados

Isso o torna extremamente flexível para ambientes heterogêneos.

3. Integração com padrões existentes

O protocolo pode reaproveitar especificações já conhecidas, como:

• OpenAPI
• definições de comandos CLI
• contratos já documentados

Ou seja, não exige “recriar” APIs para IA.

4. Open Source e extensível

O UTCP é aberto e orientado à comunidade, permitindo:

• auditoria do protocolo;
• extensões customizadas;
• adaptação a diferentes domínios (enterprise, edge, on-premise).

Segurança: ponto crítico (e responsabilidade do implementador)

Um aspecto importante: UTCP não é um sandbox de segurança por si só.

O próprio projeto deixa claro que:

• segurança depende de boas práticas de implementação;
• chamadas CLI precisam ser extremamente bem controladas;
• autenticação, autorização e rate limit continuam sendo responsabilidade da ferramenta.

Em outras palavras:

O UTCP não remove riscos ele não adiciona riscos extras, desde que usado corretamente.

Para ambientes críticos, recomenda-se:

• escopo mínimo de permissões;
• isolamento de execução;
• auditoria e logging;
• restrições claras para ferramentas locais.

Ao contrário de abordagens que centralizam autenticação no servidor intermediário, o UTCP herda a segurança do próprio serviço integrado:

• Credenciais e tokens são usados como fariam usuários humanos;

• Controle de acesso se mantém conforme já está implementado;

• Logging e auditoria podem usar os mecanismos nativos do serviço.

UTCP vs MCP: não são concorrentes diretos

Enquanto o MCP se baseia em servidores que:

• ficam entre o agente e a ferramenta;

• gerenciam autenticação e tradução;

• exigem manutenção contínua,

o UTCP é construído para ser simples, direto e sem camadas extras. O que isso significa na prática:

• sem proxy = menor latência e menos custo operacional;

• sem necessidade de reimplementar autenticação;

Embora muitas comparações sejam feitas, UTCP e MCP resolvem problemas diferentes.

Aspecto	UTCP	MCP
Servidor intermediário	Não	Sim
Latência	Menor	Maior
Infraestrutura	Mínima	Mais complexa
Governança central	Limitada	Forte
Flexibilidade	Alta	Média
Uso ideal	Integração direta	Ambientes altamente controlados

Em muitos cenários, UTCP e MCP podem coexistir, dependendo do nível de controle e abstração desejado.

Onde o UTCP faz mais sentido

O UTCP é especialmente interessante para:

• plataformas de agentes autônomos
• integrações enterprise com APIs já existentes
• ambientes on-premise e edge
• sistemas que precisam de alto desempenho
• times que querem evitar lock-in de infraestrutura

Por outro lado, pode não ser ideal para:

• ambientes que exigem governança central rígida;
• organizações que preferem tudo mediado por um único servidor controlador.

Limitações e contras do uso do UTCP

Apesar de o UTCP (Universal Tool Calling Protocol) trazer ganhos claros de simplicidade e desempenho, ele não é uma bala de prata. Sua filosofia de “chamada direta” implica trade-offs importantes que precisam ser considerados.

1 - Responsabilidade total de segurança fica com o implementador

O UTCP não impõe uma camada de segurança própria.
Isso significa que:

• Não há sandbox automático
• Não há isolamento de execução por padrão
• Não há política centralizada de autorização

Em protocolos como MCP, parte desse controle pode ser centralizado no servidor intermediário. No UTCP, tudo depende da maturidade da API existente.

2 - Risco elevado ao expor ferramentas locais (CLI)

Um dos recursos mais poderosos do UTCP — suporte a CLI — também é um dos mais perigosos.

Sem isolamento adequado:

• comandos podem ser encadeados;
• variáveis de ambiente podem ser expostas;
• arquivos sensíveis podem ser acessados.

Consequência

UTCP não deve ser usado ingenuamente para:

• shells de produção;
• servidores críticos;
• máquinas com permissões amplas.

3 - Complexidade deslocada, não eliminada

O UTCP reduz complexidade arquitetural, mas pode aumentar complexidade operacional:

• Cada API precisa estar bem documentada
• Esquemas de entrada/saída precisam ser claros
• Erros precisam ser semanticamente corretos

Caso contrário:

• agentes falham silenciosamente;
• resultados inconsistentes aparecem;
• debugging se torna difícil.

4 - Ecossistema ainda jovem

Apesar do crescimento:

• UTCP ainda não é um padrão amplamente adotado;
• há poucos cases enterprise públicos;
• ferramentas e SDKs ainda estão amadurecendo.

Risco

• mudanças no protocolo;
• ajustes de compatibilidade;
• necessidade de manutenção contínua.

5 - Não substitui completamente MCP ou Function Calling

UTCP não elimina a necessidade de:

• Function Calling para casos simples;
• MCP em ambientes com controle rígido;
• Orquestradores de workflow complexos.

Mão na massa

Vou desenvolver um exemplo simples o objetivo é simular uma situação em que já existem uma ou várias APIs e precisamos integrá-las a uma LLM ou SLM. Foi usada dotnet 10 C# porém poderia ser usada qualquer linguagem de programação, para a interação com LLM optei usar da OpenAI por dar suporte a ferramentas.

Foi utilizada uma abordagem de descoberta de ferramentas ou manual usando GET/api/v1/utcp.

{
  "manual_version": "1.0.0",
  "utcp_version": "1.1.0",
  "name": "Weather API",
  "description": "API para informações e previsões meteorológicas",
  "tools": [
    {
      "name": "get_current_weather",
      "description": "Obter o clima atual para uma localização específica",
      "tags": [
        "clima",
        "atual",
        "temperatura"
      ],
      "inputs": {
        "type": "object",
        "properties": {
          "location": {
            "type": "string",
            "description": "Nome da cidade ou coordenadas (por exemplo, Londres ou 51.5074,-0.1278)",
            "enum": null,
            "minimum": null,
            "maximum": null
          },
          "units": {
            "type": "string",
            "description": "Unidades de temperatura",
            "enum": [
              "celsius",
              "fahrenheit"
            ],
            "minimum": null,
            "maximum": null
          }
        },
        "required": [
          "location"
        ]
      },
      "output": {
        "type": "object",
        "description": "Informações do clima atual"
      },
      "average_response_size": 512,
      "tool_call_template": {
        "call_template_type": "http",
        "url": "https://localhost:7247/api/v1/weatherforecast/api/v1/current",
        "http_method": "GET",
        "headers": null,
        "query_params": {
          "location": "${location}",
          "units": "${units}"
        },
        "body": null
      }
    },
    {
      "name": "get_forecast",
      "description": "Obter a previsão do tempo para os próximos dias",
      "tags": [
        "clima",
        "previsão",
        "prognóstico"
      ],
      "inputs": {
        "type": "object",
        "properties": {
          "location": {
            "type": "string",
            "description": "Nome da cidade",
            "enum": null,
            "minimum": null,
            "maximum": null
          },
          "days": {
            "type": "integer",
            "description": "Número de dias (1-7)",
            "enum": null,
            "minimum": 1,
            "maximum": 7
          }
        },
        "required": [
          "location",
          "days"
        ]
      },
      "output": {
        "type": "array",
        "description": "Array de previsões diárias"
      },
      "average_response_size": 2048,
      "tool_call_template": {
        "call_template_type": "http",
        "url": "https://localhost:7247/api/v1/weatherforecast/api/v1/forecast",
        "http_method": "GET",
        "headers": null,
        "query_params": {
          "location": "${location}",
          "days": "${days}"
        },
        "body": null
      }
    }
  ],
  "auth": null
}

A estrutura é usada para alimentar um LLM com informações sobre como funcionam nossas APIs. Claro, aqui é apenas uma demonstração; é possível melhorar e deixá-la mais enxuta, até mesmo para consumir menos tokens.

O código abaixo mostra a parte de obtenção das ferramentas habilitadas e a integração com um LLM, que, por meio da ferramenta, escolhe aquela que melhor atende à pergunta. Feita essa descoberta, a API correspondente é chamada e, com o retorno, a resposta é elaborada.

using API.Models;
using Microsoft.Extensions.Options;
using OpenAI.Chat;
using System.Text.Json;

namespace API.Services;

public interface IChatService
{
    Task<string> SendMessageAsync(string userMessage);
}

public class ChatService : IChatService
{
    private readonly ChatClient _chat;
    private readonly IUtcpService _utcpService;
    private readonly UTCPSettings _utcpSetting;

    public ChatService(IUtcpService utpcService, IOptions<OpenAISettings> settings, IOptions<UTCPSettings> utcpSetting)
    {
        _utcpService = utpcService;
        _chat = new ChatClient(
            model: settings.Value.Model,
            apiKey: settings.Value.ApiKey
        );
        _utcpSetting = utcpSetting.Value;
    }

    public async Task<string> SendMessageAsync(string userMessage)
    {
        var messages = new List<ChatMessage>
        {
            new SystemChatMessage("Você é um assistente que usa ferramentas quando necessário."),
            new UserChatMessage(userMessage)
        };

        foreach (var manualUrl in _utcpSetting.ManualUrls)
        {
            try
            {
                await _utcpService.DiscoverToolsAsync(manualUrl);
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Failed to discover tools: {ex.Message}");
                throw;
            }
        }

        var options = new ChatCompletionOptions();

        // Add UTCP tools discovered from the manual
        foreach (var tool in _utcpService.GetToolsForOpenAI())
        {
            options.Tools.Add(tool);
        }

        var response = await _chat.CompleteChatAsync(messages, options);
        var assistantMessage = response.Value;

        // Handle tool calls
        if (assistantMessage.ToolCalls.Count > 0)
        {
            var toolCall = assistantMessage.ToolCalls[0];

            // Parse arguments from OpenAI
            var argsJson = JsonSerializer.Deserialize<JsonElement>(
                toolCall.FunctionArguments.ToString()
            );

            // Execute UTCP tool
            var toolResult = await _utcpService.ExecuteAsync(
                toolCall.FunctionName,
                argsJson
            );

            // Add assistant message with tool call
            messages.Add(new AssistantChatMessage(assistantMessage));

            // Add tool result
            messages.Add(new ToolChatMessage(
                toolCall.Id,
                JsonSerializer.Serialize(toolResult)
            ));

            // Get final response from OpenAI
            var finalResponse = await _chat.CompleteChatAsync(messages, options);
            return finalResponse.Value.Content[0].Text;
        }

        return assistantMessage.Content[0].Text;
    }
}

Vamos ao teste:

1° - "Qual a temperatura da cidade de Vitória?"

Chamou: GET/api/v1/weatherforecast/api/v1/current

Resposta:

{
  "response": "A temperatura atual em Vitória é de 22,5 °C, com condições de céu parcialmente nublado. A umidade está em 65% e a velocidade do vento é de 12,5 km/h vindo do noroeste."
}

2° - "Qual foi a temperatura da cidade de Vitória para próximos 3 dias?"

Chamou: GET/api/v1/weatherforecast/api/v1/forecast

Resposta:

{
   "response":"Aqui está a previsão do tempo para Vitória nos próximos 3 dias:\n\n- **25 de dezembro**: \n  - Temperatura máxima: 25°C \n  - Temperatura mínima: 15°C \n  - Condições: Ensolarado \n  - Chance de precipitação: 0%\n\n- **26 de dezembro**: \n  - Temperatura máxima: 26°C \n  - Temperatura mínima: 16°C \n  - Condições: Nublado \n  - Chance de precipitação: 10%\n\n- **27 de dezembro**: \n  - Temperatura máxima: 27°C \n  - Temperatura mínima: 17°C \n  - Condições: Ensolarado \n  - Chance de precipitação: 20% \n\nSe precisar de mais informações, é só avisar!"
}

Impacto no futuro dos agentes de IA

O UTCP aponta para uma tendência clara: agentes de IA cada vez mais próximos da infraestrutura real.

Em vez de “simular” chamadas via camadas artificiais, os agentes passam a operar como atores de primeira classe, usando as mesmas interfaces que humanos e sistemas tradicionais.

Isso abre espaço para:

• agentes mais autônomos;
• menor custo operacional;
• maior interoperabilidade entre sistemas.

Conclusão

O UTCP é um protocolo simples na ideia, mas profundo nas implicações.
Ele não tenta substituir tudo, nem ser uma solução mágica, mas propõe algo fundamental: menos abstração desnecessária entre IA e ferramentas reais.

Ele funciona melhor quando:

• APIs já são bem projetadas;
• segurança já está resolvida;
• o time entende os riscos;
• simplicidade e desempenho são prioridades.

Em ambientes imaturos ou excessivamente regulados, o UTCP pode amplificar problemas existentes, em vez de resolvê-los.

Se adotado com responsabilidade, o UTCP pode se tornar um padrão importante na próxima geração de sistemas baseados em agentes, especialmente em ambientes técnicos, enterprise e distribuídos.

O projeto completo: Github

Referência:

UTCP
GitHub UTCP