A tool gives a session a specific way to read information or make a change. Inspect its name, input, target and expected effect before approving it. A tool appearing in a catalog does not mean the current session can execute it.
This guide targets Sonny 0.12.7, build commit
192e590345c6a4bf1ef8f72b043b318084ea84d6. The inventory commands were executed
with the installed Linux binary in a private environment. They qualify the
reported declarations; they do not certify every tool, service, client or
platform. Start with the installation and access guide
if you
do not already have an approved Sonny installation.
Inspect your installation
Run these commands under the account and environment that will run the task:
sonny version
sonny tools list --json
sonny tools inventory --format json
These commands inspect metadata. They do not launch a browser, run the tools listed, or connect an external MCP server. The tested default listing reported 72 registered tools. Its JSON contains names, descriptions and parameter schemas. The separate Recipe contract reported 16 core names, two triggered unlock groups, 111 searchable entries and 73 retired-name records. Retired records include compatibility aliases; they are not 73 additional tools.
The commands answer different questions. tools list builds a default registry
for inspection. tools inventory describes the contract Recipes can target,
including tools added only by a live session or a configured subsystem. A live
session can expose a different set after Recipe limits, configured services,
provider limits and policy are applied. Compare the session’s own discovery
result with the saved contract before relying on a capability.
Download the captured registered tools and parameter schemas and Recipe discovery contract . Both files identify their version and evidence scope. Use fresh output from your own installation when its release, configuration or connected services differ.
Find a tool inside a session
Ask Sonny to find the narrow tool for the task, such as reading one local note.
tool_search returns matching tools and their execution names. For a local
searchable tool, that name has the form local.<name>; for a connected MCP tool,
it has the form <server>.<tool>. tool_exec must use the exact name and
arguments returned for that session. Discovery does not approve execution.
The core contract names tool_search, tool_exec, think, read_file,
edit_file, write_file, delete_file, exec, find, todo_add,
todo_update, todo_list, todo_delete, spawn_agent, agent_search and
wait. The contract unlocks agent-process inspection and integration names
after spawn_agent, and job output/stop names after exec. This is the
contract’s organization, not proof that delegation or a job was created.
Sessions and goals
describes the separate lifecycle limits.
If discovery returns zero matches, check the installed version, Recipe scope, subsystem configuration and MCP connection. Do not guess an execution name or repeat an external action to compensate for missing results. A tool-call refusal can occur inside an otherwise successful command or conversation; inspect the actual tool result and its target-side effect.
Review access and effects
Built-in tools arrive with the approved binary. Optional subsystems may also need an installed language server, converter, worker or service. Review that subsystem’s setup and the discovered schema instead of installing a similarly named package and assuming it supplies the capability.
| Tool family | Availability and setup | Permission and effects to review | Limit or recovery |
|---|---|---|---|
| Local files, search and structured data | Core plus searchable tools, within the session’s workspace and permitted roots | Reads disclose content to the model; edits, replacements and deletes change files | Inspect the current file and scope before a write. A stale or partial basis can be refused; obtain a fresh appropriate read before reviewing another edit. |
| Shell, toolchains and jobs | Requires the selected execution boundary and requested executable | Commands can write files, start processes or contact services; background jobs outlive one result | Review the exact command, directory and timeout. Inspect job output before stopping or repeating work. A timeout does not roll back effects. |
| Version control and local CI | Searchable vcs_* and ci_* tools; uses the workspace’s repository/configuration | Staging, commits, resets, stashes, branches and local jobs alter state; fetch/pull contact a configured remote | Inspect the operation and remote. An available VCS tool is not blanket permission to publish or discard changes. |
| Web and downloads | Searchable fetch/download, subject to effective network policy | Requests disclose their target and supplied data; downloads create local content | Review destination, output path and returned status. A network allowlist does not prove a successful fetch. |
| Memory, plans and tracing | Added or scoped by their subsystem; see memory and plan mode | Durable records, plan state and diagnostic artifacts may contain private task data | Check session, project and tenant scope. Listing or exporting a record does not delete it. |
| Documents, archives and analysis | Searchable entries; some need an approved local converter or runtime | Reads disclose document content; conversion, extraction and edits create or replace files | Use the schema’s supported format and inspect the output. Archive paths and converter availability remain execution checks. |
| Language servers and agent processes | Optional runtime collaborators; contract names alone do not start them | Starts processes and may retain workspace state or create child work | Confirm the owning session and live process. Delegated-worker and cross-client behavior need their own qualification. |
| CANARY, project templates and conversation data | Optional project/runtime setup; inspect the exact entry | Indexing, tests and evidence collection can write artifacts or access data beyond one file | A producer exit code, imported record or available template is not independent verification of the task. Review actual evidence and collection scope. |
| External MCP | Separately install, configure, connect and trust the intended server | Server-specific reads and writes can affect a remote account; connecting exposes its advertised schemas | Follow MCP connection and trust . Built-in catalog entries do not supply server credentials or prove its availability. |
| Browser and system-resource automation | Not exposed in the tested 0.12.7 local or managed TUI sessions | No browser operation was admitted in those runs | Read the release boundary below. An installed browser or source descriptor does not establish a supported connection. |
The security guide explains workspace trust, credentials and isolation. Recipe tool scope narrows the available set; it does not replace host policy, an execution grant or a requested operator approval. Review a specific consequential action at the point it is proposed.
Browser availability in this release
The tested local TUI found no browser_launch tool. Its effective network
policy was none. A separate managed-node test reached an attached native TUI
with required, verified Docker isolation and an exact-origin network allowlist.
That session also found no browser_launch: zero matches among 117 available
discovery entries. No page was opened or submitted in either case.
The source includes disposable-browser descriptors and a Linux adapter, but those declarations do not establish a callable browser integration in these installed clients. A browser read-only journey, separately reviewed form submission, screenshot and browser recovery remain unqualified. Installing Chrome, changing a Recipe tool list or connecting a generic MCP transport does not by itself resolve that boundary. Do not lower isolation to make the example appear to work.
The related browser and system-resource work is release tracking, not an availability guarantee. Check the supported release and connection instructions supplied for your approved integration before using browser automation on a real account. When a session cannot discover its browser tool, retain the version and discovery result for support; no browser side effect should be inferred from the conversation’s completion message.
Extend a task deliberately
For a custom integration, start with APIC , then connect and review its server through the MCP guide. Use lifecycle hooks for reviewed event logging or validation: hooks execute through a separate configuration and trust path, so disabling a model tool does not disable a hook command. Confirm which session or service owns a resource before reusing it for another task.
The resource reuse guide explains repeated file reads, realm copies, write observations and the installed lifecycle limits.