Remove Rune's vestigial built-in $rune.search/$rune.describe (which only
saw effect-Schema Definitions, never our dynamic MCP tools) and the
reserved-namespace guard. Move our ranked search and typed describe under
tools.$rune.* — the runtime's own namespace, separate from MCP server
namespaces and collision-proof since $ never appears in a sanitized
server name. One discovery implementation, no dead code.
Replace the contiguous-substring search with tokenized, field-weighted
scoring adapted from the deferred-tool-search bridge (#34368): exact tool
name > path > description > indexed parameter text, summed across terms
and ranked by relevance. Index each tool's parameter names/descriptions
so tools are findable by their inputs. Keep the namespace filter and
{ items, total } shape. Add unit + end-to-end search tests.
Always list every MCP namespace, then inline a preview of individual
tools (path + brief) until a character budget is hit; remaining
namespaces show counts only. Front-loads a useful slice of the catalog
to cut discovery round-trips without dumping the full tool list.
Replace the in-process AsyncFunction engine with Rune.execute. MCP tools
are exposed as a host-tool tree (tools.<server>.<tool>) plus top-level
search/describe; each call is permission-gated and coerced to the
{ result, attachments? } envelope. Raise data limits for base64 media.
This adds real sandboxing: host globals are isolated and runaway loops
terminate via the operation limit instead of hanging the event loop.
Expose mcp.defs() so code mode can read MCP outputSchema. Tool calls and
the final return now use one { result, attachments? } envelope; media
blocks become FilePart attachments. describe renders typed signatures
with the structured return type when an outputSchema is present.
Drop the MCP-instructions blending from the execute tool description; just
list namespace names and tool counts on the tool definition. The full server
instructions already live in the system prompt's <mcp_instructions>, and
per-tool detail is fetched on demand via tools.search/tools.describe.
Shrink the execute tool description to namespaces only (server name, tool
count, and a brief note reused from the server's MCP instructions) instead of
inlining every tool signature, so the prompt stays small for large catalogs.
Add in-sandbox discovery: `tools.search(query, { namespace?, limit? })` returns
ranked tool paths + descriptions, and `tools.describe(path)` returns the full
signature and input schema on demand (with tool_not_found suggestions). The
proxy is now recursive so both `tools.<server>.<tool>(args)` and the dotted
`tools[path](args)` returned by search resolve to the catalog key.
Expose connected MCP tools to code mode as per-server namespaces
(`tools.<server>.<tool>(args)`) and generate the execute tool description
from the catalog: one namespace block per server, each tool rendered with a
TypeScript-style input signature derived from its JSON schema plus its
description, and the calling convention stated up front.
The server/tool split is cosmetic; child-call routing re-joins the segments
into the existing flat catalog key, so it stays exact regardless of
underscores in server or tool names.
Add an experimental, off-by-default `execute` tool that runs LLM-authored
JavaScript with a `tools.<name>(args)` proxy over connected MCP tools. When
OPENCODE_EXPERIMENTAL_CODE_MODE is enabled and MCP tools are present, the
session exposes the single code-mode tool instead of registering each MCP
tool directly; child calls route through the native permission path.
Code mode is defined via the standard Tool.define/Tool.init machinery so it
inherits arg decoding and output truncation from the shared wrapper. Tool
results are reduced to structured content or text, and the program's return
value is coerced to text without failing on shape.
Note: execution currently uses an in-process AsyncFunction with no isolation
or timeout; sandboxing is tracked as follow-up work.
Aiden Cline