Skip to main content

Tools & Capabilities

Svantic has three ways to give agents tools: capabilities (your code, running on your machine), MCP servers (tool processes running alongside Svantic), and builtin tools (pre-built integrations shipped with the SDK).

Capabilities

A capability is a function your agent exposes to the AI. You define it with define_capability and it becomes invocable by the mesh — just like any built-in tool.

How Capabilities Become AI-Callable

  1. Svantic reads your agent card (including skills with parameters)
  2. For each skill, Svantic creates a capability proxy
  3. When the AI invokes the capability, the proxy sends an A2A task to your agent
  4. Your handler receives the arguments and returns the result
The AI doesn’t know the capability runs on a different machine.

Bidirectional Execution

Capabilities execute on your machine, not on the server. This is a foundational architectural decision. Bidirectional capability execution: Svantic sends A2A task, agent executes locally, returns result The agent never sends credentials or raw data. It receives a structured request, executes locally, and returns just the result. This is what makes Svantic usable in regulated industries — the mesh sees capability names and results, not the underlying data. Why it matters:
  • Data sovereignty — data never leaves your environment
  • Security — credentials stay on the machine that owns them
  • Network topology — works behind firewalls, VPNs, air-gapped environments (outbound only)
  • Scale — execution is distributed across your agents; Svantic handles reasoning

Design Guidelines

Do:
  • Be atomic — one capability, one action
  • Write descriptions the AI can understand
  • Use JSON Schema with descriptions on every property
  • Return structured data with clear field names
  • Handle errors gracefully with clear messages
Don’t:
  • Bundle multiple operations into one capability
  • Expose raw SQL — wrap queries in specific capabilities
  • Return HTML — return structured data
  • Skip descriptions on parameters

MCP Servers

MCP (Model Context Protocol) servers are tool processes that Svantic spawns and manages. They’re ideal for general-purpose utilities like browser automation, filesystem access, or code search.

MCP vs. Capabilities

Rule of thumb: If the tool needs your database, credentials, or internal state → capability. If it’s a general-purpose utility → MCP.

Adding MCP Servers

settings.json (permanent):
REST API (runtime, in-memory — cleared on restart):
Terminal client: Use /mcp add for an interactive wizard, /mcp list to see all servers, /mcp sync to re-push after a server restart.

Common MCP Servers

Any npm package that speaks the MCP protocol works with Svantic — just add it to settings.json.

Writing a Custom MCP Server


Builtin Tools

The SDK ships with 25 production-ready tools across 7 domains. Enable them in settings.json:

Available Domains

Shell Tool

A general-purpose command execution tool that replaces the need for individual git, kubectl, docker, or terraform wrappers. The agent constructs the command; shell_exec runs it locally.
Returns { "stdout": "...", "stderr": "...", "exit_code": 0 }.

Programmatic Usage

The SDK also exports HttpHelper for building custom tools that call HTTP APIs.