Cada usuário do seu app com o MCP dele

Em vez de consumir a API no seu backend, cada usuário final pluga o MCP dele no Claude/ChatGPT: toolkit e convite por usuário, isolamento de fábrica e a URL no seu domínio.

Precisa de chave própria
Executar com IA

Pule a leitura: mande este guia como um prompt pronto pra rodar. Ele instrui o assistente a parar e te perguntar sempre que precisar de uma credencial ou de um passo que só você pode fazer.

O Claude Code abre com o prompt preenchido mas não enviado, pra você revisar antes.

Tem dois jeitos de colocar um MCP dentro do seu produto, e eles servem a coisas diferentes:

  • Um MCP dentro do seu produto — o seu backend consome a API REST. O usuário final nunca vê a MCP.AI, e nunca vê um endereço nosso. É o caminho para dashboard, painel, relatório.
  • Este guia — cada usuário final ganha o MCP dele, que ele pluga no próprio Claude ou ChatGPT e usa pra conversar com os próprios dados. Você não constrói a interface de conversa: ela já é o cliente de IA que ele usa.

Se o seu produto é um app que mostra os dados, use o primeiro. Se o diferencial que você quer vender é "converse com os seus dados", é este aqui.

Vale pra qualquer MCP do catálogo. O mecanismo é da plataforma, não do conector: troque o mi_ e o fluxo é idêntico.

O que você precisa antes

  1. Uma workspace API key (sk_live_…), em app.mcp.ai → Configurações → API. Ela vai autenticar as chamadas server-to-server abaixo. Use a key de workspace; uma key escopada num MCP não cria toolkit nem convite.
  2. O id da instalação do MCP que você vai oferecer (mi_…):
bash
curl -s https://app.mcp.ai/api/mcps \
  -H "Authorization: Bearer $MCPAI_KEY"

Procure o MCP na resposta e guarde o mi_….

Você não precisa instalar o MCP de novo a cada usuário. É UM install por workspace; o que nasce por usuário é o toolkit e o convite. E num MCP que autentica por OAuth, o install já nasce com o escopo de credencial per_user: cada convidado conecta a conta dele e enxerga só a dele, sem você configurar nada. (Confira o escopo na aba Credenciais do MCP; se for shared, troque pra per_user antes de convidar alguém.)

Passo 1 — um toolkit por usuário

O toolkit é o "pacote de ferramentas" que vira uma URL de MCP. Crie um por usuário do seu app, já apontando pro install:

bash
curl -s -X POST https://app.mcp.ai/api/toolkits \
  -H "Authorization: Bearer $MCPAI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "meuapp:<id-do-usuario-no-seu-sistema>", "mcpIds": ["<mi_...>"]}'

Use o seu id de usuário no name. É o que te deixa reconhecer de quem é o toolkit depois, sem manter um de-para à parte.

A resposta traz o tk_…. Guarde junto do cadastro do usuário.

Passo 2 — o convite

O convite (inv_…) é a identidade do usuário final dentro daquele toolkit. É ele que separa os dados de um usuário dos do outro.

bash
curl -s -X POST https://app.mcp.ai/api/toolkits/<tk_...>/invites \
  -H "Authorization: Bearer $MCPAI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"label": "<nome ou id do usuario>"}'

A resposta traz o convite com o campo url — que é exatamente a URL do próximo passo, já montada.

Passo 3 — a URL que o usuário recebe

https://api.mcp.ai/<tk_...>?u=<inv_...>

É isso que ele cola no Claude, no ChatGPT ou no cliente de IA dele. Trate essa URL como segredo: quem tem o link tem o acesso daquele usuário, do mesmo jeito que um link de convite. Entregue por dentro do seu app (área logada), não por e-mail em massa.

Passo 4 — ele conecta a conta dele

Na primeira vez que o usuário pedir algo que exija a conta dele, o próprio MCP devolve o link de conexão dentro da conversa. Ele abre, autoriza no provedor e volta. Você não precisa construir nem hospedar esse fluxo, e o consentimento acontece ali, com ele.

Daí em diante as perguntas dele já respondem com os dados dele.

Sua marca no fluxo (dois domínios)

Nos planos que incluem domínio próprio, em app.mcp.ai → página do MCP → aba Configurações → Domínio próprio, você pode configurar dois domínios, com papéis diferentes:

camposerveexemplo
Domínio de conexãoa tela onde o usuário autoriza a contaconectar.seuapp.com
Domínio do endpoint MCPa URL que ele cola no cliente de IAmcp.seuapp.com

Os dois apontam pro mesmo CNAME, que a tela mostra; use um subdomínio para cada (um host não pode fazer os dois papéis). Depois de verificados, a URL do Passo 3 passa a sair assim, automaticamente:

https://mcp.seuapp.com/<tk_...>?u=<inv_...>

E o nome que aparece no cliente de IA do seu usuário passa a ser o seu, não o nosso.

Neste guia o segundo campo importa de verdade — diferente da integração por REST, aqui a URL do MCP é justamente o que o usuário final vê e guarda.

Isolamento entre os seus usuários

Vem de fábrica, e é bom saber por quê:

  • Um toolkit por usuário — o MCP de um não lista o do outro.
  • Um convite por usuário — o ?u=inv_… identifica quem está chamando.
  • Escopo per_user — a credencial fica amarrada ao convite que conectou. Um convidado nunca lê a conexão de outro, mesmo dentro do mesmo workspace.

O que conta como uso

Criar toolkit e convite é de graça. Provisionar o usuário no seu cadastro não custa nada; custa quando ele efetivamente usa.

O que é cobrado depende do modelo do MCP, e a página dele em app.mcp.ai mostra qual é: alguns cobram por conta conectada (aí vale conferir se a contagem é por ciclo, porque conectar e desconectar no mesmo mês já conta), outros por chamada ou por crédito (aí conectar é livre e você paga o consumo).

O que não dá

  • Fazer o que o MCP não faz. Cada conector expõe um conjunto fixo de ferramentas, e alguns são read-only por arquitetura.
  • Pular o consentimento. Nem por API, nem com domínio próprio.
  • Ver a conta do seu usuário. A credencial é dele, sob o convite dele. Você administra o acesso, não os dados.

Próximo passo

Teste com um usuário só: crie um toolkit, um convite, cole a URL no seu próprio Claude e conecte uma conta sua. A franquia gratuita do MCP cobre esse teste, antes de assinar qualquer coisa.

Quando for dimensionar volume ou quiser os domínios próprios, fale com a gente em contato@mcp.ai.

Outros guias