Collega qualsiasi server MCP a Claude Code e Claude Desktop

Collegare un server MCP sia a Claude Code sia a Claude Desktop è più che copiare la stessa configurazione in due posti.

In Claude Code i server MCP si possono configurare su scope diversi, tra cui i livelli local, project e user. Una volta inserita la configurazione, può comunque servire un'approvazione prima di poter verificare che il server sia davvero connesso. Claude Desktop gestisce la cosa in modo diverso: i server MCP locali si possono caricare tramite Estensioni o la configurazione Developer, mentre i server remoti seguono un flusso di connessione separato. Di conseguenza, un server MCP che funziona in Claude Code non diventa automaticamente disponibile in Claude Desktop.

Un'altra fonte comune di confusione è trattare “added”, “approved”, “connected” e “able to complete the task” come se fossero la stessa cosa. Rappresentano fasi diverse.

“Added” significa soltanto che la configurazione è stata registrata. “Pending approval” significa che il server è ancora in attesa di autorizzazione. “Connected” significa che la connessione MCP è stata stabilita correttamente. Ma anche quando tutti questi passaggi funzionano come previsto, l'agente può comunque non riuscire a completare l'attività vera.

Questo vale in particolare per i server MCP che interagiscono con il browser. Il server può essere connesso e i suoi strumenti disponibili, ma l'attività può comunque fallire se il browser non ha la sessione di accesso necessaria, i cookies o altro stato di runtime. A quel punto la configurazione MCP può essere già corretta: il pezzo mancante è l'ambiente del browser.

Questo è il livello che ego (lite) è progettato per gestire. L'agente può continuare a lavorare dentro un ambiente browser reale che ha già lo stato richiesto dall'attività, comprese le sessioni di accesso esistenti e lo stato attuale della pagina. Invece di modificare ripetutamente una configurazione MCP che già funziona, l'agente può passare all'attività nel browser.

Quindi, quando risolvi problemi con MCP, non fermarti a controllare se il server mostra “Connected”. Individua quale livello sta davvero fallendo: Il server è stato aggiunto? È stato approvato? È connesso? E il browser ha lo stato necessario per completare l'attività?

Che cosa stai collegando davvero

Sul filo ci sono due parti, una per lato. Il client è l'app Claude: scopre gli strumenti, decide quando chiamarli e ti mostra il risultato. Il server è un processo separato o un endpoint remoto che possiede la capacità vera: un database, un sistema di ticketing, un filesystem, un browser. MCP in sé è solo il contratto tra loro, ed è per questo che vale la pena tenere dritto il vocabolario: nulla in questa guida dipende dal server che hai scelto, perché la meccanica di configurazione è identica per tutti.

Il protocollo in sé è definito su modelcontextprotocol.io, il riferimento per trasporti, capacità e il contratto client-server.

La conseguenza pratica è che i problemi di connessione quasi mai stanno nel server. Stanno nei tre punti in cui il client decide se avviarlo: quale file di configurazione ha letto, se riesce a raggiungere l'endpoint e se l'hai approvato. Tieni separati questi tre aspetti e il debug diventa una breve checklist invece di un pomeriggio intero.

Scegli lo scope prima di digitare qualsiasi cosa

Claude Code ti offre tre posti dove mettere la definizione di un server, e scegliere quello sbagliato è la causa più comune di un server che “sparisce”: si era connesso bene, ma in una cartella in cui non ti trovi più.

Lo scope local è quello predefinito. Usalo mentre provi un server di cui non sei sicuro e per tutto ciò che porta una credenziale che non vuoi in un repository. Scegli project quando il server appartiene davvero al codice (per esempio un server di gestione progetti per il repository di un team), perché quella voce viaggia con il checkout e ogni collega riceve una sola richiesta di approvazione. Scegli user per i server che riguardano te e non il codice: un server di note personali, un endpoint del tuo home lab, quello che usi in ogni sessione.

Un comportamento da interiorizzare prima di creare duplicati: quando lo stesso nome di server esiste in più di un posto, Claude Code si connette una volta sola e prende l'intera voce dalla fonte con precedenza più alta. L'ordine di precedenza è local, poi project, poi user, poi i server forniti dai plugin. I campi non vengono uniti, quindi una voce project che omette una chiave opzionale non viene corretta in silenzio da una voce user più completa; ciò che viene eseguito è l'intera voce project.

