TunnelHub MCP

Conecte clientes MCP ao TunnelHub para investigar e administrar automações, tabelas, sistemas, pacotes e usuários, além de consultar execuções, logs, traces, estatísticas de uso e API Gateway usando o mesmo fluxo de autenticação do frontend.

Este MCP é especialmente útil para:

• Acompanhar automações do TunnelHub
• Localizar e resumir execuções
• Imprimir logs e traces
• Analisar falhas parciais e dependências externas
• Trabalhar com ambientes da empresa atual

✨ O que você pode fazer

• Autenticar no TunnelHub pelo navegador
• Listar ambientes disponíveis
• Listar, criar, atualizar, excluir e executar automações
• Solicitar, acompanhar, aprovar e reprovar transportes de automações entre ambientes
• Listar, consultar, criar, atualizar e excluir usuários da empresa atual
• Listar, criar, atualizar e excluir sistemas e pacotes do ambiente atual
• Administrar tabelas de de/para e seus itens
• Administrar metadados, schema e linhas de tabelas de apoio
• Consultar APIs, clients, usage plans, API keys e logs do API Gateway
• Consultar estatísticas de uso e consumo da empresa atual
• Localizar execuções por intervalo de tempo
• Resumir uma execução completa
• Consultar logs e traces de uma execução
• Ler informações básicas da empresa atual

✅ Pré-requisitos

Você vai precisar de:

• Node.js 22+
• Acesso a uma empresa do TunnelHub
• Um cliente compatível com MCP via stdio

Clientes recomendados:

• OpenCode
• Claude Desktop
• Cursor
• Outros clientes MCP compatíveis com stdio

🚀 Comece em 2 minutos

A forma principal de uso é via npx com o bin explícito:

npx -y @tunnelhub/mcp@latest

Se você estiver desenvolvendo localmente:

pnpm install
pnpm build
node dist/index.js

Se esta for sua primeira vez usando o MCP do TunnelHub, siga este fluxo:

1. Faça login no TunnelHub
   • não é necessário informar empresa nem ambiente
2. Liste meus tenants e escolha com switch_tenant_tunnelhub (um único tenant é selecionado automaticamente, salvo exigência de SAML)
3. Liste os ambientes disponíveis e selecione o ambiente de trabalho
4. Liste as automações ativas

Você não precisa decorar o nome das tools. Pode pedir em linguagem natural, e o cliente MCP deve escolher a ferramenta certa.

🔌 Configuração oficial por cliente

OpenCode

A forma mais estável de configurar no OpenCode é via opencode.json.

Se preferir, você também pode usar opencode mcp add, que abre um fluxo interativo para adicionar o servidor MCP.

Exemplo usando opencode.json:

Exemplo completo:

{
  "mcp": {
    "tunnelhub": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@tunnelhub/mcp@latest"
      ],
      "enabled": true,
      "environment": {
        "OAUTH_CALLBACK_PORT": "3333"
      }
    }
  }
}

Exemplo usando build local:

{
  "mcp": {
    "tunnelhub": {
      "type": "local",
      "command": [
        "node",
        "/caminho/para/mcp/dist/index.js"
      ],
      "enabled": true,
      "environment": {
        "OAUTH_CALLBACK_PORT": "3333"
      }
    }
  }
}

Claude Desktop

Exemplo de configuração no claude_desktop_config.json:

{
  "mcpServers": {
    "tunnelhub": {
      "command": "npx",
      "args": ["-y", "@tunnelhub/mcp@latest"],
      "env": {
        "OAUTH_CALLBACK_PORT": "3333"
      }
    }
  }
}

Exemplo usando build local:

{
  "mcpServers": {
    "tunnelhub": {
      "command": "node",
      "args": ["/caminho/para/mcp/dist/index.js"],
      "env": {
        "OAUTH_CALLBACK_PORT": "3333"
      }
    }
  }
}

Cursor

Use o mesmo comando stdio do cliente MCP:

{
  "mcpServers": {
    "tunnelhub": {
      "command": "npx",
      "args": ["-y", "@tunnelhub/mcp@latest"],
      "env": {
        "OAUTH_CALLBACK_PORT": "3333"
      }
    }
  }
}

Exemplo usando build local:

{
  "mcpServers": {
    "tunnelhub": {
      "command": "node",
      "args": ["/caminho/para/mcp/dist/index.js"],
      "env": {
        "OAUTH_CALLBACK_PORT": "3333"
      }
    }
  }
}

