Most failures happen at a clear boundary: client to MCP, user to project, or editor to renderer.
connection
The MCP client shows 401 or never opens sign-in
Remove the saved Shyne connection, add the canonical MCP URL again, then complete OAuth in the browser. In Claude Code, open /mcp and authenticate the server.
Opening the MCP URL in a browser returns 405
That is expected. The endpoint accepts authenticated POST requests from an MCP client. It is not a human web page.
The desktop endpoint (127.0.0.1:7655) refuses the connection
The local endpoint answers only while the Shyne desktop app is running and signed in. Open the app, sign in, then reconnect. It is loopback-only, so it is never reachable from another machine.
project access
The agent says no project was specified
Ask the agent to list projects first and then name the one you mean. Every project-scoped tool call carries an explicit project id.
A linked project is visible in the app but absent from MCP
Hosted MCP project discovery is owner-scoped. Sign in as the project owner or ask the owner to run the agent.
editing
A recent human edit disappeared
The agent edited from a stale read. Undo the change in Shyne, then ask the agent to re-read the frame just before writing and to keep everything outside the requested change.
rendering
The frame looks right in the editor but wrong in a screenshot or export
Check the warnings the tools returned. Keep styles, scripts, and media local to the frame; external references the renderer cannot load are the usual cause.
get_presence returns no peers
Hosted MCP has no persistent awareness peer, so an empty presence result is expected there. The desktop app’s local MCP can expose live collaborators.