Syncanix with Rails

Make a Rails API agent-ready: what discovery reads, how to run it, and how to ship the chat surface and MCP server.

Rails routes are declared in config/routes.rb with resource macros and nesting. Discovery expands those declarations into the concrete verb-and-path pairs your API serves.

What discovery reads

Discovery is static — it reads your source, not your traffic. It composes full request paths across files, so mounted prefixes are part of every extracted route:

# config/routes.rb
namespace :api do
  resources :orders, only: [:index, :show] do
    member { post :refund }   # → POST /api/orders/:id/refund
  end
end

Representative routes the extractor composes — full paths, prefixes included.

The extractor expands namespace and scope blocks (string and symbol forms), nested resources, member and collection routes, and respects only:/except: filters — even devise_for authentication routes are expanded.

Run discovery

From the repository root, run the init command. It detects the framework automatically, asks for consent before any LLM enrichment, and writes a deterministic catalog:

$ npx syncanix init
✓ detected framework
✓ scanned routes
✓ wrote .syncanix/catalog.json
→ review your capabilities in the dashboard

Available at launch — this package is not on its public registry yet, so the command above will work the day Syncanix opens.

Review the catalog

The catalog at .syncanix/catalog.json lists every capability discovery found — method, path, and the enriched description your users will see. Review it like code before uploading: it is the contract your chat surface and MCP server expose.

Ship the surface

Once the catalog is uploaded, embed the widget for in-app chat and connect the per-tenant MCP server for Claude, ChatGPT, and Cursor. Every write action stays permission-gated, confirmed, and audited.

Next steps

Framework supportThe full language and framework matrix the discovery CLI reads.Launch assistantThe guided path from a fresh catalog to a live, embedded assistant.