A connect attempt that was refused leaves a connection row in the settings registry reading Connected, even though the journey never completed and the credential was rejected on every attempt.
What was seen
Driving the connect sheet against a server that requires an API key, with a deliberately wrong credential: the verifying call was refused each time, the sheet reported that the server could not be reached, and the journey was never finished. The endpoint row was nonetheless present in Settings under MCPs with the status Connected.
Why it matters
That row asserts a state nothing has established. The registry is the surface a person reads to know which servers are usable, and an agent's configuration reads the same records to decide what tools it has. A row that says Connected for a server whose credential was refused sends someone looking for the problem anywhere but at the credential.
It is not an unsafe grant: the connection does not work, so nothing runs that should not. What it costs is a misleading screen and the debugging time that follows it.
Related
This sits next to the retry behaviour filed separately, where a 401 relayed from a third party is retried as though our own session had expired and the journey ends on a generic unreachable screen. That explains why the journey ends where it does; this issue is about what the row says in the meantime. Whoever picks up one should look at the other, because the same failed attempt produces both.
What would close it
Either do not persist the row until the journey reaches a verified state, or give a row whose verification never succeeded a status that says so. The registry already has a vocabulary for a connection that exists but cannot currently be used, which is what an expired login shows.
Found during the final verification pass of the MCP gateway release, driven against the running deployment.
A connect attempt that was refused leaves a connection row in the settings registry reading
Connected, even though the journey never completed and the credential was rejected on every attempt.What was seen
Driving the connect sheet against a server that requires an API key, with a deliberately wrong credential: the verifying call was refused each time, the sheet reported that the server could not be reached, and the journey was never finished. The endpoint row was nonetheless present in Settings under MCPs with the status
Connected.Why it matters
That row asserts a state nothing has established. The registry is the surface a person reads to know which servers are usable, and an agent's configuration reads the same records to decide what tools it has. A row that says
Connectedfor a server whose credential was refused sends someone looking for the problem anywhere but at the credential.It is not an unsafe grant: the connection does not work, so nothing runs that should not. What it costs is a misleading screen and the debugging time that follows it.
Related
This sits next to the retry behaviour filed separately, where a 401 relayed from a third party is retried as though our own session had expired and the journey ends on a generic unreachable screen. That explains why the journey ends where it does; this issue is about what the row says in the meantime. Whoever picks up one should look at the other, because the same failed attempt produces both.
What would close it
Either do not persist the row until the journey reaches a verified state, or give a row whose verification never succeeded a status that says so. The registry already has a vocabulary for a connection that exists but cannot currently be used, which is what an expired login shows.
Found during the final verification pass of the MCP gateway release, driven against the running deployment.