Conectei o Servidor MCP Gerenciado da Oracle a Clientes de Chat de IA - Veja o que Funcionou

Assistentes de IA estão se tornando bons em fazer coisas, não apenas em conversar — em grande parte graças ao MCP (Modelo de Protocolo de Contexto), o padrão aberto que permite que um cliente de IA chame ferramentas externas. A Oracle recentemente lançou um servidor MCP gerenciado no OCI (Servidor MCP de Ferramentas de Banco de Dados) que permite que um cliente de IA execute consultas contra um banco de dados Oracle, com OAuth e acesso baseado em funções integrados.

Eu queria usá-lo para algo prático: verificações de saúde somente leitura para um banco de dados Oracle E‑Business Suite na versão 19c, apresentadas dentro de um chat de IA — "O banco de dados está ativo? Alguma sessão bloqueada? Quais gerentes concorrentes estão inativos?"

Funcionou no final — um assistente de IA puxando dados de saúde do banco de dados ao vivo e somente leitura. Mas chegar lá me ensinou muito sobre como o MCP gerenciado + OAuth realmente se comporta. Aqui está a jornada honesta.

A configuração, em termos simples

• Um servidor MCP gerenciado no OCI, apontado para o banco de dados através de um usuário somente leitura.
• Algumas ferramentas SQL personalizadas somente leitura (visão geral da instância, sessões ativas, sessões bloqueadas, status do gerente concorrente…).
• Um cliente de chat de IA conectado via MCP + OAuth.

Pegadinha #1 — um banco de dados privado precisa de um Endpoint Privado

O serviço MCP é gerenciado — ele roda na tenência da Oracle, não na sua rede. Portanto, ele não pode acessar um banco de dados privado por conta própria. Você anexa um Endpoint Privado para dar a ele um ponto de apoio dentro do seu VCN. Manter as coisas privadas é exatamente por que você precisa do endpoint, não uma razão para ignorá-lo.

Pegadinha #2 — somente leitura é sua verdadeira proteção

Eu apontei a conexão para um usuário de banco de dados somente leitura. Mesmo que o conjunto de ferramentas possa executar SQL geral, a conta simplesmente não pode escrever. Essa única decisão supera qualquer quantidade de avisos de "por favor, tenha cuidado".

Pegadinha #3 — a URL do endpoint tem uma data de versão, e isso importa

Cada URL de servidor OCI MCP tem um segmento de versão da API como /20250830/. Eu reutilizei uma URL de um servidor anterior com uma data diferente. Resultado: HTTP 404 em cada chamada, não importa quão perfeita fosse minha autenticação. Lição: copie a URL exata do Servidor do console, incluindo a data da versão. O 404 parecia um problema de autenticação por muito tempo — não era.

Pegadinha #4 — OAuth: 404 vs 401 quebra UIs de chat web auto-hospedadas

A grande questão. Muitos clientes de MCP OAuth são dirigidos por descoberta: acesse o servidor, espere um 401 com metadados OAuth, use isso para iniciar o login. O servidor da Oracle retorna 404 para solicitações não autenticadas — então uma UI de chat web auto-hospedada (eu tentei o LibreChat) nunca constrói a URL de login e não consegue iniciar o fluxo, mesmo quando tudo está configurado corretamente.

Duas coisas agravam isso para UIs de chat hospedadas no servidor:

1. Elas rodam sem cabeça (sem navegador para o login interativo).
2. O 404 derrota a auto-descoberta.

Portanto, UIs de chat hospedadas no servidor não são uma boa opção para este servidor hoje.

Pegadinha #5 — o papel depende do token do usuário, não do token do aplicativo

Eu tentei um token de credenciais do cliente (identidade do aplicativo) para pular o navegador. Ele autenticou (HTTP 200!), mas cada chamada de ferramenta retornou Permissões necessárias ausentes. O papel de acesso é um papel de usuário — e tokens de credenciais do cliente carregam escopos, não papéis. A solução foi um token de authorization_code (usuário): o usuário tem o papel, então seu token é autorizado.

O que realmente funcionou: clientes de desktop

Clientes de IA de desktop têm um navegador para o login e fazem feliz o fluxo de OAuth do usuário. Usando mcp-remote com metadados OAuth estáticos (para que não dependa da descoberta 404), eu me conectei a partir do Claude Desktop e VS Code + Cline:

{
  "mcpServers": {
    "db_diag": {
      "command": "npx.cmd",
      "args": [
        "-y", "mcp-remote",
        "<exact Server URL with the correct /YYYYMMDD/>",
        "3334",
        "--static-oauth-client-info", "{\"client_id\":\"<public client id>\"}",
        "--static-oauth-server-metadata", "{\"issuer\":\"...\",\"authorization_endpoint\":\".../authorize\",\"token_endpoint\":\".../token\"}"
      ]
    }
  }
}

Um navegador foi aberto, eu fiz login como um usuário com o papel correto, e as ferramentas apareceram. Pedindo "me dê a visão geral da instância" retornou dados ao vivo — nome da instância, versão, modo aberto, tempo de atividade — tudo somente leitura.

Algumas armadilhas menores

• No Windows, os clientes iniciam npx e falham com ENOENT — use npx.cmd e reinicie o aplicativo para que o PATH seja atualizado.
• Não execute dois clientes na mesma porta de callback OAuth (EADDRINUSE) — dê a cada um sua própria porta e registre ambos os redirecionamentos.
• Evite TO_CHAR(date,'HH24:MI:SS') no SQL do conjunto de ferramentas — os dois pontos são interpretados como variáveis de ligação. Retorne a data bruta.
• Use gv$ views (não v$) para ver todas as instâncias RAC.

Conclusões

1. MCP gerenciado + agentes de IA são reais — um assistente de banco de dados governado e somente leitura é genuinamente útil.
2. Combine o cliente com a implantação — clientes de desktop lidam com o fluxo de usuário OAuth; UIs web sem cabeça têm dificuldades.
3. Um usuário de banco de dados somente leitura é seu controle mais forte.
4. Copie a URL exata do servidor — um 404 é frequentemente um caminho