
Como Permitir que um Agente de IA Gere PDFs Reais (com um servidor MCP)
Agentes de IA são ótimos em produzir texto. Mas no momento em que você precisa de um documento real — uma fatura, um relatório, um certificado — eles falham. Você recebe markdown que precisa formatar sozinho, ou (com o Code Interpreter) um PDF rudimentar de uma biblioteca Python com fontes e tabelas genéricas que nunca parecem certas. Não há uma maneira limpa de entregar a um agente a tarefa de "produzir um PDF polido".
Então, eu dei aos meus agentes uma ferramenta que faz exatamente isso, através do MCP (Modelo de Protocolo de Contexto). O agente descreve o documento e recebe de volta um link para um PDF editável finalizado. Aqui está como configurá-lo em cerca de 5 linhas de configuração.
Divulgação: Eu trabalho na PDFMakerAPI — mas o padrão aqui (dar a um agente uma única ferramenta bem definida que retorna um artefato revisável) se aplica a qualquer servidor MCP. A configuração abaixo apenas acontece de usar a minha.
Refrescante de 30 segundos sobre MCP
MCP é o padrão aberto para dar a um agente de IA ferramentas. Você direciona seu cliente (Claude Desktop, Cursor, Windsurf, Cline, VS Code, ChatGPT…) para um servidor MCP, e o agente agora pode chamar quaisquer funções que esse servidor expõe. Sem código de ligação, sem integração personalizada por cliente — essa é toda a atração.
O servidor que estamos adicionando expõe exatamente uma ferramenta: create_document. (Uma ferramenta de propósito — uma área de superfície pequena e previsível é mais fácil para um agente usar corretamente do que um saco de vinte.)
Passo 1 — Adicione o servidor
Coloque isso na configuração MCP do seu cliente (Claude Desktop: Configurações → Desenvolvedor → Editar Configuração; Cursor: ~/.cursor/mcp.json; mesma ideia em outros lugares):
{
"mcpServers": {
"pdfmakerapi": {
"command": "npx",
"args": ["-y", "@pdfmakerapi/mcp"]
}
}
}
Reinicie o cliente. Essa é toda a configuração — sem chave de API, sem conta.
Usando um cliente web como Claude.ai ou ChatGPT que não pode executar npx? Adicione o endpoint hospedado como um conector personalizado em vez disso:
https://api.pdfmakerapi.com/mcp
Passo 2 — Peça um documento
Agora basta pedir ao agente em inglês simples:
"Faça uma fatura profissional para a Acme Corp — 3 itens, líquido em 30 dias."
O agente chama create_document, e você recebe de volta um link como:
https://app.pdfmakerapi.com/d/019ee2fe-c503-71c0-aaf6-68cf33ca096c
Abra-o e você verá a fatura finalizada — e você pode editar qualquer campo antes de baixar o PDF. Aqui está um real para clicar:
👉 Exemplo de fatura ao vivo
Funciona para faturas, recibos, certificados, relatórios, currículos, cartas — se o agente pode descrevê-lo, ele pode organizá-lo com cabeçalhos, tabelas e seus dados.
Por que o "link editável" é importante para os agentes
Esta é a parte que realmente me importa, e é por isso que eu não fiz a ferramenta apenas gerar um PDF final.
Se você passou algum tempo executando agentes em produção, sabe que o modo de falha não é "resposta ruim" — é uma ação errada que já foi feita. Um agente que envia um e-mail para o cliente errado ou arquiva o número errado é pior do que um que apenas diz algo estúpido.
Retornar um documento editável em vez de um arquivo finalizado constrói um checkpoint humano no fluxo de trabalho:
- O agente elabora o documento a partir do pedido.
- Um humano abre o link, verifica, corrige qualquer coisa e baixa.
Assim, o agente faz os 90% tediosos (layout, estrutura, reunindo os dados), mas uma pessoa permanece no controle do que realmente é enviado. Para qualquer coisa que saia do prédio — uma fatura para um cliente, um certificado com o nome de alguém — esse checkpoint vale muito mais do que total autonomia.
O que ele não faz (para que você defina o escopo corretamente)
Falando claramente sobre os limites:
- Ele gera documentos — ele não lê ou edita um PDF que você envia. Problema diferente.
- Ele retorna um documento web editável + um PDF para download, não um formulário em branco para distribuir.
Se seu agente precisa produzir documentos estruturados a partir de dados ou um prompt, isso se encaixa. Se ele precisa analisar PDFs existentes, você quer uma ferramenta diferente.
Por trás das câmeras (para os curiosos)
create_document leva um modelo de documento — uma pequena árvore JSON de nós (texto, contêineres, tabelas) com {{variáveis}} opcionais — e o armazena, retornando o link de compartilhamento. O agente pode construir essa estrutura a partir de um prompt, ou você pode POSTá-la você mesmo para a mesma API REST se preferir pular o agente completamente. É código aberto (MIT) se você quiser ler a definição da ferramenta: github.com/GerardoBarrera/pdfmakerapi-mcp.
Conclusão
Dar a um agente a capacidade de produzir um documento real e revisável acabou sendo uma pequena mudança com um grande retorno:
- Adicione um servidor MCP (~5 linhas).
- Peça o documento em inglês simples.
- Receba um link editável que um humano pode aprovar antes de ser enviado.
Sem manipulação de markdown para PDF, sem navegador sem cabeça, e um passo de revisão embutido em vez de autonomia cega.
Se você está construindo agentes que produzem entregáveis (não apenas texto): você deixa o agente finalizar, ou sempre entrega a um humano para revisar primeiro? Estou genuinamente curioso sobre como outros estão traçando essa linha — deixe nos comentários.
A implementação do MCP para geração de PDFs pode transformar a forma como empresas brasileiras produzem documentos. Isso garante que a qualidade e a precisão sejam mantidas, minimizando erros. A solução proposta é prática e acessível, facilitando a adoção de agentes de IA nas operações diárias.

