Se você tem construído produtos SaaS em 2025-2026, provavelmente notou que todo gerente de produto agora quer "recursos de IA". Justo. Mas a verdadeira questão não é se adicionar IA -- é como dar aos modelos de IA acesso estruturado e seguro aos dados e capacidades da sua aplicação. É exatamente isso que o Model Context Protocol (MCP) resolve, e implantar servidores MCP no Vercel com Next.js se tornou um dos padrões mais práticos que já vi para times SaaS que querem se mover rápido sem criar nova infraestrutura.

Passei os últimos vários meses construindo servidores MCP para clientes -- algumas setups simples de ferramentas, outras com fluxos de autenticação multi-tenant complexos. Este artigo cobre tudo que aprendi sobre construir, implantar e escalar servidores MCP no Vercel com Next.js.

MCP Server Development: Deploy on Vercel with Next.js for SaaS

Índice

O que é MCP e por que times SaaS devem se importar

O Model Context Protocol (MCP) é um padrão aberto -- originalmente desenvolvido pela Anthropic e agora amplamente adotado -- que define como modelos de IA interagem com ferramentas externas e fontes de dados. Pense nele como uma porta USB-C para IA: uma interface padronizada que qualquer cliente de IA pode usar para se conectar a qualquer servidor compatível com MCP.

Antes do MCP, se você quisesse que Claude, GPT, ou qualquer outro modelo interagisse com seu aplicativo SaaS, você construiria integrações customizadas para cada provedor de IA. Chamada de função com OpenAI parecia diferente do uso de ferramenta com Anthropic. MCP muda isso. Você constrói um servidor, e qualquer cliente compatível com MCP pode usá-lo.

Para times SaaS, isso importa porque:

  • Seus usuários esperam integrações de IA. No meio de 2026, aproximadamente 68% dos usuários de SaaS B2B relatam usar assistentes de IA junto com suas ferramentas principais (Gartner, Q1 2026).
  • MCP está se tornando o padrão. Claude Desktop, Cursor, Windsurf, VS Code Copilot, e dezenas de outros clientes agora suportam MCP nativamente.
  • Construir um servidor MCP é mais barato que construir integrações customizadas para cada provedor de IA.

MCP vs. integrações tradicionais de API

Aspecto API tradicional Servidor MCP
Compatibilidade com cliente Um-para-um por provedor Qualquer cliente compatível com MCP
Descoberta Leitura manual de docs Descoberta automática de ferramenta/recurso
Fluxo de autenticação Customizado por integração OAuth 2.1 / Chaves de API padronizadas
Carga de manutenção Alta (N integrações) Baixa (1 servidor)
Dados em tempo real Polling ou webhooks Server-sent events / streaming
Tempo de setup Dias a semanas por cliente Horas para o servidor, minutos por cliente

Visão geral da arquitetura: MCP no Vercel

Aqui está a arquitetura na qual cheguei após iterar através de várias abordagens:

┌─────────────────┐     ┌──────────────────────┐     ┌─────────────────┐
│  Clientes MCP   │     │  Vercel (Next.js)    │     │  Seu backend    │
│                 │     │                      │     │  SaaS           │
│  - Claude       │────▶│  /api/mcp (HTTP+SSE) │────▶│  - Banco de      │
│  - Cursor       │     │  /api/mcp/sse        │     │    dados        │
│  - Apps custom  │◀────│  /api/auth/[...mcp]  │     │  - APIs         │
└─────────────────┘     └──────────────────────┘     │  - Serviços     │
                                                      └─────────────────┘

A percepção chave: seu servidor MCP não substitui sua API existente. Fica na frente dela como uma camada de tradução. O servidor MCP expõe ferramentas e recursos que mapeiam para funcionalidades SaaS existentes, mas em um formato que modelos de IA podem descobrir e usar.

No Vercel, isso é executado como funções serverless. A especificação MCP mais recente (v2025-12) suporta HTTP com Server-Sent Events (SSE) como transporte, que funciona bem com suporte de streaming do Vercel em manipuladores de rota Next.js.

Por que Next.js no Vercel?

