Skip to content
SVEDA
EN
Menu

TOOLS

Connectors and tools. Not feature bullets.

Backend tools run in sveda-server. Frontend tools run in the browser. Host MCP is an HTTP server you pass when minting the embed token.

Get started Tools docs

Three tool surfaces

Builtin tools run in sveda-server against the workspace index. Frontend tools run in the host browser via SvedaToolRegistry. Host MCP is HTTP tooling you attach when minting the embed token. Named policies on the token filter which tools run on each turn.

4

builtin tools

register

frontend API

HTTP

host MCP

The problem

Tooling usually means a custom MCP client, a browser callback bus, and a workspace indexer that never share a catalog. Each server is headers and a session you maintain. The agent should list tools from three layers without a new control plane.

A client per MCP server

Hand-rolled transports, auth, and tool lists. Host MCP on Sveda is an HTTP URL plus token on the embed handshake — http or https, Bearer outbound.

Frontend tools on a side bus

Confirm dialogs and in-page actions never join the model loop. SvedaToolRegistry.register puts them on the same turn as backend tools.

Repo blind agents

Without an index, “read the file” is a prompt hack. Builtin search_code and read_code_file run when a workspace index is attached to the runtime.

How Sveda does it

Backend tools execute in sveda-server. Frontend tools execute in the host via the registry on SvedaClient. Host MCP is listed when you pass host_mcp_url and host_mcp_token together while minting the embed token.

Builtins on the runtime

Four agent tools. They appear in the catalog when the runtime has the matching capability — index, spawn, deferred discovery.

  • search_code
  • read_code_file
  • spawn_tasks
  • search_agent_tools

Frontend on the client

Register handlers before send. A tool.call with target frontend runs in the browser, then the stream continues.

  • SvedaToolRegistry.register
  • name, description, parameters, handler
  • target: frontend on the event

Host MCP on the token

Not a second JS MCP client. URL and token are stored per visitor_id. Outbound calls use Bearer. Schemes are http and https.

  • host_mcp_url and host_mcp_token together
  • POST /sveda/embed/token
  • Bearer on outbound MCP

CATALOG

  • search_code backend
  • SvedaToolRegistry frontend
  • host MCP http

URL and token travel together.

If you send host_mcp_url without host_mcp_token, or the reverse, the mint rejects. Both are required together. The runtime lists tools over HTTP and executes them during the turn with Authorization: Bearer on the outbound request.

search_agent_tools discovers deferred MCP tools. spawn_tasks fans parallel work on the same SSE pipe via tool.progress. search_code ranks the workspace index; read_code_file pages a file the runtime already indexed. None of this is a Vue plugin.

Rules live in the tools docs. The host MCP and code agent solutions show the two common attach paths.

embed-token.json POST 
POST /sveda/embed/token
x-sveda-host-key: …

{
  "visitor_id": "visitor-1",
  "host_mcp_url": "https://host.example/mcp",
  "host_mcp_token": "…"
}

Related

Embed token

Host MCP credentials ride on the same mint as the visitor token.

Stream protocol

tool.call, tool.result, and tool.progress are SSE events.

JS client

SvedaToolRegistry.register is how frontend tools join the turn.

Tools docs

Builtins, frontend registry, and host MCP attachment rules.

Host MCP

HTTP tools from the embed-token handshake.

Code agent

search_code and read_code_file on a workspace index.

Register a tool. Pass the MCP pair.

Builtins in sveda-server. Frontend via SvedaToolRegistry. Host MCP only when URL and token arrive together.

Get started