KarstenSamaschke
Back to all writing

Field notes

Hayate Agent's Starter Setup Kept MCP Tools From Its Model

Hayate Agent's new /mcp command could connect a server and count its tools, while the model could not call one of them on the starter configuration. A fix 17 minutes later makes connected tools usable, and changes what a tools list without MCP entries means.

Karsten Samaschke · · 9 min read

Hayate Agent's Starter Setup Kept MCP Tools From Its Model

立冬や
繋いだ道具
手に取れず

Winter begins.
The connected tools
cannot be taken in hand.

This afternoon, Hayate Agent got a way to add and sign in to MCP servers from the chat itself, and the first release with it had a gap that the feature's own status output hid. With the starter configuration, you could connect a server, watch it report its tools, and the model still could not call a single one of them. A follow-up pull request, which its author says came out of checking the feature in actual use, closed that gap 17 minutes after the first one merged, and the next release followed about 20 minutes after the first. I think the fix is right, and it moves a line that anyone who restricts tools needs to know about.

Hayate Agent cover: red Japanese headline Hayate Agentの初期設定が モデルのMCP利用を阻んだ above the white English headline Hayate Agent's Starter Setup Kept MCP Tools From Its Model

All times are Europe/Berlin. The window is 9 November 08:00 to 20:00.

What /mcp added at 15:25

Core pull request #310 merged at 15:25 in the core repository of Hayate Agent (formerly the VanillaCore Agent). It adds /mcp as a host command in the terminal UI, Matrix and the WebUI: add, edit and remove servers, connect and disconnect them, list their tools, choose how the tools are exposed, and run an OAuth sign-in whose link and result come back to the same conversation. These are user commands handled by the host, not model turns. In Matrix and the WebUI only actors enrolled as Hayate administrators may use them. Release v0.1.212 followed at 15:30 from that merge.

Where the tools got lost

A Hayate configuration can have a tools list. If it is there and not empty, it selects the tools the model gets, plus a set of bundled workflow tools that Hayate always keeps reachable. If it is missing, the runtime defaults apply, and those were not affected by anything in this post. The configuration that setup writes for a new installation has the list and names seven tools: read, bash, edit, write, grep, find and ls. It names neither codemode nor tool_search, the two entrypoints through which the model reaches MCP tools indirectly, and no MCP tool, because nobody knows the server names in advance.

So with v0.1.212 and the starter list, the sequence went like this. /mcp add saves the server and switches MCP on. /mcp status probes the server and counts its tools. The open conversation loads MCP at its next prompt, and its tool selection still leaves every MCP tool inactive. The documentation at that commit did say so: "Existing explicit tool allowlists still apply; select the allowed MCP/codemode tools in your rollout when you restrict tools." It is a correct sentence. It also means a feature built so that nobody has to edit configuration files needed a configuration file edit before it did anything useful.

The fix: management reserves the entrypoints

Core #311 merged at 15:42, and release v0.1.213 followed at 15:50. When the native user management is active, which the Hayate command line now always switches on, the session adds codemode and tool_search to a non-empty tools list, and it adds the pattern mcp__*, which matches every MCP tool name, unless some entry on the list already starts with mcp__. The PR body lists the boundaries. The tool-list rules among them match the code at the merge:

  • The built-in MCP integration of a conversation loads only when MCP is enabled, the session is not ephemeral and the tools list is not empty. The short status probes of /mcp and connections that trusted plugins open themselves are separate from it.
  • If an entry on the tools list already starts with mcp__, mcp__* is not added, and the explicit entries restrict MCP tools. In a Hayate configuration file those entries have to be exact tool names such as mcp__github__search_code, because the configuration loader accepts only literal names and rejects *.
  • tools: [] still means no tools at all.
  • No unrelated non-MCP tool is added. A list without bash stays without bash.
  • Ephemeral sessions, which the harness uses for assessments, still get no tools.
  • Programs that embed the runtime as an SDK without switching user management on keep their explicit list exactly as before.

The test against the release before the fix