Outros clientes MCP compatíveis com stdio

Se o cliente aceitar um comando local, use:

npx -y @tunnelhub/mcp@latest

Ou, em desenvolvimento:

node /caminho/para/mcp/dist/index.js

🔐 Como funciona o login

No primeiro uso, chame a ferramenta de login do MCP.

Fluxo esperado:

1. O cliente chama login_tunnelhub
2. O MCP abre o navegador local
3. Você faz login e autoriza o MCP na página dedicada do TunnelHub
4. O MCP consulta os tenants acessíveis; se houver apenas um e ele não exigir novo login SAML, seleciona-o automaticamente
5. Escolha ou troque o tenant com switch_tenant_tunnelhub; usuário e ambientes são recarregados no backend
6. A identidade fica salva localmente, independente do tenant e do ambiente selecionados

Ferramentas básicas de sessão:

• login_tunnelhub
• current_session_tunnelhub
• list_sessions_tunnelhub
• list_my_tenants_tunnelhub
• switch_tenant_tunnelhub
• list_environments_tunnelhub
• switch_environment_tunnelhub
• logout_tunnelhub

Identidade compartilhada e migração

O JWT humano identifica a pessoa, sem tenant ou lista de ambientes. O MCP envia TenantId em todas as chamadas humanas contextualizadas e EnvironmentId quando há ambiente selecionado. A descoberta inicial de tenants autentica somente a identidade, sem inventar um tenant. SystemAdmin e SystemSupport recebem do backend a lista global; o MCP não calcula permissões por papel.

Refresh tokens continuam gerenciados pelo Cognito, usando o app client que emitiu o token, inclusive no SAML. O app client OAuth público pode não emitir refresh token com os escopos padrão; nesse caso a sessão pede novo login quando expirar. Login e refresh não aceitam environment_id. Não há armazenamento próprio de grants. As respostas das tools não incluem tokens.

Sessões anteriores à migração exigem novo login. Usuários locais migrados podem precisar redefinir senha; usuários SAML entram novamente pelo IdP. Um tenant com requiresSamlLogin exige login_tunnelhub com seu tenantId, seguido da seleção do tenant. A associação de identidades SAML permanece no frontend/backend, nunca por comparação local de emails.

Erros LOGIN_REQUIRED indicam sessão expirada, inválida ou anterior à migração. ACCESS_DENIED indica recusa do backend (403): atualize a lista de tenants e confira a exigência de SAML. Falhas temporárias de refresh retornam REFRESH_FAILED sem apagar a sessão.

O MCP usa o Managed Login v2 do Cognito por padrão, com Authorization Code + PKCE; nesse modo consulta /tenant-service/auth/public-config e usa o discoveryUrl para obter os endpoints OIDC. Defina TUNNELHUB_MANAGED_LOGIN_OAUTH=false somente para forçar a ponte de login do frontend. O hint opcional de tenantId/accountName mantém o roteamento SAML existente. Contratos e dependências: autenticação compartilhada.

💬 Exemplos de perguntas

Você pode pedir coisas como:

