skip to main content
Browse documentation

How Syncanix works

From one discovery command to a live assistant: how the capability catalog connects the CLI, the widget, the chat surface, and the MCP server.

Syncanix is built around one idea: discover what your product can do once, then reuse it everywhere. That discovery produces a capability catalog, and everything else is a view onto it.

1. Embed the widget

Add one script tag to your app. The widget loads lazily, runs inside a Shadow DOM so your styles and ours never collide, and picks up your brand from your existing design system automatically.

<script
  type="module"
  src="https://cdn.syncanix.com/widget.js"
  data-key="pk_live_..."
></script>

2. It reads your product

With the widget in place, the agent works out what your product can do by looking at the screens it is made of — the forms, the buttons, the links, the things a person can fill in. A guided walk from the dashboard covers your product in one pass; after that it keeps reading the pages your own users visit.

Field values are never captured, and you can exclude any region of any page. If your team wants exact argument schemas as well, an optional scan of your source code adds them — it is a deeper pass, not a prerequisite.

3. Chat that takes action

The assistant answers questions and runs your API actions as the signed-in user — using their identity from your identity provider, never a shared credential. Actions are gated by how risky they are:

  • Read actions (look something up) can run automatically.
  • Write actions (change something) ask the user to confirm first.
  • Destructive actions are blocked by default until you explicitly allow them, and can require a re-authentication step.

4. Connect AI clients over MCP

Each workspace gets its own MCP server, so your users can reach the same capabilities from Claude Desktop, Cursor, ChatGPT, and other MCP-capable clients. Sign-in federates to your identity provider, so the same identity and permissions apply there too.

Configure everything in the dashboard

The dashboard is where you review the catalog, set each action’s risk level and permissions, write the assistant’s persona, connect knowledge sources, design the widget, manage your team, and watch usage and costs. Changes are made in a development environment first, then promoted to production.

The journey at a glance

A typical first run, from an existing app to a live assistant:

  1. EmbedAdd one script tag. Nothing is visible to your users until you finish reviewing.
  2. Let it readWalk through your product once, then let it keep reading as people use it.
  3. Review & configureIn the dashboard, set risk levels, permissions, and the assistant’s persona.
  4. PromotePromote from development to production when you’re happy with how it behaves.

Next steps