Shager no Cursor com .cursor/mcp.json: release notes viram rascunhos para todas as contas do cliente

Configure o servidor MCP remoto do Shager no Cursor com uma url e um header Authorization vindo do ambiente, e transforme um changelog em rascunhos por conta.

Para conectar o Shager ao Cursor, crie um .cursor/mcp.json no seu projeto (ou ~/.cursor/mcp.json, para valer em todos os projetos) com uma entrada shager cuja url seja https://app.shager.ai/api/mcp e cujos headers definam Authorization como Bearer ${env:SHAGER_API_KEY}. O Cursor resolve a variável a partir do seu ambiente, conecta via HTTP, e o agente ganha as ferramentas do Shager. Sem servidor local, sem ponte.

O Cursor é um lugar interessante para cuidar da distribuição porque a matéria-prima já está no repositório: changelogs, documentação, release notes, rascunhos de blog. Este guia configura a conexão do jeito certo e depois a coloca para fazer exatamente esse trabalho.

Como fica a configuração MCP do Cursor para um servidor remoto?

A documentação de MCP do Cursor mostra um servidor remoto como uma url mais um objeto headers opcional, e documenta a interpolação ${env:NAME} nos campos url e headers. Ela também indica dois locais: .cursor/mcp.json dentro de um projeto, para ferramentas específicas dele, e ~/.cursor/mcp.json na sua pasta pessoal, para ferramentas disponíveis em qualquer lugar.

Para o Shager:

{
  "mcpServers": {
    "shager": {
      "url": "https://app.shager.ai/api/mcp",
      "headers": {
        "Authorization": "Bearer ${env:SHAGER_API_KEY}"
      }
    }
  }
}

E no perfil do seu shell:

export SHAGER_API_KEY="shgr_live_your_key_here"

O Cursor lê as variáveis de ambiente do processo que o abriu. No macOS, um app aberto pelo Dock pode não enxergar variáveis definidas no ~/.zshrc. Se o servidor falhar com 401 mesmo com a chave certa, feche o Cursor e abra-o a partir de um terminal com cursor . para confirmar se a causa é essa.

mcp.json do Cursor com um servidor shager, sua URL e um cabeçalho Authorization que lê a chave de uma variável de ambiente.
O mesmo arquivo funciona por projeto ou de forma global.

Arquivo do projeto ou arquivo global?

Local Bom para Cuidado com
.cursor/mcp.json no repositório Um repositório de site de marketing ou de documentação, onde o trabalho de conteúdo acontece Commite só no formato ${env:...}, nunca com a chave escrita
~/.cursor/mcp.json Você quer o Shager disponível em todos os workspaces O agente de qualquer projeto passa a alcançar seus espaços de trabalho no Shager

Para o desenvolvedor de agência que mantém vários sites de clientes, o arquivo do projeto costuma ser a melhor escolha. O repositório do cliente A não deveria ter um agente capaz de criar, sem querer, rascunhos no espaço de trabalho do cliente B. Combine o arquivo do projeto com uma chave cuja organização só tenha os espaços de trabalho que fazem sentido para aquele repositório, ou pelo menos cite os espaços de trabalho pelo nome nos seus prompts.

De onde vem a chave?

Uma pessoa cria a chave em https://app.shager.ai/dashboard/agents e escolhe os escopos. Para trabalhar dentro de um editor, read mais write é o padrão certo: o agente consegue enviar mídia e criar rascunhos, mas o Shager se recusa a agendar ou publicar sem o escopo publish. Se você está prototipando e ainda não tem conta, um agente pode criar um ambiente de teste pelo autocadastro; a receita está publicada em shager.ai/auth.md.

Como confirmar que o Cursor está vendo as ferramentas?

Abra as configurações de MCP do Cursor e procure o shager com status conectado e a lista de ferramentas: whoami, list_workspaces, create_workspace, list_channels, create_connect_link, list_groups, create_group, upload_media_from_url, create_post, schedule_post, request_approval, get_post, list_posts, cancel_post e get_analytics. Se o servidor mostrar erro, as três causas mais comuns são uma variável de ambiente ausente, a falta do Bearer no valor do header ou um erro de sintaxe no JSON.

Depois, no chat do agente:

Chame o whoami do shager e me diga quais escopos esta chave tem.
Diagrama: briefing, rascunho por conta, aprovação do cliente, publicação escalonada e relatório de cliques por conta.
Cinco etapas fixas. A aprovação de cada post é opcional por cliente; para publicar, é preciso uma pessoa como dona e uma permissão de publicação separada na chave.

O fluxo: um changelog vira rascunhos por conta

Aqui vai um trabalho concreto que combina bem com o Cursor. Imagine que você mantém o site de uma revenda de software com doze páginas de parceiros regionais no Facebook e no Instagram. A cada versão, alguém reescreve o changelog à mão em forma de posts. Com o Shager conectado, o agente pode fazer a primeira versão.

