The capability catalog
The structured list of what your API can do — discovered once, authored by you, and read by every surface.
The capability catalog is the heart of Syncanix. It’s a structured description of everything your product can do, discovered from your API and refined by you. Every surface — the widget, the chat, the MCP server — reads from this one catalog, so what your assistant can do is consistent everywhere and edited in a single place.
What a capability is
A capability is one thing your API can do: a single endpoint or action, such as “look up an order” or “refund a payment.” Each one is described well enough for the assistant to understand what it does, what it needs, and when to use it.
What each capability carries
- Identifier
- A stable id in the form domain.action (for example orders.refund), used everywhere the capability is referenced.
- Method & path
- The HTTP method and path the capability maps to (for example POST /orders/{id}/refund).
- Inputs
- The arguments the action accepts, with their names and types — never example values from your data.
- Description
- A plain-language summary of what the action does. This is what the assistant reads to decide whether and when to use it.
- Side effect
- Whether the action reads, writes, or is destructive — which drives how it’s confirmed before it runs.
- Risk
- A risk level that lets you treat some actions more cautiously than their side effect alone would suggest.
- Required permissions
- The scopes a user must have for the action to be offered to them at all.
- Internal flag
- Marks a capability as internal so it stays out of the assistant’s reach while remaining in your catalog.
- Personal-data flags
- Marks inputs or outputs that contain personal data, so they can be handled and redacted appropriately.
Discovered, then authored
Discovery proposes the catalog by reading your code statically. From there it’s yours to author: rename capabilities, sharpen descriptions, set side effects and risk, mark endpoints internal, and adjust required permissions — all in the dashboard. Your edits are stored as overrides, so they survive the next discovery run.
One source of truth
Because the widget, the chat surface, and the MCP server all read from the same catalog, you define what the assistant can do once. Change a capability in the dashboard and every surface reflects it.