Você poderia construir um servidor MCP com qualquer framework -- Express, Fastify, Hono, o que for. Mas Next.js no Vercel oferece algumas vantagens reais para SaaS:

  1. Seu site de marketing, app e servidor MCP vivem em um repositório. Menos infraestrutura para gerenciar.
  2. Middleware Edge lida com autenticação antes dos requests chegarem aos seus endpoints MCP.
  3. Suporte de streaming do Vercel funciona bem com transporte MCP baseado em SSE.
  4. Escala automática -- você não pensa sobre servidores.
  5. Se você já está executando Next.js (e estatisticamente, você provavelmente está), não há infraestrutura nova.

Fazemos muito desenvolvimento Next.js na Social Animal, e este padrão se tornou uma de nossas arquiteturas mais solicitadas.

MCP Server Development: Deploy on Vercel with Next.js for SaaS - architecture

Configurando seu servidor MCP Next.js

Vamos construir isso. Estou assumindo que você está no Next.js 15+ com o App Router.

Instalando dependências

pnpm add @modelcontextprotocol/sdk zod
pnpm add -D @types/node

O pacote @modelcontextprotocol/sdk (v1.12+ no início de 2026) inclui tudo que você precisa para transporte HTTP+SSE. Versões anteriores apenas suportavam stdio, que não funciona em serverless.

Criando o manipulador de rota MCP

// app/api/mcp/route.ts
import { McpServer } from '@modelcontextprotocol/sdk/server';
import { httpTransport } from '@modelcontextprotocol/sdk/server/http';
import { z } from 'zod';

const server = new McpServer({
  name: 'your-saas-mcp',
  version: '1.0.0',
  description: 'MCP server for YourSaaS platform',
});

// Registrar ferramentas (detalharemos essas próximo)
server.tool(
  'get-projects',
  'List all projects for the authenticated user',
  {
    status: z.enum(['active', 'archived', 'all']).optional().default('active'),
    limit: z.number().min(1).max(100).optional().default(20),
  },
  async ({ status, limit }, context) => {
    // Sua lógica de negócio real aqui
    const projects = await fetchProjects(context.auth.userId, { status, limit });
    return {
      content: [
        {
          type: 'text',
          text: JSON.stringify(projects, null, 2),
        },
      ],
    };
  }
);

const handler = httpTransport(server, {
  sessionManagement: true,
  cors: {
    origin: '*', // Lock this down in production
  },
});

export const GET = handler;
export const POST = handler;
export const DELETE = handler;

Endpoint SSE para streaming

Alguns clientes MCP preferem o transporte SSE para operações de longa duração:

// app/api/mcp/sse/route.ts
import { sseTransport } from '@modelcontextprotocol/sdk/server/sse';
import { server } from '../mcp-server'; // Extract server config to shared module

export const GET = sseTransport(server, {
  // Vercel tem timeout de 30 segundos no Hobby, 300s no Pro
  // Para ferramentas de longa duração, você precisará do plano Pro no mínimo
  keepAliveInterval: 15000,
});

Implementando ferramentas e recursos MCP

É aqui que o trabalho real acontece. MCP distingue entre ferramentas (ações que a IA pode tomar) e recursos (dados que a IA pode ler). Acertar nisso faz a diferença entre um servidor MCP que clientes de IA amam e um com o qual eles lutam.

Projetando boas ferramentas

O maior erro que vejo: ferramentas que são muito granulares ou muito amplas. Se você expõe 50 ferramentas pequenas, modelos de IA ficam sobrecarregados. Se você expõe 3 mega-ferramentas que cada uma leva 20 parâmetros, modelos cometem erros.

Minha regra de ouro: uma ferramenta por intenção do usuário. Se um usuário diria "mostre-me minhas faturas recentes", isso é uma ferramenta. Não divida em list-invoices + filter-invoices + format-invoices.

// Bom: intenção clara, parâmetros razoáveis
server.tool(
  'search-customers',
  'Search for customers by name, email, or account ID. Returns matching customer profiles with recent activity.',
  {
    query: z.string().describe('Search term - can be name, email, or account ID'),
    includeInactive: z.boolean().optional().default(false),
  },
  async ({ query, includeInactive }, context) => {
    const customers = await customerService.search({
      query,
      tenantId: context.auth.tenantId,
      includeInactive,
    });
    
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(customers.map(c => ({
          id: c.id,
          name: c.name,
          email: c.email,
          plan: c.plan,
          mrr: c.mrr,
          lastActive: c.lastActiveAt,
        })), null, 2),
      }],
    };
  }
);

