Shager in Cursor con .cursor/mcp.json: dalle release note alle bozze per ogni account cliente

Configura il server MCP remoto di Shager in Cursor con un url e un header Authorization da variabile d'ambiente, poi trasforma un changelog in bozze.

Per collegare Shager a Cursor, crea .cursor/mcp.json nel tuo progetto (oppure ~/.cursor/mcp.json per tutti i progetti) con una voce shager il cui url è https://app.shager.ai/api/mcp e i cui headers impostano Authorization su Bearer ${env:SHAGER_API_KEY}. Cursor risolve la variabile dal tuo ambiente, si collega via HTTP e l'agente riceve i tool di Shager. Nessun server locale, nessun ponte.

Cursor è un posto interessante da cui gestire la distribuzione dei contenuti, perché il materiale di partenza è già nel repository: changelog, documentazione, release note, bozze del blog. Questa guida imposta il collegamento come si deve e poi lo usa proprio per questo lavoro.

Com'è la configurazione MCP di Cursor per un server remoto?

La documentazione MCP di Cursor rappresenta un server remoto come un url più un oggetto headers facoltativo, e documenta l'interpolazione ${env:NAME} nei campi url e headers. Indica anche due posizioni: .cursor/mcp.json in un progetto, per i tool specifici di quel progetto, e ~/.cursor/mcp.json nella tua cartella home, per i tool disponibili ovunque.

Per Shager:

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

E nel profilo della shell:

export SHAGER_API_KEY="shgr_live_your_key_here"

Cursor legge le variabili d'ambiente dal processo che lo ha avviato. Su macOS, un'app aperta dal Dock potrebbe non vedere le variabili impostate in ~/.zshrc. Se il server fallisce con un 401 anche se la chiave è corretta, chiudi Cursor e avvialo da un terminale con cursor . per verificare che la causa sia questa.

mcp.json di Cursor con un server shager, il suo URL e un'intestazione Authorization che legge la chiave da una variabile d'ambiente.
Lo stesso file funziona per progetto o a livello globale.

File di progetto o file globale?

Posizione Ideale per Attenzione a
.cursor/mcp.json nel repository Un sito marketing o un repository di documentazione dove si lavora ai contenuti Fai commit solo nella forma ${env:...}, mai con la chiave in chiaro
~/.cursor/mcp.json Vuoi Shager disponibile in ogni workspace L'agente di qualsiasi progetto può ora raggiungere le tue aree di lavoro Shager

Per uno sviluppatore d'agenzia che gestisce i siti di più clienti, di solito il file di progetto è la scelta migliore. Nel repository del cliente A non dovrebbe esserci un agente in grado di preparare, così per caso, bozze nell'area di lavoro del cliente B. Abbina il file di progetto a una chiave la cui organizzazione contiene solo le aree di lavoro sensate per quel repository, o almeno indica esplicitamente il cliente nei prompt.

Da dove arriva la chiave?

La crea una persona su https://app.shager.ai/dashboard/agents, scegliendo gli ambiti. Per lavorare dentro un editor, read più write è l'impostazione predefinita giusta: l'agente può caricare file multimediali e creare bozze, ma Shager rifiuta di programmare o pubblicare senza l'ambito publish. Se stai facendo un prototipo e non hai ancora un account, un agente può creare un ambiente di prova con la registrazione autonoma; la procedura è pubblicata su shager.ai/auth.md.

Come verifichi che Cursor veda i tool?

Apri le impostazioni MCP di Cursor e cerca shager con lo stato collegato e il suo elenco di tool: 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 il server mostra un errore, le tre cause tipiche sono una variabile d'ambiente mancante, la parola Bearer assente dal valore dell'header oppure un errore di sintassi JSON nel file.

Poi, nella chat dell'agente:

Call shager whoami and tell me which scopes this key has.
Schema: brief, bozza per account, approvazione del cliente, pubblicazione scaglionata e report dei clic per account.
Cinque fasi fisse. L'approvazione di ogni post è facoltativa per ciascun cliente; per pubblicare servono una persona come proprietario e un permesso di pubblicazione separato sulla chiave.

Il flusso: un changelog diventa bozze per ogni account

Ecco un lavoro concreto che si adatta bene a Cursor. Mettiamo che tu gestisca il sito di un rivenditore di software con dodici pagine regionali dei partner su Facebook e Instagram. A ogni release qualcuno riscrive a mano il changelog in post per i social. Con Shager collegato, la prima stesura può farla l'agente.

