Code Mode and tool search

Hayba has more than 450 tools. Listing all of them to an agent up front would fill its context before it did any work. So the server starts with 7 tools, and the agent searches for the rest when it needs them.

The 7 startup tools

Tool	What it does
`hayba_search_tools`	Finds tools from a plain-language description, such as "make a menu widget". It searches the whole catalogue, including tools that are not loaded.
`hayba_invoke`	Calls a tool by name with its arguments, whether or not its pack is loaded.
`get_tool_signature`	Returns one tool's parameters, return shape and cost.
`list_tool_categories`	Lists every domain and the tools in it.
`hayba_pack_list`	Lists the tool packs and which are loaded.
`hayba_pack_load`	Registers a pack's tools natively, so they appear in the client's tool list with full schemas.
`hayba_check_ue_status`	Reports whether the editor is reachable, and its engine and plugin versions.

The first of these an agent calls also returns a short orientation note, so the agent knows the rest of the catalogue is one search away.

Finding and calling a tool

A typical exchange, when the agent does not know the tool name yet:

hayba_search_tools with query: "spawn a static mesh at a location" returns actor_spawn_from_asset, actor_spawn and others, with short descriptions.
Optionally, get_tool_signature with command: "actor_spawn_from_asset" returns its parameters.
hayba_invoke with name: "actor_spawn_from_asset" and args: { "asset_path": "/Game/Meshes/SM_Rock" } runs it.

hayba_invoke checks the arguments strictly. A misspelt or unknown parameter is refused, and the error names the parameters the tool accepts, rather than the value being dropped quietly.

If a name is not a server tool but is a plugin command marked callable, hayba_invoke passes it straight to the plugin. The tool reference marks these as plugin commands.

You do not have to name tools in your prompts. Describe the task; the agent searches. Naming a tool helps when you already know the one you want.

Packs

Tools are grouped into packs. A domain pack holds one subsystem's tools; a workflow pack bundles tools for one task across subsystems. On this version there are four workflow packs: biome, connectors, editor and python.

Loading a pack with hayba_pack_load is an optimisation for repeated calls into one area, not a requirement: hayba_invoke already reaches every static tool. When hayba_check_ue_status confirms the editor is connected, the server loads the editor pack by itself. It adds viewport capture, the log stream, Play-In-Editor start, the shader and idle waits, and camera renders.

Eleven tools are built when the server starts, because they depend on live objects: the asset search index, slivers and the history journal. They show up in search, but on this version hayba_invoke cannot call them. Load their pack first. The tool reference marks each one.

Other routing modes

The server reads optional settings from Saved/HaybaMCP/settings.json in its working directory, or from the file named by HAYBA_SETTINGS_PATH.

settings.json

{
  "toolRouting": "deferred",
  "alwaysLoadPacks": ["editor"]
}

toolRouting: "deferred" is the default described on this page.
alwaysLoadPacks loads the named packs at startup.
toolRouting: "full" drops search and packs. The server then registers only list_tool_categories, get_tool_signature and python_run. To register every tool natively instead, also set the environment variable HAYBA_CODE_MODE=off. That puts the whole catalogue in the agent's context, so use it only with clients that handle very large tool lists.

The editor's Progressive tool discovery setting is stored with the plugin settings; the server takes its routing from the file above.