Expondo recursos

Recursos são dados somente leitura que clientes de IA podem extrair como contexto. Pense neles como arquivos que o modelo pode referenciar:

server.resource(
  'api-docs',
  'Your SaaS API documentation',
  'text/markdown',
  async () => {
    const docs = await fs.readFile('./docs/api-reference.md', 'utf-8');
    return { content: docs };
  }
);

// Recurso dinâmico com modelo de URI
server.resourceTemplate(
  'project/{projectId}/analytics',
  'Analytics summary for a specific project',
  'application/json',
  async ({ projectId }, context) => {
    const analytics = await analyticsService.getSummary(projectId, context.auth.tenantId);
    return { content: JSON.stringify(analytics) };
  }
);

Autenticação e multi-tenant

Esta é a parte que todo mundo acerta errado na primeira tentativa. MCP suporta OAuth 2.1 para autenticação, e se você está construindo um SaaS multi-tenant, você absolutamente precisa disso.

Fluxo OAuth 2.1 para MCP

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  if (request.nextUrl.pathname.startsWith('/api/mcp')) {
    const authHeader = request.headers.get('authorization');
    
    if (!authHeader?.startsWith('Bearer ')) {
      return NextResponse.json(
        { error: 'Missing or invalid authorization header' },
        { status: 401 }
      );
    }
    
    // Validar o token e injetar contexto de tenant
    // É aqui que seu sistema de autenticação existente se conecta
  }
}

export const config = {
  matcher: '/api/mcp/:path*',
};

Para o endpoint de descoberta OAuth que clientes MCP precisam:

// app/.well-known/oauth-authorization-server/route.ts
export function GET() {
  return Response.json({
    issuer: 'https://your-saas.com',
    authorization_endpoint: 'https://your-saas.com/oauth/authorize',
    token_endpoint: 'https://your-saas.com/api/oauth/token',
    registration_endpoint: 'https://your-saas.com/api/oauth/register',
    scopes_supported: ['mcp:read', 'mcp:write', 'mcp:admin'],
    response_types_supported: ['code'],
    code_challenge_methods_supported: ['S256'],
  });
}

Isolamento multi-tenant

Cada invocação de ferramenta MCP deve estar escopo ao tenant autenticado. Eu uso um padrão onde o contexto de autenticação é injetado em cada manipulador de ferramenta automaticamente:

const withTenant = (handler) => async (params, context) => {
  const tenant = await resolveTenant(context.auth.token);
  if (!tenant) throw new McpError('Invalid tenant');
  return handler(params, { ...context, tenant });
};

Nunca confie em parâmetros de ferramenta para identificação de tenant. Sempre derive do token de autenticação.

Implantando no Vercel: Configuração e Armadilhas

Configuração vercel.json

{
  "functions": {
    "app/api/mcp/route.ts": {
      "maxDuration": 60
    },
    "app/api/mcp/sse/route.ts": {
      "maxDuration": 300
    }
  },
  "headers": [
    {
      "source": "/api/mcp/(.*)",
      "headers": [
        { "key": "Cache-Control", "value": "no-store" }
      ]
    }
  ]
}

As armadilhas que ninguém lhe conta

1. Timeouts de função. O plano Vercel Hobby tem máximo de 30 segundos. Pro oferece 300 segundos. Para ferramentas MCP que chamam APIs lentas ou processam dados, você precisa de Pro no mínimo. A $20/mês por membro da equipe, não é grande coisa para a maioria dos times SaaS.

2. Cold starts. Cold starts serverless podem adicionar 200-800ms ao primeiro request. Clientes MCP geralmente lidam bem com isso -- eles não estão esperando respostas sub-50ms. Mas se isso o incomoda, use cron do Vercel para manter funções aquecidas.

3. SSE e streaming. Vercel suporta respostas de streaming, mas há casos extremos com sua camada CDN. Defina Cache-Control: no-store em todas as rotas MCP. Aprendi isso do jeito difícil quando respostas SSE em cache causaram clientes receberem listas de ferramentas obsoletas.

4. Tamanho do corpo do request. Vercel limita corpos de request a 4.5MB em funções serverless. Se suas ferramentas MCP lidam com uploads de arquivo ou payloads grandes, você precisará usar URLs de upload assinadas em vez disso.

