Collaudo dell'integrazione MCP remota: cosa dimostra la discovery e cosa resta da verificare

Aggiornamento sullo stato del prodotto (verificato il 2026-10-09, ora di Pechino): l'elenco di sei strumenti in questo articolo è un'osservazione storica del 2026-09-04. everyinfra_chat è stato ritirato insieme all'API di testo generica il 2026-09-12. Ora è di nuovo disponibile con l'API per l'AI (gratuita dopo una ricarica, senza streaming). Gli strumenti di pulizia dei dati sono stati dismessi. Ricava sempre l'elenco aggiornato degli strumenti dalla discovery MCP in tempo reale (tools/list).

Inserire un indirizzo MCP in un client e vedere comparire i nomi degli strumenti è un passo avanti utile. Però non dice ancora se le chiavi vengono passate correttamente o se le chiamate effettive rientrano negli ambiti consentiti. Non dice neppure se il client riconosce gli errori e se i dati restituiti soddisfano i requisiti del task.

Prendendo come esempio l'endpoint remoto di EveryInfra, questo documento divide il collaudo dell'integrazione in quattro livelli. Sono discovery del protocollo, corrispondenza dell'autenticazione, funzionamento nel client e risultati di business. Prima fornisce un probe di discovery senza chiave. Poi spiega perché per tre client diversi non vale un'unica affermazione del tipo «basta inserire l'indirizzo». È una guida all'integrazione con limiti testati. Non dichiara che Claude, ChatGPT e Cursor siano stati tutti installati con successo.

Un solo indirizzo remoto, quattro livelli di prova indipendenti

Il punto di ingresso verificato qui è https://api.everyinfra.com/mcp. La discovery del protocollo ci dice come il server si descrive e quali strumenti espone. La corrispondenza dell'autenticazione chiarisce come il client ottiene e trasmette credenziali approvate. Il collaudo nel client verifica se gli strumenti sono effettivamente disponibili nella sessione corrente. Il collaudo di business verifica risultati ed errori effettivi.

I quattro livelli vanno registrati separatamente. Se un server risponde all'inizializzazione, non significa che il client abbia accettato le notifiche successive. Se un client vede il catalogo, non significa che abbia permessi di business. Se uno strumento restituisce contenuti, non significa che non ci siano errori di business. Non usare un unico valore booleano «connessione riuscita» per coprire tutti i casi.

Allo stesso modo, MCP e REST sono modalità di integrazione diverse. I campioni REST aiutano a verificare la semantica di business. Da soli, però, non dimostrano che un client gestisca correttamente autenticazione MCP, blocchi di contenuto, errori o flussi di conferma.

Dopo l'inizializzazione c'è anche una notifica

Questo testo verifica il percorso di discovery rispetto alla versione 2025-06-18 di MCP. Non sostiene che sia la versione più recente o l'unica per tutti i client. Il client invia prima initialize per controllare la versione scelta dal server. Poi invia notifications/initialized e solo dopo passa alla discovery degli strumenti. Le richieste HTTP successive devono includere la versione di protocollo negoziata. Ciclo di vita del protocollo

Quando una notifica Streamable HTTP viene accettata, il server deve restituire HTTP 202 senza corpo di risposta. Se durante l'inizializzazione il server restituisce Mcp-Session-Id, il client deve conservarlo nelle richieste successive. Senza quell'header di risposta non si può inventare una sessione. Le risposte alle richieste possono essere JSON o SSE, e i client reali devono supportare il formato di trasporto richiesto dal protocollo. Specifica del trasporto

Lo script seguente controlla solo il ramo di risposta JSON usato da questo server e non è un client MCP generico. Si ferma quando incontra SSE, cataloghi paginati o versioni non supportate, e lascia il resto del collaudo a un client completo. Non pretende che il parsing di un singolo oggetto JSON copra l'intero protocollo.

Uno script diagnostico solo per la discovery

Usa Node.js 22 o successivo, con il supporto integrato a fetch. Lo script non legge chiavi dall'ambiente, non invia tools/call e non installa né modifica alcun client. L'output contiene solo stato, nomi degli strumenti e problemi di compatibilità. Non stampa i testi promozionali presenti nelle descrizioni del server.

