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.

Além do código apresentado no GitHub, poderíamos utilizar uma abordagem de descoberta de ferramentas usando /.well-known/utcp.json. Dessa forma, o processo ficaria mais abstraído e reutilizável, permitindo variação e evolução das ferramentas sem acoplamento direto ao código.

{
  "protocol": "utcp",
  "version": "1.0",
  "tools": [
    {
      "name": "get_weather",
      "description": "Obtém o clima atual de uma cidade",
      "method": "GET",
      "endpoint": "/weather",
      "input_schema": {
        "type": "object",
        "properties": {
          "city": {
            "type": "string",
            "description": "Nome da cidade"
          }
        },
        "required": ["city"]
      }
    }
  ]
}

app.MapGet("/.well-known/utcp.json", () =>
{
    return Results.Json(new
    {
        protocol = "utcp",
        version = "1.0",
        tools = new[]
        {
            new
            {
                name = "get_weather",
                description = "Obtém o clima atual de uma cidade",
                method = "GET",
                endpoint = "/weather",
                input_schema = new
                {
                    type = "object",
                    properties = new
                    {
                        city = new
                        {
                            type = "string",
                            description = "Nome da cidade"
                        }
                    },
                    required = new[] { "city" }
                }
            }
        }
    });
});

1 - Contexto do UTCP

O UTCP propõe que um LLM ou assistente possa chamar ferramentas externas de forma padronizada, descrevendo:

• Nome da ferramenta (functionName / toolName)
• Descrição da função (functionDescription)
• Parâmetros esperados (functionParameters)
• Execução e retorno padronizado (JSON ou objeto serializável)

O objetivo é que qualquer ferramenta que siga esse padrão possa ser chamada dinamicamente pelo modelo, independentemente de backend ou linguagem.

2 - Estrutura do código

a) Endpoints

Dois grupos:

/api/v1/chats -> ChatEndpoint
/api/v1/weatherforecast -> WeatherEndpoint

• ChatEndpoint recebe mensagens do usuário, chama ChatService e retorna a resposta.
• WeatherEndpoint simula uma ferramenta (uma API de previsão do tempo) que retorna dados JSON sobre a cidade.

Cada ferramenta ou recurso exposto como API segue o conceito UTCP de ser acessível via chamadas REST.

b) ToolService

public static ChatTool[] GetTools()

Define a lista de ferramentas disponíveis:

• get_weather com parâmetros (city: string)
• Descrição clara
• Parâmetros estruturados em JSON

Isso é exatamente o que o UTCP sugere: definir uma lista de ferramentas com seus metadados que podem ser chamadas dinamicamente pelo modelo.

c) ChatService

Fluxo do SendMessageAsync:

1. Monta mensagens do chat:

• SystemChatMessage define comportamento (“usa ferramentas quando necessário”)
• UserChatMessage é a mensagem do usuário

1. Prepara ChatCompletionOptions com todas as ferramentas (options.Tools.Add(tool))

2. Chama o LLM (_chat.CompleteChatAsync) para obter resposta.

3. Verifica se houve ToolCall:

• Se houver, extrai o JSON (FunctionArguments)
• Executa a ferramenta via _utpcService.ExecuteAsync
• Adiciona resposta da ferramenta ao histórico de chat (ToolChatMessage)
• Faz nova chamada ao LLM para gerar a resposta final

Fluxo é exatamente o padrão UTCP:

• LLM decide quando chamar a ferramenta
• Argumentos são passados em JSON
• Resultado da ferramenta é retornado e reinserido no chat
• Modelo produz a resposta final baseada no resultado da ferramenta

d) UtpcService

public class UtpcService(HttpClient http): IUtpcService
{
    public async Task<object> ExecuteAsync(string toolName, JsonElement arguments)
    {
        if (toolName != "get_weather")
            throw new Exception("Tool não suportada");

        var city = arguments.TryGetProperty("city", out var cityProp)
            ? cityProp.GetString()
            : "Unknown";

        var response = await http.GetFromJsonAsync<object>($"api/v1/weatherforecast/{city}");
        return response!;
    }
}

• Implementa execução real da ferramenta com base no nome e nos argumentos.
• Retorna objeto serializável (JSON) — compatível com UTCP.
• Suporta adição de mais ferramentas futuramente.

Abordagem do UTCP que foi usada é a chamada de “Tool Calling via LLM com execução externa padronizada”, que é a abordagem principal do protocolo.

1. Definição de ferramentas com metadados

• No seu ToolService, cada ferramenta (ChatTool) tem:

  • functionName → nome da ferramenta
  • functionDescription → descrição do que faz
  • functionParameters → parâmetros esperados em JSON

• Isso é diretamente inspirado no UTCP, que exige que ferramentas sejam registradas com metadados para que o LLM saiba como chamá-las.

1. Decisão do LLM sobre chamar a ferramenta

• No ChatService.SendMessageAsync, você primeiro envia a mensagem do usuário ao modelo.
• O modelo decide se precisa chamar uma ferramenta (ToolCalls.Count > 0).
• Essa é a abordagem central do UTCP: o LLM não só responde, mas também invoca ferramentas quando necessário.

1. Execução externa padronizada

• O _utpcService.ExecuteAsync executa a ferramenta com os argumentos JSON recebidos.
• O resultado é retornado em formato serializado para que o LLM continue a conversa.
• Esse fluxo é exatamente como o UTCP define: LLM → Tool → JSON → LLM.

1. Integração de resultados no histórico do chat

• Após executar a ferramenta, você adiciona a resposta como ToolChatMessage e faz uma nova chamada ao LLM.
• Isso segue o padrão UTCP de retorno padronizado, permitindo que o LLM interprete resultados e continue a conversa naturalmente.

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