5. Variáveis de ambiente. Não se esqueça de definir a URL pública do seu servidor MCP como uma variável de ambiente. Durante desenvolvimento, você usará algo como ngrok ou URLs de preview do Vercel, mas em produção, precisa ser seu domínio canônico.

# .env.production
MCP_SERVER_URL=https://your-saas.com/api/mcp
MCP_SERVER_NAME=your-saas-mcp

Otimização de desempenho e escala

Estratégias de cache

Respostas de ferramentas MCP podem ser armazenadas em cache quando dados não mudam frequentemente:

import { unstable_cache } from 'next/cache';

const getCachedAnalytics = unstable_cache(
  async (tenantId: string, projectId: string) => {
    return analyticsService.getSummary(tenantId, projectId);
  },
  ['analytics-summary'],
  { revalidate: 300 } // 5 minutes
);

Connection pooling

Se suas ferramentas MCP acessam um banco de dados, use connection pooling. No Vercel, cada invocação de função recebe seu próprio contexto de execução, então sem pooling, você esgotará conexões de banco de dados rapidamente.

import { Pool } from '@neondatabase/serverless';

// O driver serverless do Neon lida com pooling automaticamente
const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
});

Recomendaria Neon ou PlanetScale para ferramentas MCP apoiadas por banco de dados no Vercel. Ambos lidam bem com o modelo de conexão serverless.

Benchmarks

Aqui estão o que medimos em vários deployments MCP em produção no Vercel Pro:

Métrica Cold Start Warm P99
Ferramenta simples (sem BD) 420ms 45ms 180ms
Ferramenta apoiada por BD (Neon) 680ms 95ms 320ms
Ferramenta com API externa 850ms 280ms 1200ms
Setup de conexão SSE 520ms 60ms 250ms
Descoberta de ferramenta (list) 380ms 30ms 120ms

Esses números são bons para interações de cliente de IA. Modelos levam segundos para gerar respostas de qualquer forma -- seu servidor MCP não será o gargalo.

Monitoramento e observabilidade

Você precisa saber o que está acontecendo em produção. Servidores MCP têm necessidades de observabilidade únicas porque os "usuários" são modelos de IA, não humanos.

O que rastrear

  • Frequência de invocação de ferramentas -- quais ferramentas modelos realmente estão usando?
  • Taxas de erro por ferramenta -- uma ferramenta específica está falhando mais que outras?
  • Distribuição de token/tenant -- um tenant está martelando seu servidor?
  • Tamanhos de payload de resposta -- respostas oversized desperdiçam janelas de contexto do modelo
// Middleware de logging simples para ferramentas MCP
const withLogging = (toolName: string, handler: Function) => {
  return async (params: any, context: any) => {
    const start = performance.now();
    try {
      const result = await handler(params, context);
      const duration = performance.now() - start;
      
      console.log(JSON.stringify({
        type: 'mcp_tool_invocation',
        tool: toolName,
        tenant: context.auth?.tenantId,
        duration,
        success: true,
        responseSize: JSON.stringify(result).length,
      }));
      
      return result;
    } catch (error) {
      console.error(JSON.stringify({
        type: 'mcp_tool_error',
        tool: toolName,
        tenant: context.auth?.tenantId,
        error: error.message,
      }));
      throw error;
    }
  };
};

Canalize esses logs para Axiom (logging integrado do Vercel), Datadog, ou o que quer que você já esteja usando. Log Drains incorporadas do Vercel tornam isso direto.

Análise de custos: Executando servidores MCP no Vercel

Vamos falar dinheiro. Aqui está um breakdown realista de custos para um SaaS de médio porte executando um servidor MCP no Vercel em 2026:

Componente Hobby Pro Enterprise
Plano base $0/mês $20/mês por assento Custom
Invocações de função (incluídas) 100K 1M Custom
Invocações adicionais N/A $0.60 por 1M Negociável
Largura de banda (incluída) 100GB 1TB Custom
Duração máx de função 30s 300s 900s
Middleware Edge Incluído Incluído Incluído
Estimado mensal (10K requests MCP/dia) Não viável ~$25-40 Custom

Para a maioria dos produtos SaaS, o plano Pro lida com tráfego MCP confortavelmente. Com ~10.000 invocações de ferramentas MCP por dia (o que é bem ativo), você está vendo ~300K execuções de função por mês -- bem dentro da alocação incluída do Pro.