Aggiungi un server a Claude Code

Claude Code offre un unico comando con forme diverse a seconda di come viene distribuito il server. Un server remoto via HTTP è il caso più semplice, perché non c'è nulla da eseguire in locale:

# Remote server over HTTP (the recommended transport)
claude mcp add --transport http <name> <url>

# With an auth header
claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

Un server locale viene eseguito come processo figlio, quindi il comando e i suoi argomenti vengono dopo un doppio trattino. Quel separatore non è estetico: tutto ciò che segue viene passato al server senza modifiche, ed è questo che impedisce a Claude Code di interpretare i flag del server come propri.

# Local server as a child process
claude mcp add [options] <name> -- <command> [args...]

# Real shape, with an environment variable
claude mcp add --env API_KEY=your-key --transport stdio airtable \
  -- npx -y airtable-mcp-server

Quando il fornitore del server ti fornisce un frammento JSON (come accade nella maggior parte dei casi, perché lo stesso frammento funziona in ogni client MCP) puoi incollarlo direttamente invece di trascriverlo in flag. Passa l'oggetto dentro mcpServers, non il wrapper che lo racchiude:

claude mcp add-json weather-api \
  '{"type":"http","url":"https://api.weather.com/mcp","headers":{"Authorization":"Bearer token"}}'

Due flag vale la pena conoscerli, anche se nessuno dei due è obbligatorio. Il flag di scope decide dove finisce la voce, e si può scrivere in entrambi i modi:

claude mcp add --transport http stripe --scope local https://mcp.stripe.com
claude mcp add --transport http notion -s user https://mcp.notion.com/mcp

Due varianti dello stesso comando vengono spesso confuse. Il comando add semplice riscrive la voce indicata per intero, ed è ciò che vuoi quando un fornitore ha cambiato l'URL. La forma add-json prende lo stesso oggetto e lo mantiene come voce unica, ed è ciò che vuoi quando il server ha bisogno di più campi insieme:

Verifica che la connessione sia davvero attiva

Un add riuscito stampa la riga Added, e quella riga significa una cosa sola: la configurazione è stata scritta su disco. Non dice nulla sul fatto che il server venga eseguito. Il comando che risponde alla domanda vera è il comando list, che riporta uno stato di salute per ogni server: connesso, in attesa di autenticazione oppure connessione non riuscita:

Il riferimento a livello di comando per ogni sottocomando è la documentazione MCP ufficiale di Claude Code, che vale la pena leggere insieme a questa guida.

Per il server browser usato come esempio in questa guida, i passaggi di installazione e registrazione sono nella guida di configurazione di Playwright MCP per Claude Code e Cursor.

claude mcp list          # health status for every configured server
claude mcp get notion    # detail for one server, including its Issue line

Quando uno stato segnala un errore, il comando list aggiunge i dettagli dell'errore a quella riga, e la vista del singolo server li ripete su una riga Issue con lo stato HTTP o il codice di errore più il testo che il server ha restituito. Considera quel dettaglio la prova principale invece di rileggere il tuo JSON. Il testo che assomiglia a una credenziale viene oscurato e l'URL espanso non viene mai incluso di proposito, perché un URL può portare un segreto nella sua query string.

Non tutti gli stati derivano da un tentativo di connessione. Alcuni segnalano una decisione di configurazione e Claude Code li stampa senza contattare affatto il server. Un server con scope project che arriva dal file condiviso resta in attesa di approvazione finché non esegui una volta il client interattivo e accetti la richiesta. Un server indicato come disattivato nelle impostazioni appare come disattivato per questo progetto e torna dal pannello dell'app. Un server rifiutato da una voce delle impostazioni compare nella vista del singolo server ma non nella list, una distinzione utile quando un server che sai di aver aggiunto sembra svanito.

Su tutto questo c'è un cancello di attendibilità. I comandi list e di dettaglio leggono le approvazioni del file di progetto condiviso solo dalle impostazioni non committate nel repository, finché non dichiari attendibile lo workspace eseguendo il client lì e accettando la finestra di attendibilità. Un repository clonato non può approvare i propri server: un elenco di server pre-approvati committato nelle impostazioni del progetto viene ignorato in una cartella non attendibile, e il server resta in attesa di approvazione invece di essere sottoposto al controllo di salute. È una difesa deliberata, non un bug, ed è il motivo per cui un clone appena fatto sembra aver perso i tuoi server.