Read CHANGELOG.md and take the entry for v4.2 only.
In Shager workspace "Brightline Partners":
1. list_groups and use the group "Regional partners".
2. list_channels so you know each channel's name and network.
3. Write one short post about v4.2 for a non-technical audience.
4. Create a DRAFT with create_post (no schedule_at):
   group_ids: the "Regional partners" group
   per_channel: a caption per channel that names the region from the channel
   name and varies the opening line; keep facts identical
   cta_url: https://brightline.example/releases/4-2
   campaign: "release-4-2"
   first_comment: "Full notes: " followed by the link
5. Print the post id and a table of channel, caption first line, format.

Alcune scelte in quel prompt sono intenzionali.

I fatti restano identici, la formulazione cambia. per_channel sostituisce il testo per ogni account, ed è lo schema consigliato. Dodici copie dello stesso testo su pagine collegate tra loro sono proprio il tipo di ripetizione da cui mette in guardia il nostro articolo su come evitare i blocchi per spam quando pubblichi su larga scala, e fanno una brutta impressione a chiunque segua due di quelle pagine.

Il link è tracciato per account. Passando cta_url, Shager crea un link breve e una serie di parametri UTM separati per ogni account, con utm_content che lo identifica. In seguito get_analytics restituisce i clic per account e per post, così il partner di una regione vede quanto ha portato la sua pagina.

Il risultato è una bozza. Qualcuno la legge comunque in Shager prima che esca: un revisore interno oppure il cliente, tramite un link di approvazione.

E se preferisci chiamare l'API dal codice?

A volte questo lavoro lo vuoi come script nel repository, non come chat. Un flusso di release in CI, per esempio, non dovrebbe dipendere da qualcuno che apre Cursor. Le stesse operazioni sono esposte via REST e descritte nel documento OpenAPI. L'equivalente del passo 4 qui sopra in 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

Le risposte sono racchiuse in { "data": ... } e gli errori in { "error": { "code", "message" } }, quindi la gestione degli errori è uguale ovunque. Il quickstart REST copre la sequenza completa.

Regole da aggiungere al progetto

Cursor supporta le regole di progetto, e una regola breve ti evita di ripetere i vincoli in ogni prompt. Qualcosa del genere:

When using the shager MCP server:
Never pass schedule_at unless I explicitly give a date and time.
Always use per_channel captions when posting to more than one account.
Always pass cta_url for any link instead of pasting raw URLs into captions.
Use ISO 8601 with an offset for any time, in the workspace timezone.

Le regole sono indicazioni per il modello, non un obbligo tecnico. Il vero blocco è l'ambito della chiave. Tieni publish fuori dalla chiave dell'editor e la prima regola non potrà essere violata, anche se il modello la ignora.

Domande frequenti

Cursor supporta Shager senza OAuth?

Sì. Cursor invia qualsiasi header tu configuri, quindi la chiave API bearer funziona direttamente. Il server MCP di Shager supporta anche l'accesso OAuth per i client che lo preferiscono, ma in Cursor basta la chiave.

Posso usare la stessa chiave in Cursor e in Claude Code?

Puoi, ma è meglio usare chiavi separate. Ogni chiamata finisce nel registro di audit di Shager sotto la chiave che l'ha eseguita, e con chiavi separate puoi revocarne una senza bloccare l'altro strumento. La configurazione di Claude Code ha una guida dedicata in questa serie.

L'agente pubblica subito se gli dico «pubblica questo»?

Solo se la chiave ha l'ambito publish, l'account è stato rivendicato da una persona e l'area di lavoro non richiede prima l'approvazione del cliente. Con una chiave read e write, la richiesta fallisce con un 403 chiaro e non esce nulla.

Prossimo passo

Una volta che il collegamento funziona, il vantaggio più grande è una procedura ripetibile, non prompt ingegnosi. Leggi come creare una skill di Claude per Shager per la struttura, dato che le stesse istruzioni si traducono bene in regole di Cursor, e tieni aperta la pagina sugli agenti come riferimento per ogni tool e campo.

Provalo sui tuoi account.

Gratis durante il lancio, senza carta. Collega, scrivi una volta e Shager pubblica e misura.