The pull request extends one test file, test/mcp.test.ts. The changed test starts a session with only the read tool, enables MCP on the open session through the same call the management uses, and waits for a small local stdio server to report its tool. It then asserts that the tool is not just discovered but active, and that bash did not appear. A second addition checks that an explicit mcp__only_allowed__* pattern still keeps another server's tool away. That test builds the runtime directly. The same pattern in a configuration file would be rejected by the loader.

The AI agent that drafts these changelog posts ran the file from the fix at two commits, with dependencies installed fresh in each tree, on macOS with Node 22.22.3. The file contains one test.

Commit Release Result
e00cbcf, merge of #310 v0.1.212 0 of 1 pass
fdcf419, merge of #311 v0.1.213 1 of 1 pass

On v0.1.212 the test gets past the check that the server's tool was discovered and fails on the next one, with the message "user-connected direct MCP tool is actually exposed, not merely probed". That is the gap in one line: connected, discovered, counted, and not available to the model. On v0.1.213 every assertion passes, including the namespace restriction and the check that bash stays out. The test uses a local fixture server and a stubbed model prompt. It is not a live installation with a real MCP server and a real model. The author reports 1660 passing tests and one optional skip for the full suite. I did not rerun the full suite.

What changes for you if you restrict tools

Before #311, a non-empty tools list like the starter list, without codemode, tool_search or any mcp__ entry, kept MCP tools away from the model. After it, the same list lets every tool of a connected server through in the exposure configured for that server or tool, and only tools marked hidden stay out. Connecting a server is still an explicit administrator action, and MCP is still off until someone turns it on, so I think the new default matches what a person who types /mcp add expects. But the meaning of a list you wrote earlier has changed. If you want MCP tools limited, put the exact mcp__<server>__<tool> names you allow on the list. A wildcard like mcp__github__* does not pass the configuration loader at this commit. If you want no tools, tools: [] still does that. The documentation also says plainly that the tools setting is not a process sandbox or a network policy, and that trusted plugins can open their own connections.

Also in the window

Core #308 (12:32) and #309 (12:37), with plugins #76 (12:39), remove built-in workflow rules from the harness. According to the PR bodies, review is off by default, all mandatory gates are false, enabling advisory review alone activates no gate, and the nightly prompts no longer invent merge bans or a mandatory review that the operator never configured. Workflow restrictions are meant to come only from the operator's own configuration. Releases v0.1.210 (12:41) and v0.1.211 (12:52) carry these two merges. I did not test this change for this post.

Plugins #75 (12:59), with WebUI #12 (12:59) and #13 (13:35), fix dashboard logouts at the one-hour boundary and after a backend restart. Sessions are renewed only on real user input, not by polling. The authors list three limits: existing memory-only sessions need one fresh login, configured session lifetimes shorter than the one-minute renewal cadence can still expire during use, and full authenticated browser tests over TLS are still a follow-up. They state that nothing was deployed.

Core #306 (08:56) and #307 (08:59) and plugins #74 (11:05) tighten how the nightly work run counts completed work and proposes completion. Release v0.1.209 (09:23) is built from #307. Plugins #77 (15:35) adds acceptance tests for /mcp through the actual WebUI routing.

What merged and what was tagged

In core, six pull requests merged in the window, #306 to #311, and five releases were published, v0.1.209 to v0.1.213. Each release tag resolves to the merge commit of one of those pull requests. The fix commit of #311 is not contained in v0.1.212, so v0.1.212 is the one release with /mcp and without the fix. In plugins, four pull requests merged (#74 to #77). In webui, two (#12, #13). Deployment-base had none. When checked at 20:18, core main had moved past the window: #314 and #313, two memory changes, merged at 20:05 and are not part of this post.

A tag marks the source of a published image, and it is not a deployment. Nothing here verifies that any running installation uses v0.1.212 or v0.1.213.

Verdict

A connect button that cannot connect the model is a status message, not a feature. For the starter setup, the fix makes connected mean usable, and the price is that a tools list without MCP entries no longer keeps MCP out. List the exact MCP tools you want before you connect anything.

Sources used