I server WebSocket sono l'eccezione a tutto quanto sopra: non compaiono affatto nell'output di list. Usa la vista del singolo server o il pannello dell'app per controllarli.

Aggiungi lo stesso server a Claude Desktop

Desktop è di un'altra specie, e il cambiamento che manda in confusione è che il suo percorso principale documentato per i server locali non è più un file JSON. Il flusso attuale è fatto di estensioni pacchettizzate: apri Impostazioni, vai su Estensioni, sfoglia la directory oppure usa la sezione sviluppatore per installare un .mcpb.mcpb già pronto, poi compila le impostazioni richieste dal pacchetto. I valori obbligatori come le chiavi API vengono raccolti tramite l'interfaccia, con i campi sensibili cifrati dal deposito sicuro del sistema operativo. Le estensioni della directory si aggiornano da sole; una distribuita privatamente richiede una reinstallazione manuale quando esce una nuova versione.

Se un fornitore ti fornisce ancora un frammento JSON e nessun pacchetto, la via manuale non è sparita: si è spostata. Apri il menu dell'app desktop, scegli Impostazioni, poi Developer, e usa il controllo di modifica della configurazione, che crea il file se non esiste e lo apre se esiste. Su macOS quel file si trova in ~/Library/Application Support/Claude/claude_desktop_config.json; su Windows si trova in %APPDATA%\Claude\claude_desktop_config.json. La maggior parte dei server locali viene avviata tramite npx e richiede Node.js installato, e l'app legge il file solo all'avvio, quindi chiudere del tutto e riavviare fa parte della procedura e non è un passaggio scaramantico in più.

I server remoti seguono il terzo percorso, ed è davvero remoto in senso di rete: Claude raggiunge il server dal cloud di Anthropic, non dal tuo dispositivo. Questo ha due conseguenze che le persone scoprono a proprie spese. Il tuo server deve essere raggiungibile pubblicamente, quindi un servizio legato a una rete privata deve avere i suoi intervalli in allowlist prima di potersi connettere. E il connettore si autentica con OAuth invece che con un percorso di file, ed è per questo che un connettore remoto può funzionare su una macchina che non ha mai eseguito il codice del server.

Per gli account individuali il percorso è la schermata dei connettori nelle impostazioni di personalizzazione, dove aggiungi un connettore personalizzato e incolli l'URL del server; una sezione avanzata accetta un client ID e un secret OAuth quando il server non supporta la registrazione dinamica dei client. Con un piano organizzazione, un proprietario aggiunge il connettore a livello di organizzazione e poi i membri si autenticano singolarmente. Si applicano i limiti del piano (un account gratuito è limitato a un solo connettore personalizzato) e un connettore appare come personalizzato a meno che il suo dominio corrisponda a una voce della directory.

La struttura di configurazione su cui concordano le due app

Sotto le diverse superfici, la voce è lo stesso oggetto. Un server remoto è un type, un URL e header opzionali. Un server locale è un comando, i suoi argomenti e un blocco environment opzionale. Questa è la struttura con cui confrontarti quando la documentazione di un fornitore e il tuo file non concordano:

{
  "mcpServers": {
    "remote-example": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" }
    },
    "local-example": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@example/mcp-server"],
      "env": { "CACHE_DIR": "/tmp" }
    }
  }
}

Tre dettagli di quell'oggetto causano la maggior parte degli errori evitabili. Una voce stdio con un percorso relativo nel comando si rompe nel momento in cui cambia la directory di lavoro, quindi usa percorsi assoluti. Un percorso Windows dentro una stringa JSON ha bisogno di backslash con escape, altrimenti il file viene analizzato come una stringa malformata. E una voce remota senza alcun type viene letta come server locale, il che produce un errore confuso su un comando mancante invece che sull'URL.

Dove le due app divergono è nella denominazione. Claude Code richiede nomi fatti di lettere, numeri, trattini e underscore, mentre una chiave di configurazione desktop è più tollerante. Mantenere il nome identico in entrambi i posti è il modo più economico per non confondere i tuoi appunti.

Credenziali, variabili e la trappola in ${VAR}

