Troubleshooting
Work down from the symptom you can see. Most issues are access configuration, a runtime version, or a connection that needs re-establishing.
Common symptoms
Diagnosing a specific connection
The connection command prints its private connection state path. Use it explicitly:
quilr-mcp status --state PATH
quilr-mcp doctor --state PATH --package ID
--stateWithout --state, these commands may report on a different connection than the one you set up, which makes a working setup look broken.
A tool call returns "Preparing"
This is expected on a first call, while the package is set up on your computer.
Preparing means the tool did not execute. Ask your AI app to check quilr_connection_status, then retry when it reports ready. Later calls are fast.
If a package stays in Preparing, the usual causes are a failed dependency install or a missing Node or Python runtime for that package. Run doctor and share the output with your administrator.
A call succeeded locally but shows as Blocked
The local MCP ran, and the gateway blocked the response on its way back to the AI app. Ask your administrator to open the call in Activity and check its Policy evaluation.
No tools appear after an admin granted access
Use Refresh access in self service. Do not sign in again.
New tools are picked up automatically. AI clients that do not refresh on their own need their native MCP reconnect action, or a restart.
Starting over cleanly
- Run
quilr-mcp disconnect --state PATHand let it confirm with the gateway. - Only then uninstall the CLI, if you want it gone.
- Package files remain under
~/.quilr-mcp. Remove that directory only after confirming no other installation uses it.
Re-enrollment is a new computer connection and is subject to current access policy. A revoked installation cannot restore itself.
Escalating
Collect before you raise a ticket:
- The output of
quilr-mcp status --state PATH - The output of
quilr-mcp doctor --state PATH --package ID - Your AI client and its version
- The Node or Python version in use
- The approximate timestamp of the failing call, so an admin can find it in Activity