Treg vs OpenConnector: diferenças e como escolher em 2026

Treg e OpenConnector já oferecem MCP, mas resolvem problemas diferentes de acesso, credenciais e execução. Esta comparação mostra como escolher entre registry de equipe com catálogo comercial e gateway de Actions para contas de usuários, sem transformar quantidade de integrações em critério suficiente.

A metodologia é documental: README, licenças, manifests, configuração, documentos de runtime e trechos de código dos dois repositórios fornecidos foram consultados em outubro de 2026. Não executamos ferramentas, testes ou benchmarks; os cenários de PME, agência e SaaS são propostas de arquitetura, não experiências operacionais atribuídas à Techify.

1. A escolha começa por quem possui a conta

Treg e OpenConnector diferem principalmente na unidade que organizam: o Treg reúne acesso comercial e ferramentas compartilhadas de equipe, enquanto o OpenConnector organiza Actions executáveis associadas a conexões de contas. Ambos escondem credenciais em determinados caminhos, mas não transformam automaticamente toda conta em recurso de uso livre.

A primeira tese da comparação é que propriedade da conta e contrato de execução devem vir antes do protocolo MCP. A pergunta para uma PME não é apenas qual projeto conversa com seu agente; é quem concede acesso, quem paga, quem pode revogar e qual identidade aparece no serviço externo. Essas respostas afetam o produto inteiro.

Como proposta para uma agência, uma ferramenta SEO contratada pela equipe pode favorecer o modelo de registry compartilhado. Como proposta para um SaaS, cada usuário conectando sua caixa de entrada pede identidade e autorização por conexão. Esses exemplos descrevem necessidades, não demonstram superioridade universal de nenhum projeto.

A Techify recomenda desenhar a jornada e o limite de confiança antes de selecionar conectores. O guia de harness e loop para processos com IA oferece uma base útil: ferramentas entram depois que a tarefa, a fonte e o critério de aprovação estão claros, não para compensar um processo indefinido.

2. Registry fiel e gateway de Actions têm contratos distintos

O Treg prioriza registrar ferramentas e encaminhar requisições upstream com autenticação injetada, além de oferecer descoberta e acesso comercial catalogado. O OpenConnector prioriza definições de Actions com schemas, requisitos e executores, expondo operações por diferentes clientes. Essa diferença determina quanto contrato a aplicação precisa conhecer e manter.

No modelo de relay, o consumidor continua lidando com o comportamento da API upstream. No modelo de Actions, existe um contrato intermediário de entrada e saída que precisa acompanhar o serviço conectado. Nenhum caminho elimina mudança de fornecedor; eles distribuem a responsabilidade de adaptação em lugares diferentes da arquitetura.

OpenConnector também possui proxy de provedor, e Treg possui metadados e superfícies estruturadas. Por isso, a comparação não deve afirmar que um só encaminha bytes e o outro nunca faz proxy. O ponto é identificar o contrato predominante para a tarefa escolhida e os limites do caminho específico que será usado.

O desenho de APIs e webhooks para automação ajuda a formular esse requisito. Para uma rotina de pedidos, registre campos necessários, semântica de erro e estado final esperado. Uma resposta JSON válida de qualquer conector não significa que o pedido foi processado corretamente ou sem duplicação.

3. Custódia de credenciais não é autorização de negócio

Credenciais protegidas pelo runtime reduzem exposição ao agente, mas a aplicação ainda precisa impor acesso à conta certa e à operação certa. Treg organiza recursos por equipe, papéis e controles de ferramenta; OpenConnector oferece conexões e políticas de execução, incluindo grants de conexão em tokens persistentes. Isso não equivale a autorização universal já pronta.

No Treg, a CLI local é o padrão e recebe o material necessário no ambiente do runner cliente. O isolamento por usuário dedicado depende da preparação; --server é o caminho que mantém a chave fora da máquina cliente. Portanto, esconder a chave da pessoa operadora e evitar sua presença no dispositivo são promessas diferentes.