Scrivere un token in chiaro dentro un file di configurazione è il modo in cui i segreti finiscono in un repository, per questo le configurazioni MCP supportano l'espansione delle variabili. La sintassi ha due forme, una semplice e una con valore predefinito, e l'espansione copre il comando, i suoi argomenti, il blocco environment, l'URL e gli header:

{
  "mcpServers": {
    "api-server": {
      "type": "http",
      "url": "${API_BASE_URL:-https://api.example.com}/mcp",
      "headers": { "Authorization": "Bearer ${API_KEY}" }
    }
  }
}

Il comportamento quando manca una variabile è il punto in cui si nasconde la trappola, ed è diverso per le due categorie di variabile. Una variabile ordinaria non impostata e senza valore predefinito non rompe la configurazione: il server si carica comunque, l'elenco di salute segnala per essa un avviso di variabile mancante e il testo non espanso viene usato come valore letterale. Quell'avviso è l'indizio, ed è facile lasciarlo scorrere.

Un insieme specifico di variabili di credenziali si comporta diversamente nell'URL e negli header di un server remoto: vengono lette come vuote, senza alcun avviso, e un valore predefinito associato a esse viene ignorato. La differenza pratica è che la prima categoria fallisce in modo rumoroso e la seconda in modo silenzioso: ottieni una richiesta non autenticata e qualunque errore restituisca l'altro capo, senza nulla nella tua configurazione che indichi la causa. Se un server remoto segnala errori di autenticazione mentre le tue variabili sembrano impostate correttamente, controlla l'ambiente effettivo ereditato dal processo client prima di controllare il token stesso.

Esiste una seconda regola, più ristretta, per le voci con scope project: fare riferimento alla variabile della directory di progetto in un comando o in un argomento richiede che tu le fornisca un valore predefinito, perché non è garantito che il valore sia impostato nel momento in cui la voce viene letta. Le configurazioni fornite dai plugin la sostituiscono direttamente e non sono soggette allo stesso requisito.

Risolvere i problemi di connessione

Procedi dall'esterno verso l'interno, in quattro passaggi: il server si avvia, il trasporto lo raggiunge, l'handshake si completa e l'agente riesce davvero a fare il lavoro. Ogni passaggio ha un sintomo distinto, e l'ordine conta perché un errore nel primo fa sembrare rotto anche tutto ciò che viene dopo.

Per la stessa diagnosi applicata nello specifico a un server browser, Chrome DevTools MCP: configurazione, sessioni esistenti e soluzioni ripercorre in ordine i problemi di connessione e di profilo.

Il server non si avvia. Prendi il comando e gli argomenti fuori dalla configurazione e eseguili in un terminale normale. Se falliscono lì, nessuna impostazione del client li sistemerà: manca un runtime, il nome del pacchetto è sbagliato oppure il percorso non esiste. Solo questo passaggio risolve buona parte delle segnalazioni sui server locali, perché elimina del tutto il file di configurazione dall'equazione.

Il trasporto non riesce a raggiungere il server. Per un endpoint remoto, verifica che l'URL sia il percorso MCP e non la radice del servizio, poi verifica che la credenziale arrivi davvero. Un 401 o 403 dall'altro capo è il segnale più chiaro di tutta questa guida: il client ha raggiunto il server e il server ha rifiutato il chiamante, il che ti porta dritto alla sezione sulle credenziali qui sopra. Un connection refused o un errore di risoluzione indica la direzione opposta, cioè l'indirizzo o un firewall.

L'handshake si blocca o l'elenco degli strumenti torna vuoto. Un server che si avvia ma non conclude mai il suo primo scambio di solito è lento, non guasto. Il client applica un timeout di avvio ai server MCP, e il download npx a freddo di un pacchetto di grandi dimensioni può superarlo alla prima esecuzione: esegui il server manualmente una volta in modo che il pacchetto sia in cache, poi riprova. Un server che si connette ma non espone alcuno strumento è un problema diverso: si è avviato con successo e non ha pubblicizzato nulla, il che di solito significa che ha bisogno di una configurazione passata attraverso il suo blocco environment prima di avere qualcosa da offrire.

L'output viene tagliato. Esiste un tetto a quanto il risultato di un singolo strumento può contribuire alla conversazione, e compare un avviso quando l'output supera una soglia più bassa. Un server le cui risposte vengono tagliate sembrerà funzionare, meno l'ultima parte di ogni risposta. Se un server è legittimamente prolisso, alza il tetto di proposito invece di concludere che è inaffidabile.