Compare isso com executar um servidor MCP dedicado no AWS: você precisaria no mínimo uma instância EC2 ($30-50/mês), load balancer ($18/mês), e seu tempo gerenciando infraestrutura. Vercel vence em simplicidade operacional.

Se você está avaliando a arquitetura certa para seu SaaS, podemos ajudar a escopar isso. Verifique nossa página de preços ou nos contacte diretamente.

FAQ

O que é o Model Context Protocol (MCP) e como ele difere de chamada de função?

MCP é um padrão aberto para conectar modelos de IA a ferramentas e dados externos. Diferente de chamada de função específica do provedor (chamada de função OpenAI, uso de ferramenta Anthropic), MCP é universal. Você constrói um servidor MCP, e qualquer cliente compatível -- Claude, Cursor, apps customizados -- pode descobrir e usar suas ferramentas automaticamente. Chamada de função exige que você defina ferramentas separadamente para cada provedor de IA.

Posso implantar um servidor MCP no plano Hobby gratuito do Vercel?

Tecnicamente sim, mas não recomendaria para produção. O timeout de função de 30 segundos é muito restritivo para ferramentas MCP que consultam bancos de dados ou chamam APIs externas. Você também recebe invocações limitadas (100K/mês). O plano Pro a $20/mês por assento é o mínimo que sugeriria para qualquer workload real.

Como faço para lidar com autenticação entre clientes MCP e meu SaaS?

A especificação MCP suporta OAuth 2.1. Você expõe um endpoint .well-known/oauth-authorization-server que clientes MCP descobrem automaticamente. Quando um usuário se conecta via um cliente de IA como Claude, ele é redirecionado para seu fluxo OAuth padrão, concede permissões, e o cliente recebe um token de acesso escopo. Este token é enviado com cada request MCP.

Qual é a diferença entre ferramentas MCP e recursos MCP?

Ferramentas são ações -- coisas que a IA pode fazer (criar um projeto, enviar um email, executar uma consulta). Recursos são dados -- coisas que a IA pode ler para contexto (documentação, arquivos de configuração, resumos de análises). Ferramentas são invocadas sob demanda; recursos são carregados na janela de contexto do modelo. Projete ferramentas para ações, recursos para material de referência.

Quantas ferramentas MCP meu servidor deve expor?

Da minha experiência, 5-15 ferramentas é o sweet spot para a maioria dos produtos SaaS. Menos de 5 e seu servidor MCP não é muito útil. Mais de 20 e modelos de IA começam a fazer pobres decisões de seleção de ferramentas. Agrupe operações relacionadas em ferramentas únicas com opções de parâmetros em vez de expor cada operação CRUD separadamente.

Isso funciona com frameworks além de Next.js?

Absolutamente. O @modelcontextprotocol/sdk funciona com qualquer framework Node.js. Você poderia usar Hono, Express, ou até Astro com endpoints SSR. Next.js no Vercel é apenas uma combinação particularmente conveniente por causa do suporte de streaming incorporado, middleware edge, e deploy zero-config. Se você está usando um stack diferente, nosso time de desenvolvimento de CMS headless construiu servidores MCP através de múltiplos frameworks.

Como testo meu servidor MCP durante desenvolvimento?

O MCP Inspector (parte do kit de ferramentas oficial MCP) é seu melhor amigo. Ele se conecta ao seu servidor local e permite que você invoque ferramentas, navegue recursos, e depure respostas interativamente. Para testes automatizados, escreva testes de integração que instanciam seu servidor MCP in-process e chamam ferramentas programaticamente -- o SDK suporta isso sem precisar de transporte HTTP.

O que acontece quando funções Vercel sofrem cold start durante um request MCP?

Clientes MCP são projetados para serem tolerantes com latência -- eles estão tipicamente esperando por respostas de modelo de IA que levam segundos de qualquer forma. Um cold start de 400-800ms é imperceptível na prática. Se você está preocupado, o plano Pro do Vercel permite configurar aquecimento baseado em cron, e o SDK inclui lógica automática de retry para falhas transitórias. Em seis meses de uso em produção, cold starts nunca foram um problema relatado pelo usuário para nossos clientes.