Sfoglia la documentazione
MCP server

Server MCP

L'endpoint MCP remoto: URL, le due modalità di autenticazione, e cosa vede un client alla connessione.

BoostEcom esegue un server MCP remoto, un endpoint per store connesso. È la superficie tramite cui un client IA legge uno store Shopify e i dati BoostEcom a esso collegati.

Solo lettura. Ogni strumento del catalogo è una lettura, compreso quello che accetta un documento GraphQL: shopifyAdminGraphQL esegue le query e rifiuta le mutation, per nome, nell'handler. Una scrittura su uno store in produzione è una decisione che qualcuno deve approvare, e in un relay non c'è nessuno: un client IA chiama, la chiamata arriva, niente sta in mezzo. Finché non esiste un percorso di approvazione, rifiutare è l'unica risposta che non può modificare in silenzio il catalogo di un cliente.

L'endpoint

https://boostecom.app/api/mcp/v1/<storeId>

La forma senza versione, /api/mcp/<storeId>, è stata rilasciata per prima ed è mantenuta nella configurazione di ogni client installato da allora. Resta, esattamente com'è. Le due sono un unico endpoint con due nomi: gli stessi handler, e un token generato tramite l'uno funziona sull'altro.

Usa il percorso v1 per tutto ciò che è nuovo.

Due modalità di autenticazione

| Modalità | Credenziale | Famiglie di strumenti che apre | |---|---|---| | OAuth 2.1 PKCE | Token di accesso da /oauth/authorize | Relay e native. | | Statica | Bearer bst_mcp_ | Solo relay: i 15 strumenti relay, entro i permessi Shopify dello store. |

L'asimmetria è deliberata ed è spiegata in Strumenti e scope MCP.

Una chiave statica non porta alcuna stringa di scope: viene letta come la concessione ereditata, che si espande alla famiglia relay e a nient'altro. Ne seguono due conseguenze. Gli strumenti di documentazione public, searchDocs e getDoc, ammetterebbero un chiamante che il relay non sa nominare, ma una chiave statica non nomina mai il loro scope: non vengono registrati per lei e raggiungono un client solo tramite OAuth. E gli strumenti native non vengono mai registrati per una chiave statica, qualunque sia la concessione, perché richiedono un chiamante identificato.

Cosa blocca uno strumento

Tre porte, e uno strumento deve superarle tutte per essere registrato in una data sessione:

  1. Lo scope BoostEcom approvato: ciò a cui l'utente ha acconsentito.
  2. Gli scope Shopify dello store: un tetto rigido. Se la Custom App o l'installazione OAuth non ha mai ottenuto read_orders, nessuno scope BoostEcom lo evoca.
  3. Un chiamante identificato: richiesto solo dagli strumenti native, perché il loro permesso dipende da un'appartenenza a un'organizzazione e non c'è nessuno da verificare in modalità statica.

Uno strumento che fallisce a una qualsiasi porta non viene registrato: non compare affatto nell'elenco degli strumenti del client, invece di comparire e fallire alla chiamata. Questo è il comportamento corretto per un client IA: uno strumento che può vedere è uno strumento che proverà.

Collegare un client

Quattro client hanno una guida passo passo:

Ognuna fornisce l'URL, la modalità di autenticazione supportata da quel client, e uno snippet di configurazione pronto da incollare.

Scoperta degli agenti

La piattaforma pubblica un profilo agente UCP su /.well-known/ucp-agent. Dichiara capacità di lettura del catalogo e non porta segreti. È ciò che ogni store Shopify che interroghiamo legge per negoziare le nostre capacità prima di rispondere.

Successivo

Hai costruito con queste docs?

Passa dal forum se qualcosa non è chiaro o è sbagliato. La documentazione migliora più in fretta quando chi legge segnala le lacune.

Apri il forum