Un server di progetto non si connette per nessun altro. Questo è il cancello di attendibilità, non una voce rotta. Il clone appena fatto di un collega deve dichiarare attendibile lo workspace e approvare la voce condivisa una volta. Se non lo ha fatto, il server appare in attesa di approvazione e il controllo di salute non viene mai eseguito.

Quando il server MCP ha bisogno di una sessione browser

I server che usano il browser sono il punto in cui il quarto passaggio diventa tutta la storia. Il server si connette, il trasporto va bene, l'handshake si completa, l'elenco degli strumenti è popolato e l'attività fallisce comunque, perché il browser che pilota non ha una sessione con accesso effettuato oppure il profilo che ha avviato non è quello che contiene i tuoi cookie. Ogni sintomo nel client sembra sano.

Il server di quell'esempio è microsoft/playwright-mcp, dove sono tracciati il suo elenco di strumenti e i problemi noti.

Per l'insieme più ampio di modi in cui un agente può raggiungere un browser dentro Claude Code, vedi il confronto tra le cinque strade per il browser.

Questo è il livello che ego (lite) occupa, e vale la pena essere precisi su quale prodotto sia. Non è un server MCP e non registra alcuno strumento: è un browser costruito perché un agente lavori dentro il browser che ha già i tuoi accessi, invece che in un profilo di automazione nuovo accanto. La connessione tra l'agente e quel browser è una questione separata dalla connessione tra l'agente e i suoi strumenti. Claude Code o Claude Desktop mantiene la connessione MCP; ego-browser mantiene la sessione browser, e le sessioni vivono in Space isolati così il lavoro di un agente non entra in collisione con la finestra che stai usando. Quando un server MCP per il browser restituisce una pagina vuota, un reindirizzamento al login o un elemento che non riesce a vedere, la correzione è quasi sempre da quel lato del confine e non nella configurazione appena verificata.

Se non hai ancora scelto un server browser, il confronto tra i server MCP browser per Claude Code classifica le opzioni attuali in base a cosa riesce a raggiungere ciascuna e quanto costa.

MCP, uno strumento da riga di comando, un'estensione del browser e un browser costruito per gli agenti sono quattro livelli diversi, e scegliere tra loro è una questione di chi possiede la finestra, non di quale sia più capace. Il test pratico è ciò di cui ha bisogno l'attività: un server che riesca a raggiungere le tue sessioni autenticate, a un costo in token che puoi accettare, in una finestra che resta tua. È su quest'ultimo passaggio che si prende la decisione, qualunque cosa dica la riga di stato.

I compromessi livello per livello sono analizzati in MCP vs CLI e dove si inseriscono le estensioni del browser.

Che cosa concedi quando un server si connette

Collegare un server significa concedere una capacità, e la tabella degli scope di prima vale anche come tabella delle autorizzazioni. Un server con scope user è presente in ogni progetto che apri, compresi quelli che non hai scritto tu. Un server con scope project è presente per chiunque cloni il repository. Nessuno dei due fatti è negativo di per sé, ma entrambi si dimenticano facilmente un mese dopo la configurazione.

Tre abitudini coprono gran parte del rischio. Tieni le credenziali nelle variabili d'ambiente invece che in un file committato, e ricorda che una voce con scope project viaggia. Installa i server che stai ancora valutando con scope local, dove rimuoverli è un solo comando e nulla arriva al controllo di versione. E quando l'accesso di un server è più ampio del suo compito (un server filesystem puntato alla tua home directory per modificare una sola cartella, un server browser che può raggiungere ogni account con accesso effettuato che possiedi), restringi la concessione prima di restringere la configurazione.

Se vuoi vedere cosa espongono gli altri server prima di concedere qualcosa, il repository ufficiale dei server MCP elenca le implementazioni di riferimento e i loro scope.

Anche le definizioni dei server consumano contesto una volta connessi; come ridurre il consumo di token MCP copre questo lato del compromesso.

L'interfaccia utente rafforza la differenza: un connettore remoto viene eseguito dal cloud del fornitore, con la portata di rete che questo implica, mentre un server locale viene eseguito con i permessi del tuo account sulla tua macchina. Per questo la domanda di sicurezza per un connettore remoto è chi altro può raggiungere quell'endpoint, e la domanda di sicurezza per un server locale è a cosa può accedere quel processo.