node --input-type=module <<'JS'
const endpoint = 'https://api.everyinfra.com/mcp';
const supportedVersion = '2025-06-18';
const headers = {
  'Content-Type': 'application/json',
  Accept: 'application/json, text/event-stream',
};
const issues = [];
async function post(message) {
  const response = await fetch(endpoint, {
    method: 'POST', headers, redirect: 'error',
    body: JSON.stringify(message),
    signal: AbortSignal.timeout(20000),
  });
  return { response, text: await response.text() };
}
function rpcResult(reply, id) {
  if (reply.response.status !== 200) {
    throw new Error('RPC HTTP ' + reply.response.status);
  }
  if (!reply.response.headers.get('content-type')?.includes('application/json')) {
    throw new Error('This probe only handles JSON; use a full MCP client');
  }
  const body = JSON.parse(reply.text);
  if (body.jsonrpc !== '2.0' || body.id !== id ||
      body.error || !body.result || typeof body.result !== 'object') {
    throw new Error('Invalid or failed RPC response');
  }
  return body.result;
}
const initReply = await post({
  jsonrpc: '2.0', id: 1, method: 'initialize',
  params: {
    protocolVersion: supportedVersion, capabilities: {},
    clientInfo: { name: 'bip-discovery-only', version: '1.0' },
  },
});
const init = rpcResult(initReply, 1);
if (init.protocolVersion !== supportedVersion ||
    init.serverInfo?.name !== 'EveryInfra' || !init.capabilities?.tools) {
  throw new Error('Unexpected version, server or tool capability');
}
headers['MCP-Protocol-Version'] = init.protocolVersion;
const session = initReply.response.headers.get('mcp-session-id');
if (session) headers['Mcp-Session-Id'] = session;
const notification = await post({
  jsonrpc: '2.0', method: 'notifications/initialized',
});
if (notification.response.status !== 202) {
  throw new Error('Initialization notification was not accepted');
}
const notificationBytes = Buffer.byteLength(notification.text);
if (notificationBytes !== 0) issues.push('notification_body_not_empty');
// Continue discovery for diagnosis only; never enter a business call.
const listed = rpcResult(await post({
  jsonrpc: '2.0', id: 2, method: 'tools/list', params: {},
}), 2);
if (!Array.isArray(listed.tools) || listed.tools.length === 0 ||
    listed.tools.some(tool => !tool.name || tool.inputSchema?.type !== 'object') ||
    listed.nextCursor) {
  throw new Error('Incomplete or unexpected tool list');
}
console.log(JSON.stringify({
  observedAt: new Date().toISOString(),
  protocolVersion: init.protocolVersion,
  sessionHeaderPresent: Boolean(session),
  notificationStatus: notification.response.status,
  notificationBodyBytes: notificationBytes,
  toolNames: listed.tools.map(tool => tool.name),
  issues,
  businessCallPerformed: false,
  hostAcceptanceVerified: false,
}, null, 2));
if (issues.length) process.exitCode = 2;
JS

Il codice di uscita 0 indica solo che questo controllo di discovery limitato non ha trovato discrepanze. Non significa affatto che il risultato sia pubblicabile o che il collaudo sui tre client sia superato. Il codice di uscita 2 indica che il catalogo è stato recuperato ma ci sono discrepanze di protocollo. Gli altri errori interrompono l'esecuzione. Gestisci separatamente gli errori di connessione e i problemi di compatibilità emersi dopo una discovery riuscita.

Cosa ha verificato con successo la discovery e quali problemi ha rilevato

Nella nuova verifica senza autenticazione del 4/9/2026 alle 20:43 (ora standard della Cina), l'inizializzazione ha restituito HTTP 200 e la versione del protocollo 2025-06-18, senza fornire un header di risposta con l'ID di sessione. Il catalogo degli strumenti ha restituito sei nomi:

• everyinfra_list_capabilities
• everyinfra_call_api
• everyinfra_chat
• everyinfra_list_captcha_types
• everyinfra_solve_captcha
• everyinfra_search

Tuttavia, quando la notifica di inizializzazione completata ha restituito HTTP 202, il corpo della risposta era il JSON null anziché vuoto. Questo non rispetta i requisiti di risposta alle notifiche della versione citata. Il catalogo resta leggibile, ma non basta a dimostrare che tutti i client tollereranno questa discrepanza. Lo script deve segnalarla esplicitamente anziché ignorarla in silenzio.

In questo ciclo non sono stati invocati strumenti di business. Non è stato nemmeno verificato se i client fallissero di conseguenza. Le discrepanze di risposta vanno gestite dai maintainer del servizio e poi ritestate nei client reali. L'affermazione supportata al momento è «sul percorso di discovery pubblico sono stati osservati sei strumenti, con una discrepanza nella risposta alle notifiche». Non si può trasformare in «pienamente compatibile con MCP».

