MCPinho Web

Painel administrativo do gateway MCP MCPinho. A interface React consome a API Mcpinho.Api para cadastrar aplicações MCP, sincronizar e habilitar ferramentas, acompanhar conexões e consultar a auditoria de execuções. O login é feito pelo Loguinho.

O backend é a fonte da verdade. Algumas telas já existem na interface, mas dependem de recursos que a API ainda não oferece (veja Limitações atuais).

O que faz

• Dashboard: visão geral do gateway.
• Aplicações: cadastro, edição, ativação/desativação e detalhe de servidores MCP (endpoint HTTPS, identificador único, tipo de autenticação).
• Ferramentas: lista o catálogo de cada aplicação, sincroniza com o servidor de origem e habilita ou desabilita cada ferramenta. Ferramentas recém-descobertas ficam desabilitadas até aprovação explícita.
• Conexões: exibe o estado da conexão do usuário com aplicações que usam OAuth.
• Agentes: tela reservada; a API ainda não tem endpoint de clientes/agentes.
• Auditoria: lista as execuções registradas (início, duração, status e código de erro).
• Configurações: mostra a URL pública da API e do endpoint /mcp, e testa o /health da API.

Stack

React 19, TypeScript, Vite, Tailwind CSS 4, lucide-react e motion. Em produção o build estático é servido por Nginx.

Como rodar

Requisitos: Node.js 24 (mesma versão do Dockerfile) e a API em execução, por padrão em http://localhost:5208.

1. Instale as dependências:

   npm install
   

2. Configure as variáveis de ambiente (opcional em desenvolvimento, pois há valores padrão):

   cp .env.example .env.local
   

3. Inicie o servidor de desenvolvimento em http://localhost:3000:

   npm run dev
   

A porta 3000 é a origem liberada por padrão no CORS da API (Cors:Origins). Se usar outra porta ou domínio, adicione-o à configuração Cors:Origins da API.

Scripts

Comando	Uso
npm run dev	Servidor de desenvolvimento do Vite (porta 3000)
npm run build	Build de produção em dist/
npm run preview	Serve o build localmente
npm run lint	Verificação de tipos (tsc --noEmit)

Configuração

As variáveis são lidas em tempo de build pelo Vite (prefixo VITE_). Não grave segredos nelas: tudo o que é VITE_* fica visível no navegador.

Variável	Padrão	Uso
VITE_API_URL	obrigatório	URL base da Mcpinho.Api (sem barra final); a aplicação falha ao iniciar se não estiver configurada

O clientId do Loguinho (mcpinho) é fixo no código, em src/context/AuthContext.tsx.

Autenticação

O painel abre na tela de login e só exibe as demais telas com sessão válida; ao expirar ou ao sair, o usuário volta para ela. Ele usa o Método 1 do Loguinho (login direto): o usuário informa e-mail e senha, a interface chama POST https://loguinho.biao.com.br/api/conta/login e recebe o JWT e o refresh token. A renovação usa POST https://loguinho.biao.com.br/api/conta/refresh.

• A sessão fica no localStorage (mcpinho_auth_session_v1) e o token é enviado como Authorization: Bearer a cada chamada à API.
• A API valida o token (RS256, emissor, audiência e claim sub). As rotas /api exigem a política Administrador: o sub do usuário precisa ser o configurado em Mcpinho__AdministradorUsuarioId na API. Sem isso as chamadas retornam 403.
• O clientId e a audiência do token precisam coincidir com o que a API espera em Loguinho__LoginDireto__*.
• O navegador chama o Loguinho diretamente, então a política CORS do provedor precisa aceitar a origem do painel.

Detalhes dos métodos de login em Mcpinho.Api/docs/loguinho.md.

Integração com a API

Todas as chamadas passam por src/services/api.ts.

Tela	Endpoints
Aplicações	GET/POST /api/aplicacoes, GET/PUT /api/aplicacoes/{id}, POST /api/aplicacoes/{id}/desativar
Ferramentas	GET /api/ferramentas/aplicacao/{id}, POST /api/ferramentas/aplicacao/{id}/sincronizar, PATCH /api/ferramentas/{id}/habilitacao
Conexões	GET /api/conexoes, POST /api/conexoes/{id}/conectar, DELETE /api/conexoes/{id}
Auditoria	GET /api/auditoria/execucoes
Configurações	GET /health (anônimo)

Agentes MCP usam o endpoint /mcp da API diretamente; a interface apenas exibe a URL para configuração do cliente.

Limitações atuais

Refletem o estado do backend em Mcpinho.Api/docs/estado-atual.md:

• OAuth por aplicação: POST /api/conexoes/{id}/conectar ainda responde 501; o fluxo de conexão individual não funciona.
• Teste de conectividade de servidores MCP: a API não tem rota para isso, então a ação exibe erro.
• Agentes: sem endpoint na API; a lista fica vazia.
• Auditoria: a API não devolve argumentos nem resumo da resposta (por segurança), então esses campos não aparecem.

Docker

O Dockerfile faz o build com pnpm e serve dist/ com Nginx na porta 80, com fallback de SPA e bloqueio de arquivos sensíveis (nginx.conf). A URL da API é fixada no build:

docker build --build-arg VITE_API_URL=https://api.exemplo.com -t mcpinho-web .
docker run -p 8080:80 mcpinho-web

O pnpm-lock.yaml já está versionado e a instalação usa --frozen-lockfile; ao mudar dependências, rode pnpm install e commite o lockfile atualizado.

Estrutura

src/
├── components/   layout, modais (aplicações, execução, conexão) e detalhe de ferramenta
├── context/      AuthContext (sessão Loguinho) e NavigationContext (rotas internas)
├── pages/        Dashboard, Aplicações, Ferramentas, Conexões, Agentes, Auditoria, Configurações
├── services/     api.ts (cliente da API e adaptadores dos DTOs)
└── types/        tipos compartilhados

A navegação é feita por estado interno (NavigationContext), sem React Router.