Leia o CHANGELOG.md e pegue só a entrada da v4.2.
No espaço de trabalho do Shager "Brightline Partners":
1. list_groups e use o grupo "Regional partners".
2. list_channels para saber o nome e a rede de cada canal.
3. Escreva um post curto sobre a v4.2 para um público não técnico.
4. Crie um RASCUNHO com create_post (sem schedule_at):
   group_ids: o grupo "Regional partners"
   per_channel: uma legenda por canal que cite a região a partir do nome do
   canal e varie a frase de abertura; mantenha os fatos idênticos
   cta_url: https://brightline.example/releases/4-2
   campaign: "release-4-2"
   first_comment: "Notas completas: " seguido do link
5. Mostre o id do post e uma tabela com canal, primeira linha da legenda e formato.

Algumas escolhas desse prompt são propositais.

Os fatos ficam idênticos e a redação varia. O per_channel substitui a legenda de cada conta, que é o padrão recomendado. Doze cópias do mesmo texto em páginas relacionadas é justamente o tipo de repetição contra o qual alerta nosso texto sobre como evitar bloqueios por spam ao publicar em escala, além de pegar mal para quem segue duas dessas páginas.

O link é rastreado por conta. Informar a cta_url faz o Shager criar um link curto e um conjunto de UTMs separados para cada conta, com o utm_content identificando a conta. Depois, o get_analytics devolve os cliques por conta e por post, e o parceiro de cada região consegue ver o que a página dele gerou.

O resultado é um rascunho. Alguém ainda lê tudo no Shager antes de sair, seja um revisor interno, seja o cliente por um link de aprovação.

E se você preferir chamar a API pelo código?

Às vezes você quer isso como um script no repositório, e não como um chat. Um fluxo de release no CI, por exemplo, não deveria depender de alguém abrir o Cursor. As mesmas operações estão disponíveis via REST, descritas no documento OpenAPI. O equivalente ao passo 4 acima, em TypeScript:

const API = "https://app.shager.ai/api/v1";
const headers = {
  Authorization: `Bearer ${process.env.SHAGER_API_KEY}`,
  "Content-Type": "application/json",
};

const res = await fetch(`${API}/workspaces/${workspaceId}/posts`, {
  method: "POST",
  headers,
  body: JSON.stringify({
    caption: defaultCaption,
    group_ids: [groupId],
    per_channel: captions.map((c) => ({ channel_id: c.channelId, caption: c.text })),
    cta_url: "https://brightline.example/releases/4-2",
    campaign: "release-4-2",
    first_comment: "Full notes: https://brightline.example/releases/4-2",
  }),
});

const body = await res.json();
if (!res.ok) throw new Error(`${body.error.code}: ${body.error.message}`);
console.log(body.data.id, body.data.status); // a DRAFT post

As respostas vêm dentro de { "data": ... } e os erros em { "error": { "code", "message" } }, então o tratamento de erros é igual em todo lugar. O guia rápido da API REST cobre a sequência completa.

Regras que valem a pena adicionar ao projeto

O Cursor aceita regras de projeto, e uma regra curta evita repetir restrições em todo prompt. Algo como:

Ao usar o servidor MCP shager:
Nunca informe schedule_at, a menos que eu dê explicitamente uma data e um horário.
Sempre use legendas per_channel ao publicar em mais de uma conta.
Sempre informe cta_url para qualquer link, em vez de colar URLs soltas nas legendas.
Use ISO 8601 com offset para qualquer horário, no fuso do espaço de trabalho.

Regras orientam o modelo, mas não obrigam. Quem obriga é o escopo da chave. Deixe o publish fora da chave do editor e a primeira regra não pode ser quebrada, nem se o modelo ignorá-la.

Perguntas frequentes

O Cursor funciona com o Shager sem OAuth?

Funciona. O Cursor envia os headers que você configurar, então a chave de API bearer funciona direto. O servidor MCP do Shager também aceita login via OAuth para os clientes que preferem esse caminho, mas no Cursor a chave basta.

Posso usar a mesma chave no Cursor e no Claude Code?

Pode, mas chaves separadas são melhores. Cada chamada entra no registro de auditoria do Shager com a chave que a fez, e chaves separadas permitem revogar uma ferramenta sem quebrar a outra. A configuração do Claude Code tem um guia próprio nesta série.

O agente vai postar na hora se eu disser "publique isto"?

Só se a chave tiver o escopo publish, a conta tiver sido assumida por uma pessoa e o espaço de trabalho não exigir antes a aprovação do cliente. Com uma chave de leitura e escrita, o pedido falha com um 403 claro e nada é publicado.

Próximo passo

Quando a conexão estiver funcionando, o ganho maior vem de um procedimento repetível, e não de prompts engenhosos. Leia como criar uma skill do Claude para o Shager para entender a estrutura, já que as mesmas instruções funcionam bem como regras do Cursor, e deixe a página para agentes aberta como referência de todas as ferramentas e campos.

Experimente nas suas próprias contas.

Grátis durante o lançamento, sem cartão. Conecte, escreva uma vez, e o Shager publica e mede.