• Faça login no TunnelHub
• Faça login no TunnelHub para a empresa 4success
• Qual sessão está ativa?
• Liste os ambientes disponíveis
• Liste as automações ativas
• Liste os sistemas HTTP do ambiente atual
• Mostre o system 1234
• Crie um sistema HTTP chamado ERP no ambiente atual, com URL https://erp.example.com e sem autenticação
• Atualize a descrição do system 1234
• Exclua o system 1234; confirmo que referências existentes podem ser quebradas
• Liste os pacotes do ambiente atual
• Mostre o package abc
• Crie o pacote Financeiro com a descrição Integrações financeiras
• Atualize os parâmetros do package abc usando somente os valores que eu informar
• Exclua o package abc; confirmo que dependências podem parar de funcionar
• Liste os usuários da empresa atual
• Mostre o usuário user-123
• Crie Ada Lovelace como TenantUser usando [email protected]; confirmo o envio do convite
• Atualize apenas o timezone do usuário user-123 para UTC; confirmo a alteração
• Exclua o vínculo do usuário user-123 com este tenant; confirmo a remoção
• Liste as APIs do API Gateway
• Mostre a API 123abc
• Liste os clients de autenticacao
• Mostre o client xyz
• Liste os usage plans
• Liste as API keys
• Liste os logs da API 123abc
• Mostre o log 9988 da API 123abc no timestamp 1710345600
• Liste os logs globais do API Gateway no dia 2026-03-13
• Mostre as estatísticas da home deste mês
• Mostre as estatísticas da home de 2026-03-01 até 2026-03-31
• Mostre o consumo de execuções do tenant neste mês
• Mostre recargas e consumo do tenant para 2026-03-01
• Liste as tabelas de de/para do ambiente atual
• Busque a tabela de de/para CFOP
• Crie uma tabela de de/para CFOP no pacote abc
• Liste os itens da tabela de de/para 1234
• Me mostre o item abc da tabela de de/para 1234
• Adicione o de/para 5102 -> VENDA na tabela 1234
• Atualize o item abc da tabela 1234 para 5102 -> VENDA_INTERNA
• Exclua o item abc da tabela 1234; confirmo a exclusão permanente
• Exclua a tabela de de/para 1234; confirmo, mas não apague enquanto ela tiver itens
• Liste as tabelas de apoio do ambiente atual
• Mostre a tabela de apoio customer-cache
• Liste as linhas da tabela de apoio customer-cache filtrando document
• Exporte as linhas da tabela de apoio customer-cache
• Crie a tabela de apoio customer-cache com document como chave primária
• Atualize a descrição da tabela customer-cache sem alterar o schema
• Migre o schema de customer-cache removendo legacyCode; confirmo que os dados dessa coluna serão perdidos
• Insira uma linha em customer-cache com document 123 e active true
• Atualize a linha row-123 de customer-cache definindo active como false
• Exclua a linha row-123 de customer-cache; confirmo a exclusão permanente
• Crie uma automação ativa chamada Sincronizar clientes no pacote abc
• Atualize a retenção da automação auto-123
• Execute a automação auto-123 com este payload, sabendo que ela pode alterar sistemas externos
• Exclua a automação auto-123; confirmo a remoção permanente dos recursos de runtime
• Liste os transportes pendentes visíveis no ambiente atual
• Solicite o transporte da automação auto-123 para o ambiente env-qas com a mensagem Validada em desenvolvimento
• Aprove o transporte tr-123 da automação auto-123; confirmo o deploy e as alterações no ambiente de destino
• Reprove o transporte tr-123 da automação auto-123 com a justificativa Aguardando validação do schema; confirmo a reprovação
• Aprove o transporte tr-123 da automação auto-123 com force; confirmo o deploy e também a possível perda de dados das tabelas SQL incompatíveis no destino
• Ache a execução 9b696080439f no dia 2026-03-13
• Resuma a execução 019ce7f3-2707-740c-8692-9b696080439f
• Me mostre os traces com ERROR dessa execução
• Me mostre os logs dessa execução
• Essa execução teve sucesso degradado?
• Quais dependências externas falharam nessa execução?
• Só usando o MCP, me diga o que precisa ser corrigido nessa automação

✍️ Operações de escrita e segurança

• Exclusões de packages, systems, automações, tabelas e linhas exigem confirm: true. Em linguagem natural, deixe a confirmação e o recurso exato explícitos para o cliente MCP.
• Migrações de schema também exigem confirm: true, pois renomear ou remover colunas pode descartar dados permanentemente.
• Migrações preservam automaticamente a chave primária atual; a API não permite alterá-la.
• Updates, deletes e migrações de recursos principais fazem um preflight de existência antes da mutação. Updates e deletes de itens de de/para também validam que o item pertence à tabela informada.
• Uma tabela de de/para só pode ser excluída quando estiver vazia. O MCP recusa a operação enquanto houver itens; remova-os individualmente primeiro.
• Systems, packages, automações e tabelas podem ser referenciados por outros recursos. Revise as dependências antes de excluir. Em tabelas de apoio, force: true também remove referências das automações dependentes.
• A criação de systems valida parameters conforme o tipo e seus discriminadores, como databaseType, oracleConnectionType e authType. Updates aceitam patches parciais enquanto o tipo e o subtipo permanecem iguais; ao trocar qualquer um deles, envie a configuração completa da nova variante. Omita segredos já configurados somente em updates parciais da mesma variante.
• parameters de systems pode conter credenciais e outros segredos. Evite repeti-los em mensagens, logs ou exemplos.
• Em updates de package, changes.parameters substitui o array inteiro. Consulte o package e reenvie todas as entradas que devem permanecer; valores não são devolvidos pelas write tools.
• execute_automation_tunnelhub é não idempotente e pode produzir efeitos em serviços externos. delete_automation_tunnelhub pode remover de forma assíncrona agenda, revisões, função Lambda, role IAM e policies.
• Updates de automação enviam somente os campos informados. Quando changes.trigger é parcial, o MCP preserva UUID, tipo, autenticação, credenciais e demais propriedades omitidas a partir do preflight. Credenciais WEBHOOK podem ser parciais somente quando o modo de autenticação permanece igual; criação ou troca de modo exige todos os campos da autenticação escolhida.
• Para evitar substituições acidentais e lost updates, update_automation_tunnelhub temporariamente não aceita changes.notifications nem changes.limitedUsers.
• Quando presentes na resposta do backend, parameters, notifications e limitedUsers de automações são preservados integralmente. Somente trigger.credentials e chaves internas do DynamoDB são omitidos.
• Logs de ações preservam o histórico de parameters e notifications, mas removem trigger.credentials dos estados anterior e posterior.

