Tool Registry
How native tools, MCP tools, and discovered tools reach the model.
The Tool Registry is the catalog every tool call resolves through. It aggregates native tools and MCP-provided tools, and it is the place where a tool's risk level is declared.
Sources
| Source | Description | ID form |
|---|---|---|
| Native | Tools implemented in the tool runtime | native:<name> |
| MCP | Tools reported by a connected MCP server | mcp:<serverId>:<toolName> |
Declared risk, not inferred risk
Every native tool is registered with an explicit risk level:
registerTool("dispatch_agent", tool({ ... }), "high");This is a deliberate constraint. Inferring risk from the tool name once rated dispatch_agent and run_task_graph as low — they contain no risky-sounding word — while both spawn runs that write files and execute commands, and low is auto-approved by default. A name is not evidence about an effect.
Core tools and on-demand discovery
Exposing every tool schema on every turn burns context and degrades tool selection. The router therefore works in two tiers:
- Core tools are always available.
- Everything else is reachable through
search_tools, which matches the full catalog by query and returns schemas for the matches. The model plans with the tools it found rather than carrying the whole catalog.
Built-in native tools
| Tool | Risk | Purpose |
|---|---|---|
get_code_skeleton | low | AST-pruned skeleton of a file or symbol — signatures and types preserved, bodies collapsed |
search_tools | low | Discover tools outside the core set |
listConversations | low | List conversations |
previewConversationCleanup | low | Dry-run a cleanup query |
taskflow_create_task | medium | Create a task |
taskflow_list_tasks | low | List tasks |
deleteConversation | high | Delete one conversation |
deleteConversationsByQuery | high | Bulk delete by query |
requestConversationCleanup | high | Cleanup behind an approval |
dispatch_agent | high | Delegate a bounded run to a child agent |
run_task_graph | high | Execute a DAG of coding sub-tasks |
createTask / updateTask | medium | Task management |
getTodayTasks / queryTasks | low | Query tasks |
deleteTask | high | Delete a task |
addArticle / updateReadingStatus | medium | Reading list |
getReadingList / getReadingStats / recommendNext | low | Reading queries |
getDailySummary / getWeeklyStats / getReviewHistory | low | Review queries |
saveReview | medium | Persist a review |
memory_store | medium | Write a long-term memory (persistent influence, so not low) |
memory_search / memory_list | low | Read memories |
memory_delete | high | Delete a memory |
Every native tool declares its risk at registration; none of them rely on name or argument inference.
MCP tools carry the risk policy configured for their server (riskPolicy per level) and are registered on connect.
Resolution
Model requests tool "search_tools"
→ registry resolves native:search_tools
→ Permission Guard reads the declared risk
→ policy decides auto / notify / confirm / deny
→ execute, audit, returnResolution accepts both the bare name and the native: prefix, so the model does not need to know the namespacing.
Inspecting the registry
GET /api/tools— list registered toolsGET /api/tools/:id— one toolPOST /api/tools/filter— filter by source or riskPOST /api/tools/:id/execute— execute directly (still permission-checked)GET /api/tools/logs— recent call log
Next Steps
- MCP Servers — connect external tools
- Permission Guard — how risk becomes a decision
- Add a Custom Tool — register your own