O servidor MCP é a peça que efetivamente entrega valor em qualquer configuração de MCP. Sem ele, o assistente não tem nada para acessar.
O que um servidor expõe
Conforme a especificação, um servidor pode expor três tipos de capacidade. Nem todo servidor implementa todas — e está tudo bem.
| Primitiva | Para que serve | Risco |
|---|---|---|
| Tools | Ações que o modelo pode executar | Alto — pode alterar dados |
| Resources | Dados para leitura como contexto | Médio — exposição de dados |
| Prompts | Templates de instrução reutilizáveis | Baixo |
Local ou remoto
Servidores locais usam o transporte stdio: o cliente inicia o programa na sua máquina e a comunicação acontece pela entrada e saída padrão. É simples, rápido e não exige autenticação de rede — mas só existe naquela máquina.
Servidores remotos usam Streamable HTTP e ficam acessíveis por rede, permitindo que um time inteiro use o mesmo servidor. Em troca, exigem autenticação de verdade, porque ficam expostos.
Escolhendo o SDK
O projeto MCP mantém SDKs oficiais em Python e TypeScript, com SDKs mantidos pela comunidade em outras linguagens. A escolha costuma seguir a linguagem em que o seu sistema já está escrito.
- Python: se o acesso é a dados, análise ou scripts internos.
- TypeScript: se o alvo é a web ou se você quer o servidor rodando no edge.
- Outras linguagens: verifique se existe SDK comunitário ativo antes de começar.
Como é a configuração do lado do cliente
Do lado de quem usa, configurar um servidor MCP local é declarar como iniciá-lo. Este é o formato padrão usado por vários clientes:
{
"mcpServers": {
"meu-projeto": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/caminho/do/projeto"]
}
}
}O campo `command` é o executável, `args` são os argumentos e as variáveis de ambiente (quando existirem) entram em um campo próprio. Esse mesmo formato é usado por Cursor, Claude Desktop e outros clientes — com pequenas diferenças no caminho do arquivo.
Princípios para criar o seu
1. Exponha o mínimo necessário
Cada ferramenta exposta é superfície de risco e espaço consumido na janela de contexto. Um servidor com três ferramentas bem desenhadas é melhor que um com vinte ferramentas sobrepostas.
2. Escreva descrições pensando no modelo
A descrição da ferramenta é o que o modelo lê para decidir quando usá-la. Seja específico sobre quando usar e quando não usar. "Consulta o banco de dados" é fraco; "Consulta pedidos por período. Use apenas para leitura; não use para alterar dados." é bem melhor.
3. Prefira leitura a escrita
Um servidor que apenas lê dados é substancialmente mais seguro. Se operações de escrita forem necessárias, considere exigir confirmação explícita ou restringi-las a ambientes que não sejam produção.
4. Retorne erros úteis
Quando uma chamada falha, a mensagem de erro vai para o modelo, que pode tentar corrigir. "Erro 400" é inútil. "Parâmetro de data deve estar no formato AAAA-MM-DD" permite que o modelo se corrija sozinho.
5. Limite o volume de retorno
Retornar dez mil linhas consome o contexto e piora a resposta. Pagine resultados e defina um padrão sensato de limite por consulta.