Abbiamo eseguito di nuovo lo stesso processo di discovery gratuito il 2026-09-08. Il catalogo ha restituito otto strumenti: i due nuovi erano strumenti di pulizia dei dati. La notifica di inizializzazione completata ha restituito HTTP 202 con un corpo di risposta di 0 byte. Quindi la discrepanza del 4 settembre non si è ripresentata. Questo aggiornamento chiude soltanto le vecchie osservazioni a livello di discovery pubblica. Non significa che Claude, ChatGPT e Cursor abbiano completato l'autenticazione o chiamate di business reali.

Cursor: verifica il supporto degli header in configurazione separatamente dai permessi reali

La documentazione ufficiale di Cursor prevede le configurazioni url e headers per i server remoti, con interpolazione dalle variabili d'ambiente. Di seguito trovi la struttura di configurazione da usare dopo l'autorizzazione dell'utente. In questo ciclo non è stata scritta nelle configurazioni dell'utente e non sono state verificate chiamate reali dal client. Documentazione MCP di Cursor

{
  "mcpServers": {
    "everyinfra": {
      "url": "https://api.everyinfra.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:EVERYINFRA_API_KEY}"
      }
    }
  }
}

L'attuale codice del server del progetto include il parsing dell'header Bearer. La presenza di questo percorso nel sorgente, però, non dimostra che una determinata chiave sia utilizzabile oggi. Quando prepari l'integrazione reale, conferma che il processo del client possa leggere le variabili d'ambiente indicate. Verifica anche i permessi di business della chiave. Non scrivere valori reali in configurazioni sotto controllo di versione, screenshot o segnalazioni di errore.

Successivamente, aggiorna il catalogo nella versione corrente di Cursor, seleziona i singoli strumenti e mantieni l'obbligo di conferma da parte dell'utente. Non attivare l'esecuzione automatica per tutti gli strumenti solo perché il catalogo è visibile. Una chiave con permessi di business non va considerata un'autorizzazione permanente per ogni operazione.

Claude: i connettori remoti non passano dalla rete locale

La documentazione ufficiale di Claude sui connettori remoti specifica che le richieste partono dal cloud di Anthropic, anche per i connettori remoti di Claude Desktop. È un meccanismo diverso dalle configurazioni MCP locali nelle impostazioni dell'app desktop. Quindi, se un indirizzo è raggiungibile in locale, questo dimostra solo il percorso locale. Non dimostra che anche i connettori cloud possano raggiungerlo. Istruzioni sui connettori remoti di Claude

Per l'integrazione verifica i punti di accesso ai connettori in base ai permessi attuali dell'account e dell'organizzazione. Poi verifica i flussi di autenticazione supportati sia dal servizio sia dal client. Le configurazioni OAuth della documentazione ufficiale non si possono riformulare come «puoi inserire qualsiasi chiave API Bearer». Se i modelli di autenticazione non coincidono, prima bisogna progettare e collaudare servizi o soluzioni di adattamento controllate. Infilare i segreti negli URL non è un sostituto generico.

Qui non trovi screenshot dei passaggi né istruzioni del tipo «aggiungi ed è fatta» non verificate con questo account. Aggiungere connettori, autorizzarli e dare la conferma finale modificano lo stato dell'account. Sono passaggi da eseguire dopo l'approvazione dell'utente, e i probe di protocollo non sostituiscono questo tipo di prova.

ChatGPT e OpenAI API: due punti di integrazione diversi

La documentazione ufficiale sull'autenticazione MCP per i plugin di ChatGPT elenca tre opzioni: OAuth, nessuna autenticazione e autenticazione ibrida. Quella ibrida prevede una discovery non autenticata. Prevede poi la scelta del metodo di autenticazione in base alle dichiarazioni di sicurezza di ciascuno strumento. Una discovery senza chiave non equivale a poter invocare senza autenticazione tutti gli strumenti di business. ChatGPT Developer mode

In questo catalogo degli strumenti non sono stati osservati campi securitySchemes o _meta a livello di strumento. È un'osservazione su questa risposta, non un audit completo dell'implementazione dell'autenticazione dell'intero servizio. Basta però a mostrare una cosa: una discovery riuscita, da sola, non permette di affermare che i requisiti dell'autenticazione ibrida di ChatGPT siano soddisfatti.

