I’ve been using the Railway MCP server and Agent Skills inside Cursor and they’re genuinely solid. But after seeing Canvas Chat in action, it feels like that’s the system that actually understands what’s going on inside a project.

I’d love to see Canvas Chat exposed as something external IDE agents can call directly. Right now, agents can technically set environment variables and inspect services through the CLI-backed MCP tools, but in practice it’s clunky.

A real example: when the agent needs a Postgres URL, it usually has to:

• Check environment variables

• Realize the URL in the repo points to the internal Railway address

• Use the CLI to switch from the backend service to the Postgres service

• Inspect connection details there

• Then jump back to the backend service to verify something

• Sometimes forget which service it was in and repeat the whole process

It works, but it’s inefficient and wastes a lot of cycles. The agent ends up rediscovering the same context multiple times because it doesn’t have a strong, centralized understanding of the canvas state.

Canvas Chat already has that context. It knows what’s running, what’s connected, and how services relate to each other. Letting external agents delegate infrastructure questions and staged changes to Canvas Chat would reduce redundant CLI hops and make the overall workflow much tighter.

The IDE agent could stay focused on code while Canvas Chat handles project-level reasoning. That separation feels cleaner and more scalable than trying to teach every external agent how to navigate the full Railway CLI surface area efficiently.