search_code
rank the workspace index
USE CASE
An agent that can see the repo.
When a workspace index is attached, search_code and read_code_file are in the catalog. The agent searches, then reads, then answers — in one stream.
read_code_file
page a file the index already has
spawn_tasks
parallel work in one stream
The challenge without an index
A code agent that cannot see the repo guesses. Teams dump trees into the prompt, shell out to grep, or stand up a separate retrieval service and then teach the model how to call it. The first turn should search, then read, then answer — in the same stream, only when an index is actually attached.
Paste the tree
Context windows fill with paths the model never opens. Answers cite files that are stale, missing, or outside the workspace.
Shell as retrieval
grep and cat become tools with no ranking, no paging, and no record of what the agent actually read.
Eval in another repo
A harness proves the agent can navigate a fixture tree. The product never gets search_code on the live index.
How Sveda solves it
Point sveda-server at a workspace index. Builtin search_code ranks files. read_code_file pages them. spawn_tasks fans independent work. search_agent_tools discovers deferred tools. Index tools are advertised only when an index is attached.
Search, then read
The catalog tells the model to search the index before opening a file. Hits carry path, line range, snippet, and score.
- search_code requires a query
- limit defaults to 8, clamped 1–24
- read_code_file requires a path from the index
- offset and length page the file; default length 4000, max 8000
- has_more tells the model to call again with offset
Parallel work
spawn_tasks runs independent background tasks in one turn instead of a chain of sequential calls.
- Each task has a type, an input payload, and an optional label
- Maximum 6 tasks per turn
- Maximum 4 tasks in parallel
- Progress events stream on the same pipe
- Host MCP tools can back the spawned work
Tools when they exist
search_code and read_code_file are not always in the catalog. They appear when a workspace index is attached. Deferred MCP tools show up through search_agent_tools.
- No index → no search_code, no read_code_file
- spawn_tasks is always advertised
- Large MCP pools defer tools behind search_agent_tools
- Activated tools join the next step by name
- Unknown tools fail closed in the runtime
INDEX TOOLS
Rank first. Open second.
search_code queries the local workspace index with keyword and embedding ranking. The tool description says to use it before read_code_file. That order is the product: the agent sees scores, then pages a path the index already holds.
If the index is missing, both tools error with “Code index is not configured.” They are not advertised. You do not ship a fake file tree in the prompt to paper over that.
The MCP and tools page and the tools docs list the builtins.
TOOL CALLS index attached
search_code query · limit 8
crates/sveda-agent/src/tools.rs
score 0.86 · L351–L380
read_code_file offset 0 · length 4000
has_more call again
CATALOG this turn
- spawn_tasks always
- search_code index
- read_code_file index
- search_agent_tools deferred pool
SPAWN + DEFER
Fan out without a second harness.
spawn_tasks takes an array of independent tasks. The runtime runs them in parallel, emits tool.progress, and returns a combined result. That is the alternative to an eval worker that fans jobs in another process.
When the MCP pool is large, search_agent_tools is advertised instead of dumping every tool into the prompt. The agent searches, activates matches, and calls them by name on the next step. Index tools still only appear when the index is attached.
Pair this with host MCP when spawned work should hit your HTTP tools.
Related
Product copilot
Same client and runtime. The copilot does not replace the host.
Host MCP
HTTP tools from the embed handshake, listed and executed in the loop.
Model failover
The index tools stay on the runtime if a provider drops.
MCP & tools
Builtins, frontend tools, and host MCP — not feature bullets.
Rust runtime
The index and the agent loop live in sveda-server.
Stream protocol
tool.call, tool.result, and tool.progress on one SSE pipe.
Tools docs
search_code, read_code_file, spawn_tasks, search_agent_tools.
Runtime docs
sveda-server routes. Default bind 0.0.0.0:8787.
Stream protocol docs
Event types including tool.call and tool.progress.
Give the agent the repo.
Attach a workspace index. search_code ranks. read_code_file pages. spawn_tasks fans the rest.