Tools & execution
What the MCP server exposes, how risky tools are marked, and how calls actually run.
Your MCP server exposes your capabilities as tools, with clear risk markers — and runs them carefully.
What’s exposed
Each non-internal capability becomes a tool, named by its capability id, with its inputs described. Tools a user lacks the permissions for are hidden. Descriptions carry clear risk markers:
- Requires step-up — the action needs re-authentication, which is completed in the widget.
- Destructive — blocked unless you’ve explicitly allowed it.
- Live data — the tool reads or writes real data, not a sandbox.
- A built-in docs-search tool also lets clients search your connected knowledge.
What a large catalog looks like
AI clients get worse at choosing a tool as the list grows, and several cap how many they will hold. So the shape of what a client is offered depends on how many capabilities you have enabled. You can override the choice from the dashboard if you would rather pin one.
- A small catalog
- Every enabled tool is offered directly. This is the shape until your catalog outgrows a single list.
- A few dozen tools
- The client is offered a small core set plus one search tool it uses to find the rest. Everything is still reachable — the client asks for what it needs instead of holding the whole list.
- A very large catalog
- The set offered is chosen per session from what is most relevant and most recently used, rather than being the whole list.
How calls run
How a tool call executes depends on whether you’ve enabled server-side execution.
Bring your own MCP server
If your workspace already runs its own MCP server, you can register it (from the dashboard or the CLI) and Syncanix will forward tool calls to it — optionally acting as the end user.