No OpenConnector, uma lista allowedConnections não vazia pode restringir um token persistente a IDs estáveis. Lista vazia ou omitida na criação não restringe contas, e bootstrap/JWT não possuem esse grant armazenado. Em um SaaS, a seleção autorizada precisa vir do backend autenticado, não de um alias arbitrário sugerido pelo agente.

Uma proposta de avaliação usa 2 contas e 1 operação de leitura para conferir separação inicial. O objetivo é verificar recusa de troca de conta, revogação e omissão de identificador antes de permitir escrita. Esse conjunto é um roteiro sugerido, não um experimento executado nesta análise.

4. Catálogos amplos não garantem cobertura pronta

O Treg declara milhares de endpoints e o OpenConnector anuncia mais de 1.000 provedores e 10.000 Actions. São números publicados pelos projetos, sem contagem ou validação independente nesta apuração. Eles não demonstram que todos os acessos estão habilitados, que todas as contas existem ou que a operação requerida funciona no runtime escolhido.

OpenConnector distingue schema catalogado de executor local, necessidade de credencial e Action sem autenticação. Treg diferencia oferta com ferramenta própria, segredo próprio, rota pública e conta da plataforma. Uma shortlist honesta precisa cruzar capacidade desejada, credencial disponível e caminho operacional, em vez de escolher pela maior cifra.

Treg tampouco roteia automaticamente entre todos os endpoints. A escolha normal permanece com o usuário; rotas treg.<capability> são uma exceção explícita para delegar seleção. Trocar de conta no mesmo endpoint por overflow também não deve ser confundido com escolher qualquer fornecedor alternativo para qualquer tarefa.

A posição da Techify é comparar uma lista pequena de operações indispensáveis e classificar cada uma como confirmada documentalmente, pendente de execução ou inadequada ao contrato. Isso impede que a equipe transforme uma descrição comercial em promessa de entrega. A contagem de catálogo pode ajudar descoberta, mas não deve ser usada como acordo de nível de serviço.

5. Self-host muda responsabilidade, não herda contas hosted

Self-host significa operar o software e seu estado, não receber automaticamente as contas comerciais ou os aplicativos OAuth do serviço hosted. No Treg, o registry privado precisa das credenciais e direitos de uso que sustentam as chamadas. No OpenConnector, OAuth nativo exige aplicativos próprios registrados nos provedores, com os callbacks e escopos correspondentes.

OOMOL hosted gerencia aplicativos OAuth para os provedores suportados, e OpenConnector documenta conexão SaaS com referências remotas mediante configuração de projeto. Esse caminho não é igual a guardar tokens locais nem representa acesso automático a toda conta. A arquitetura pode combinar responsabilidades, mas elas devem estar descritas explicitamente.

O Treg tem servidor Python, manifest exigindo versão a partir de 3.12 e abaixo de 3.14, SQLite para desenvolvimento e Postgres documentado em produção; o dashboard usa build Node 22.12+. OpenConnector documenta Node 22+, SQLite default e PostgreSQL 15+, além de Workers com D1 e R2 ou KV para arquivos temporários.

Uma PME com operação Linux consolidada pode preferir reduzir componentes novos. Um produto já na Cloudflare pode avaliar o destino Workers do OpenConnector, sem presumir performance ou paridade universal. O guia de arquitetura de agentes na edge reforça a necessidade de combinar runtime, persistência e conectividade segundo o workload.

6. Preço e licença podem eliminar uma opção cedo

BYOK no Treg não é medido pelo saldo da plataforma, mas continua sujeito à cobrança e quota do provedor. Chamadas com contas comerciais da plataforma podem usar saldo pré-pago conforme a oferta. Não há preço OOMOL verificado nesta apuração para comparar valores hosted, créditos ou mensalidades com números inventados.