Gestão de usuários

• As cinco tools de usuários operam somente na empresa da sessão ativa e exigem perfil TenantAdmin, SystemAdmin, SystemSupport ou SystemUser.
• create_user_tunnelhub deriva tenantId da sessão e usa o email como userName. A criação aceita somente TenantAdmin, TenantUser ou TenantLimitedUser, exige confirm: true e reutiliza a identidade existente pelo email normalizado; contas novas recebem convite pelo Cognito.
• update_user_tunnelhub envia somente os campos presentes em changes e exige confirm: true. O MCP aceita apenas nome, sobrenome, título, foto, conta Jira, ambientes, país, idioma e timezone. Use photoUrl: null para limpar a URL da foto armazenada; omitir o campo mantém o valor atual.
• role, status, userName, tenantId e identificadores Cognito não podem ser alterados pela tool. Email e username são somente leitura; atributos pessoais são globais e permissões de ambiente pertencem ao vínculo.
• delete_user_tunnelhub usa o endpoint unitário, exige confirm: true e faz preflight. O backend decide a autorização e as restrições de exclusão. A identidade Cognito e os vínculos com outros tenants são preservados.
• O status continua visível nas respostas, mas não é aceito como filtro porque o backend atual usa correspondência parcial e confunde ACTIVE com INACTIVE.
• O endpoint de exclusão em lote não é exposto porque aceita tenantId no corpo. Respostas MCP usam allowlist e omitem IDs de pools Cognito, chaves internas e quaisquer campos desconhecidos.

Transportes de automações

• list_automation_transports_tunnelhub lista solicitações de entrada e saída relacionadas ao ambiente ativo. Aceita paginação e filtros por status (PENDING, APPROVED ou REPROVED) e transportId.
• request_automation_transport_tunnelhub usa o ambiente ativo como origem e exige outro ambiente disponível como destino, além de uma requestMessage entre 5 e 5.000 caracteres. O MCP deriva o deploy de automation.headRevisionId e verifica se essa revisão existe; o chamador não escolhe um deploy arbitrário. A operação cria uma solicitação PENDING, mas ainda não altera nem implanta recursos no destino.
• A aprovação ou reprovação deve ser executada com o ambiente de destino ativo. Antes de qualquer revisão, o MCP confirma que a solicitação ainda está PENDING e pertence à automação informada. Antes de aprovar, também confirma que ela continua apontando para o mesmo head da origem; uma solicitação obsoleta ainda pode ser reprovada.
• approve_automation_transport_tunnelhub exige confirm: true. A aprovação cria metadados ausentes de package, systems e tabelas de de/para, mapeia systems já existentes, transporta somente a estrutura das tabelas SQL — sem copiar linhas —, cria ou atualiza a automação e dispara o deploy no destino. Itens das tabelas de de/para também não são copiados. Quando concluída, realiza a transição PENDING → APPROVED.
• reject_automation_transport_tunnelhub exige uma justificativa de pelo menos cinco caracteres e confirm: true. Ela não implanta os recursos transportados e conclui a transição PENDING → REPROVED.
• Uma aprovação pode deixar alterações parciais no destino se uma etapa posterior falhar. Ela não é idempotente: nunca tente novamente automaticamente. Primeiro inspecione automação, dependências, tabelas e deploy no ambiente de destino.
• force: true afeta somente tabelas SQL transportadas cujo schema conflita com o destino. Nesse caso, também é obrigatório informar confirmSqlTableDataLoss: true; a tabela incompatível pode ser recriada vazia e seus dados no destino podem ser perdidos.
• As respostas, inclusive na listagem, retornam automation.parameters, automation.notifications e automation.limitedUsers integralmente. Somente automation.trigger.credentials e chaves internas do DynamoDB são omitidos.
• A autorização para listar, solicitar ou revisar transportes é decidida pelo backend; o MCP não bloqueia operações com base em papéis armazenados na sessão.

