An attached server’s availability is checked separately from the assistant’s connection to MCP Hub. If the hub itself connects but one attached service is unavailable, begin with that server’s row rather than replacing the hub token.

Read the recorded state

Open PD Modules → MCP Hub → Attached servers and check State, Why and Last checked. The module withdraws the server after three consecutive catalogue-fetch failures and displays Not responding. A single failed check can leave the earlier state in place.

The timestamp records a check attempt, not necessarily a successful response. Likewise, a message describing an unchanged state is not proof that a tool call to the provider succeeded.

Check the intended arrangement

1. Confirm that the saved address is the provider’s current HTTPS Streamable HTTP MCP endpoint.
2. Review the provider’s availability and the credential arrangement that was originally authorised.
3. Ask the server administrator to check reachability from the billing installation if local checks are inconclusive.
4. Use Re-check on this server after the underlying issue has been addressed.
5. Inspect the row again and review any resulting tool-definition hold.

Do not assume your own browser’s access proves that the billing server can reach the service. Do not paste credentials into a diagnostic URL or remove the provider’s authentication requirement to make a check pass.

Re-check versus re-approval

A manual Re-check attempts this server immediately rather than waiting for its scheduled interval. It is not a tool-execution test, credential editor or automatic approval action. A server withdrawn after failures is not promised to return to use solely because a later fetch succeeds.

If a new review is needed, open Tools & risk, inspect the current definitions and risk classes, and approve only the intended set. If that screen does not offer a supported recovery for the observed state, keep the attachment and its connection grants while you compare the recorded check result with the provider and network checks.

Avoid removing and attaching the server again as the first troubleshooting step. Removal discards the attachment and its connection grants, creating additional setup work without explaining the original failure.

Check the recovery result

Your hosting team and server administrator should compare the recorded fetch time and error with the provider’s availability, endpoint and authentication requirements, and the billing server’s outbound connection. After addressing the cause, inspect the result of Re-check and the actual attachment state. A timestamp or unchanged-state message does not prove a successful fetch or tool execution. Keep the previous and current attachment state alongside the check times and error when comparing results. Do not remove and recreate the attachment simply to reset the display.

See the PD MCP Hub Blesta guide for related tasks, or explore PD MCP Hub.