MCP connected but not working? Troubleshoot Mono by failure stage
Find whether a Mono MCP problem comes from transport, authorization, capability discovery, model support or a tool call, then verify one harmless operation.
A saved MCP server doesn’t mean the tool works. The address can be right while sign-in isn’t finished. Sign-in can work while the server’s tools still fail to load. And a tool can load but still receive a bad request. Find the first step that fails before you change any settings.
This guide covers troubleshooting in Mono by Reunified, which isn’t out yet (join the waitlist). For a first connection, use the MCP setup guide. The goal here is to turn a vague “it doesn’t work” into one clear observation you can repeat, without accidentally repeating a write.
1. Record the symptom and stop uncertain retries
Write down the server name, transport, device, app version, what you tried to do and the exact error, with secrets removed. Note whether the same setup worked before and what has changed since. “The tool list is empty after sign-in” is more useful than “MCP is broken.”
If the last request could create, send or update something, check the destination before you retry. A lost response doesn’t mean the action didn’t happen. For testing, switch to a small read-only request, such as listing one item in a test project you can check.
Keep a private copy of the last working settings. Don’t paste tokens, authorization codes or private tool output into a public support post.
2. Check the transport before the account
An HTTP connection in Mono needs the address of an MCP server, not a normal homepage or a model API address. Compare the full URL, including the path, with the server publisher’s current documentation. A page that opens in your browser only shows that the page is reachable, not that MCP works there.
For standard input/output (stdio), check the command and arguments on the device that has to start them. Signing in again won’t fix a missing command or a device that can’t run it. Phones and computers are different, so don’t expect a desktop command to run on a phone.
An address with localhost points to the device making the request. Test from the actual device, through a supported, signed-in route. Don’t weaken a working server’s access controls just to make a test pass.
3. Separate saved settings from completed authorization
Check which authentication method you picked. A bearer token needs the right service token in its field. OAuth needs the right account, the server’s requirements and a finished return to Mono; closing the browser early is not a successful sign-in.
Mono can save a server before sign-in is finished, so a saved server isn’t proof that sign-in worked. Even after a successful sign-in, loading the server’s tools can fail for a while. Neither a saved entry nor a “Connected” message proves that a particular tool is ready.
If you change the server URL or transport, Mono treats it as a new connection, so you may need to sign in again. Fix a real address mistake, but don’t keep changing a working URL as a general reset. Follow the publisher’s documented client and redirect settings instead of guessing values.
4. Check capabilities and the selected model
The MCP architecture separates tools, resources and prompts. A server may offer only some of them, so a server that offers only resources won’t give the assistant any tools to call.
For an installed MCP skill, open its Configuration section to see the tools Mono found. If it’s empty, check sign-in and whether the server lists its tools; don’t assume every action of the service is available. Saving a server is not a full health check.
Also check the model used in the chat. Not every model can call tools, including some models you connect yourself. A model that answers text well can still be the reason a connected tool is never used. The custom endpoint guide explains this.
5. Test one known operation
Use a harmless request and compare the result with the original service:
Read the title of the existing demo item I identify.
Do not create, edit, send or delete anything.
If access fails, report the failure rather than guessing the title.| What you see | What to check next |
|---|---|
| Can’t connect to the address | Address, transport, device network and whether the server is up |
| Sign-in doesn’t finish | Account, authentication method and the publisher’s OAuth requirements |
| No tools appear | What the server offers, whether its tools loaded, and model tool support |
| One tool fails | Required inputs, the service’s permissions and the returned error |
| Reading works, writing is blocked | The access you intended and the tool’s permission setting; don’t open up everything |
A tool’s own error is different from an empty but successful result. Keep the returned status and the relevant text, with secrets removed, together.
6. Verify the fix and keep a support record
Change one thing at a time, repeat the same read-only test and note the result. If you later need a write, check its exact target and confirm the result in the service before you try again.
Keep a short note of the failing step, versions, the change you made and the last successful test. Removing a connection in Mono and revoking access at the provider are separate steps. For permission decisions during use, read reviewing tool permissions; approving requests again and again won’t fix a connection.