A segunda tese da comparação é que licença e responsabilidade OAuth podem eliminar uma arquitetura antes de qualquer discussão sobre ergonomia. Treg usa Apache 2.0 com termos adicionais; o documento restringe serviços hosted, managed ou embedded para terceiros nas condições indicadas. Não deve ser descrito como Apache irrestrita.

A restrição do arquivo LICENSE é mais ampla que o resumo sobre registry concorrente no README. Uso interno é expressamente permitido, mas embutir ou redistribuir a solução em oferta comercial a terceiros requer avaliação e eventual autorização escrita. Usar a API hosted é uma modalidade distinta, que também precisa respeitar condições comerciais e dos provedores.

OpenConnector aplica Apache-2.0 padrão ao código próprio, salvo indicações específicas, sem conceder direitos sobre marcas, produtos ou APIs de terceiros. Para um SaaS multiusuário, essa diferença é relevante, mas não elimina revisão jurídica, privacidade ou consentimento. Licença de código e direito de acessar dados de usuários são questões separadas.

7. A matriz compara arquitetura, não declara vencedor universal

A comparação documental favorece critérios verificáveis: unidade de integração, origem da credencial, localização de execução, deploy, cobrança e licença. A tabela abaixo sintetiza essas diferenças sem atribuir notas, tempos de resposta ou desempenho que não foram medidos. Ela é um instrumento de seleção, não um ranking de qualidade global.

A matriz também expõe uma falsa economia comum: reduzir esforço de conexão pode aumentar esforço de governança se a equipe libera credenciais amplas. Uma proposta financeira deve somar consumo de APIs, hospedagem, trabalho OAuth, atendimento a contas expiradas e recuperação de falhas. Nenhum número de catálogo substitui essa soma.

A Techify recomenda registrar por escrito os requisitos que desclassificam uma opção. Se a chave não pode chegar ao cliente, CLI local não atende essa promessa. Se a oferta distribui software comercialmente a terceiros, a licença precisa permitir esse desenho. Se a Action necessária está apenas no catálogo, não inclua sua execução como entrega concluída.

8. Um piloto deve validar identidade e recuperação antes de escrita

Um piloto comparativo começa com a mesma tarefa e o mesmo resultado esperado, não com demonstrações diferentes de cada projeto. Como proposta, use consulta de dados e preparação de rascunho, mantendo envio externo ou gasto sob autorização humana. Essa delimitação torna os critérios comparáveis sem depender de um benchmark sintético.

Defina 5 critérios de aceite para o cenário proposto: conta correta, operação autorizada, segredo protegido, custo identificável e recuperação sem repetição indevida. O número descreve um checklist editorial, não uma avaliação já realizada. Cada critério precisa de evidência antes da expansão para usuários ou clientes.

OpenConnector documenta idempotência HTTP opcional com replay por 24 horas, mas não exatamente uma vez no provedor e não a mesma chave no MCP. No Treg, preservação upstream e escolha de rotas exigem verificar o contrato do caminho usado. Em ambos, timeout depois de escrita deve ser tratado como estado potencialmente incerto, não como autorização para repetir.

Antes de conectar contas de produção, defina quem pode aprovar escritas e como investigar uma resposta perdida. A conveniência do conector não desfaz uma ação enviada ao provedor.

Conclusão: escolha a fronteira que corresponde ao seu produto

Treg tende a ser um candidato para compartilhar ferramentas de equipe e acessar ofertas comerciais, com atenção ao modo CLI e aos termos adicionais. OpenConnector tende a ser um candidato para produtos que conectam contas de usuários por Actions, com atenção ao OAuth, aos executores disponíveis e à autorização imposta pelo backend.

O próximo passo não é migrar tudo: é selecionar uma tarefa, conferir contrato, conta e licença e planejar uma avaliação reversível. Para transformar essa decisão em arquitetura aplicável à sua operação, converse com a Techify sobre o escopo do piloto e os limites que precisam continuar fora das decisões do agente.