Exemplo de aprovação com sobrescrita explícita de tabelas SQL incompatíveis:

{
  "automationId": "auto-123",
  "transportId": "tr-123",
  "reviewMessage": "Schema revisado e aprovado para substituição.",
  "force": true,
  "confirm": true,
  "confirmSqlTableDataLoss": true
}

🧰 Principais ferramentas disponíveis

Sessão

• login_tunnelhub
• current_session_tunnelhub
• list_sessions_tunnelhub
• list_my_tenants_tunnelhub
• switch_tenant_tunnelhub
• list_environments_tunnelhub
• switch_environment_tunnelhub
• logout_tunnelhub

Empresas

• list_tenants_tunnelhub
• get_tenant_tunnelhub

Usuários

• list_users_tunnelhub
• get_user_tunnelhub
• create_user_tunnelhub
• update_user_tunnelhub
• delete_user_tunnelhub

Tabelas de de/para

• list_data_stores_tunnelhub
• get_data_store_tunnelhub
• list_data_store_items_tunnelhub
• get_data_store_item_tunnelhub
• create_data_store_tunnelhub
• update_data_store_tunnelhub
• delete_data_store_tunnelhub
• create_data_store_item_tunnelhub
• update_data_store_item_tunnelhub
• delete_data_store_item_tunnelhub

Tabelas de apoio

• list_sql_tables_tunnelhub
• get_sql_table_tunnelhub
• list_sql_table_rows_tunnelhub
• export_sql_table_rows_tunnelhub
• create_sql_table_tunnelhub
• update_sql_table_tunnelhub
• migrate_sql_table_schema_tunnelhub
• delete_sql_table_tunnelhub
• create_sql_table_row_tunnelhub
• update_sql_table_row_tunnelhub
• delete_sql_table_row_tunnelhub

API Gateway

• list_api_gateways_tunnelhub
• get_api_gateway_tunnelhub
• list_api_keys_tunnelhub
• list_usage_plans_tunnelhub
• list_auth_clients_tunnelhub
• get_auth_client_tunnelhub
• list_auth_resource_servers_tunnelhub
• list_api_gateway_logs_tunnelhub
• get_api_gateway_log_tunnelhub
• list_all_api_gateway_logs_tunnelhub

Sistemas

• list_systems_tunnelhub
• get_system_tunnelhub
• create_system_tunnelhub
• update_system_tunnelhub
• delete_system_tunnelhub

Pacotes

• list_packages_tunnelhub
• get_package_tunnelhub
• create_package_tunnelhub
• update_package_tunnelhub
• delete_package_tunnelhub

Automações

• list_automations_tunnelhub
• get_automation_tunnelhub
• list_automation_deploys_tunnelhub
• get_automation_action_logs_tunnelhub
• create_automation_tunnelhub
• update_automation_tunnelhub
• delete_automation_tunnelhub
• execute_automation_tunnelhub

Transportes de automações

• list_automation_transports_tunnelhub
• request_automation_transport_tunnelhub
• approve_automation_transport_tunnelhub
• reject_automation_transport_tunnelhub

Monitoramento

• list_automation_executions_tunnelhub
• find_execution_tunnelhub
• get_execution_tunnelhub
• summarize_execution_tunnelhub
• get_execution_traces_tunnelhub
• export_execution_traces_tunnelhub
• get_trace_export_tunnelhub
• get_execution_logs_tunnelhub

summarize_execution_tunnelhub renderiza o jsonItem completo de até os primeiros 10 logs que couberem na resposta. Para consultar uma página específica, get_execution_logs_tunnelhub usa current=1 e pageSize=20 por padrão, mostra os metadados de paginação e renderiza o jsonItem de todos os itens que couberem no limite textual de 25 mil caracteres. Nenhum jsonItem é cortado: quando o limite é atingido, a resposta avisa como paginar e mantém a página integral em structuredContent.