La configurazione MCP remota per la Responses API di OpenAI è un ulteriore percorso. Include parametri come server_url, selezione degli strumenti, autenticazione e approvazione delle chiamate. Non si tratta di istruzioni di configurazione per l'interfaccia di ChatGPT. Costruire richieste tramite API non dimostra a posteriori che l'interfaccia web sia connessa. Guida OpenAI a MCP e connettori

In questo ciclo è stata controllata solo la documentazione. Non sono state eseguite richieste di business all'API di OpenAI e non è stata attivata la Developer mode per gli utenti. Se in seguito usi questo percorso, rivedi in modo indipendente l'ambito dei dati inviati ai servizi remoti. Mantieni anche i passaggi di approvazione per le chiamate sensibili.

Per progettare l'autenticazione consulta anche, in modo indipendente, il tutorial ufficiale MCP sulle best practice di sicurezza. La pagina si trova nel percorso della documentazione 2025-11-25. Spiega che i token devono essere destinati al servizio corretto e sconsiglia il passthrough di token non verificati. Non trasforma le chiavi di terze parti in credenziali MCP generiche. Non sostituisce nemmeno i controlli di discovery eseguiti sopra secondo la versione 2025-06-18.

Dopo l'HTTP 200 vanno controllati altri due livelli di risultato

In MCP gli errori di protocollo possono comparire nel campo error di primo livello di JSON-RPC. Gli errori di esecuzione degli strumenti possono essere espressi anche tramite result.isError. Un HTTP 200 o la presenza di un blocco di testo non bastano per dichiarare il successo di business. Specifica di strumenti ed errori

Nelle operazioni reali controlla anche le strutture dati restituite dagli strumenti. Verifica se l'output corrisponde agli oggetti attesi, se è vuoto o solo parzialmente completo e se i task asincroni richiedono ulteriori query. Gestisci i contenuti con più blocchi secondo la risposta documentata di ciascuno strumento. Non presumere che il primo blocco di testo contenga tutti i metadati. Fatturazione, consumi e saldi vanno controllati nelle risposte di business reali. La discovery dei cataloghi non prova l'avvenuta contabilizzazione delle chiamate di business.

Per operazioni come inviare, acquistare o sottoporre contenuti, e per altre operazioni con effetti collaterali, il fatto che un client mostri uno strumento non significa che l'utente ne abbia autorizzato l'esecuzione. Conferma destinatari e parametri prima della chiamata; prima di un nuovo tentativo, accertati che l'esito di quello iniziale sia noto. Il probe senza chiave di questo documento evita deliberatamente di entrare in questo livello.

Un registro di collaudo da consegnare al prossimo integratore

Per ogni client registra separatamente prodotto e versione, luogo di esecuzione e metodi di trasporto e autenticazione. Aggiungi le prove di installazione e autorizzazione, i nomi effettivi degli strumenti, gli input anonimizzati, lo stato dei risultati e gli errori. Registra orari di osservazione e ambiti di chiamata consentiti senza salvare le chiavi in chiaro. Documenta separatamente campioni riusciti, errori espliciti e risultati sconosciuti.

Per il metodo di registrazione puoi rifarti ai principi di correlazione degli eventi e di esclusione dei dati delle guide OWASP sul logging. Correla le singole operazioni ed evita di scrivere token, sessioni o contenuti completi dei clienti negli allegati di debug. I log sono solo una parte delle prove di collaudo. Non sostituiscono il controllo del comportamento reale del client.

In questo ciclo sono state completate la discovery pubblica e la verifica delle discrepanze nella documentazione. Restano da completare quattro punti. Il primo è la correzione delle risposte alle notifiche affinché abbiano il corpo vuoto. Il secondo riguarda l'installazione e l'autenticazione sui tre client. Il terzo riguarda le chiamate di business autorizzate e il quarto il collaudo della visualizzazione degli errori. Solo quando ciascun punto avrà le sue prove, il tutorial potrà passare da «configurazione in attesa di verifica» a «testato e superato nelle versioni indicate».

Esegui prima lo script di discovery di questo testo per confermare che le interfacce attuali e i record siano ancora coerenti. Poi procedi con i client scelti dal team. Non modificare tre account contemporaneamente. Non copiare configurazioni non verificate solo per mettere insieme un elenco di compatibilità. Punto di accesso alla documentazione di EveryInfra