Domande frequenti

Un solo server MCP può essere usato sia da Claude Code sia da Claude Desktop?

Sì, a patto di configurare ogni app separatamente. I due client leggono configurazioni diverse, quindi aggiungere un server in Claude Code non ha alcun effetto su Desktop e installare un'estensione desktop non rende il server disponibile a Claude Code. Un server remoto è il più economico da tenere in entrambi i posti, perché lo stesso URL vale per tutti e due e cambia solo la voce che lo circonda.

Dove viene eseguito davvero il server?

Un server locale è un processo sulla tua macchina, avviato dal client, con i permessi del tuo account utente. Un server remoto via HTTP o tramite il trasporto SSE deprecato viene raggiunto attraverso la rete e, dentro Claude Desktop, quel raggiungimento avviene dal cloud di Claude e non dal tuo dispositivo. È la distinzione più utile quando un server funziona in un'app e non nell'altra.

Perché il server appare in attesa di approvazione?

Arriva da un file di progetto condiviso che non hai ancora approvato in questo workspace. L'attesa di approvazione è una decisione di configurazione, non una connessione fallita, quindi il client non ha mai contattato il server per generarla. Esegui una volta il client interattivo in quella directory, accetta la finestra di attendibilità dello workspace e approva il server; lo stato cambia al controllo successivo.

SSE è ancora utilizzabile o devo migrare?

Il trasporto SSE è deprecato ma ancora accettato. Quando un server offre entrambi gli endpoint, il trasporto HTTP è la scelta migliore e nelle versioni recenti il client preferisce HTTP e ripiega su SSE quando il server non lo accetta. La migrazione è una modifica di una riga al type e all'URL della voce, non una reinstallazione.

Perché il server funziona nel mio terminale ma non nell'app?

Quasi sempre perché l'app non eredita l'ambiente che aveva la tua shell. Il tuo terminale ha un PATH e una serie di variabili esportate che un'applicazione con interfaccia grafica non vede mai, quindi un server avviato con un semplice nome di comando si risolve in un posto e non nell'altro. Usa percorsi assoluti per il comando e passa le variabili di cui il server ha bisogno attraverso il suo blocco environment invece di affidarti alla shell circostante.

Come rimuovo un server in modo pulito?

In Claude Code rimuovilo per nome, il che elimina la voce dallo scope che la contiene. In Desktop disinstalla l'estensione oppure elimina la voce e riavvia, dato che il file manuale viene letto solo all'avvio. Rimuovere da un posto non rimuove mai dall'altro, ed è bene ricordarlo quando un server che hai eliminato in un'app continua a comparire nell'altra.

Posso committare un .mcp.json di progetto nel repository?

Puoi farlo, ed è proprio lo scopo dello scope project, ma il file non contiene credenziali e ogni collega lo approva comunque una volta. Tieni i valori segreti nelle variabili d'ambiente a cui fa riferimento la voce, e considera il file committato come un elenco di nomi di server e comandi, non come una configurazione di cui un clone possa fidarsi da solo.

Perché Claude Desktop non vede un server che ho aggiunto in Claude Code?

Perché le due app leggono configurazioni diverse. Un server registrato con la CLI vive nei file di scope propri di Claude Code, e Desktop legge solo le sue estensioni e la sua configurazione Developer. Aggiungi di nuovo il server dal lato Desktop, oppure punta entrambi allo stesso URL remoto in modo che ci sia una sola definizione da mantenere.

Devo riavviare l'app dopo aver modificato un file di configurazione?

Claude Code legge e scrive le sue definizioni dei server tramite i propri comandi, quindi non serve un riavvio manuale. Claude Desktop legge il suo file di configurazione manuale all'avvio, quindi una modifica fatta fuori dall'app ha effetto solo dopo un riavvio.

Cosa significa needs authentication nell'elenco dei server?

Il server si è avviato e ha risposto, ma il chiamante che ha visto non era autorizzato. Per un server remoto questo di solito significa che la credenziale nell'URL o negli header non è arrivata, oppure è arrivata vuota dopo l'espansione delle variabili. Apri la configurazione del server e verifica i valori espansi prima di cambiare qualsiasi altra cosa.