Estatísticas

• get_home_statistics_tunnelhub
• get_tenant_execution_statistics_tunnelhub

⚙️ Variáveis de ambiente

Variáveis suportadas:

• OAUTH_CALLBACK_PORT padrão 3333
• TUNNELHUB_OAUTH_REDIRECT_URI opcional; callback loopback OAuth registrado no app client (padrão http://localhost:3333/auth/callback)
• TUNNELHUB_MANAGED_LOGIN_OAUTH opcional; padrão true, defina false somente para usar a ponte do frontend
• TUNNELHUB_FRONTEND_URL opcional
• TUNNELHUB_API_HOST opcional; padrão https://api.tunnelhub.io

Observações:

• O login humano usa Managed Login v2 com PKCE e /tenant-service/auth/public-config por padrão; TUNNELHUB_MANAGED_LOGIN_OAUTH=false força a ponte do frontend
• Tenants com requiresSamlLogin continuam usando a rota dedicada /auth/mcp/local do frontend
• Quando possível, o MCP reutiliza o domínio personalizado da empresa
• O callback OAuth direto exige a porta fixa registrada no app client; a ponte SAML pode procurar outra porta livre

🧭 Dicas de uso

• Ao procurar uma execução, informe sempre a data ou um intervalo de tempo
• Quando já souber automationId, executionId e executionPeriod, use direto as ferramentas de detalhe
• Para diagnóstico rápido, prefira summarize_execution_tunnelhub
• Para investigação detalhada, consulte traces e logs em seguida
• Os payloads dos itens de execução ficam em data[].jsonItem no retorno de get_execution_logs_tunnelhub
• Antes de uma mutação, confirme o ambiente ativo e consulte o recurso para revisar seu ID e suas dependências
• Para mutações de usuários, deletes e migração de schema, informe a confirmação de forma explícita; o MCP não presume consentimento
• Nunca coloque segredos de system em exemplos reutilizáveis ou mensagens desnecessárias

⚠️ Limitações atuais

• API Gateway está disponível em modo somente leitura
• API keys e logs podem incluir dados sensíveis retornados pelo backend
• Algumas APIs do backend têm comportamentos específicos de filtro e paginação
• A listagem de execuções depende de intervalo de tempo obrigatório
• Estatísticas de consumo do tenant são somente leitura
• Alterações administrativas de role e status de usuários não são expostas por este MCP
• Em get_tenant_execution_statistics_tunnelhub, o backend resolve o período principalmente por startDate

🛠️ Desenvolvimento local

Comandos úteis:

pnpm install
pnpm typecheck
pnpm build
pnpm dev

🤝 Contribuições

Feedback, sugestões e contribuições são bem-vindos.

Se você estiver evoluindo o MCP internamente, vale sempre validar:

• Experiência de uso no cliente MCP
• Clareza das respostas textuais
• Consistência dos filtros
• Qualidade dos exemplos do README

📦 Releases

O repositório publica GitHub Releases e o pacote no npm a partir de tags no formato vX.Y.Z.

Fluxo recomendado:

1. Garanta que a branch principal esteja pronta para release
2. Atualize a versão com um dos comandos abaixo:
   • pnpm release:patch para correções e ajustes compatíveis
   • pnpm release:minor para novas funcionalidades compatíveis
   • pnpm release:major para mudanças incompatíveis
3. Envie o commit e a tag:

git push origin main --follow-tags

Quando a tag chegar no GitHub, o workflow de release:

• valida se a tag bate com a versão do package.json
• roda pnpm check
• gera o tarball com npm pack
• publica no npm via Trusted Publishing (OIDC)
• cria ou atualiza a GitHub Release com notas automáticas

Para o publish no npm funcionar, configure o pacote no npm com Trusted Publisher apontando para tunnelhub/mcp e o workflow release.yml.

Comandos prontos:

# patch
pnpm release:patch
git push origin main --follow-tags

# minor
pnpm release:minor
git push origin main --follow-tags

# major
pnpm release:major
git push origin main --follow-tags

O histórico manual das releases fica em CHANGELOG.md.

📚 Documentação técnica

Detalhes técnicos, arquitetura e comportamento interno estão documentados em inglês:

• docs/technical-overview.md