Skip to main content

v0.7.3

/tools is now one list — the tools iota ships with, then each MCP server, with its tool count and how it stands — and Enter opens a page for one of them, from which a server can be reconnected without leaving the chat. When a server does fail, the notice says what went wrong and what to check instead of quoting the library. A server that dies mid-session is shown as stopped, and a tool call it never answers no longer holds the turn forever.

Changed​

  • /tools is one list of where the tools come from. The two tabs, Tools and MCP, are now one list: built in first, then each MCP server, with how many tools it has and how it stands — connected, connecting…, down, needs login or failed, with the reason in a few words. Enter opens that source's page; Esc goes back to the list.

     4 MCP servers · 10 tools · Enter: open · Esc: close
    ▸ built in  2 tools  available
      dead      3 tools  down: exited (its last stderr line: "mock_mcp: <- tools/list") — its tools will fail until it …
      flaky     3 tools  down: exited (its last stderr line: "mock_mcp: <- tools/list") — its tools will fail until it …
      ok        2 tools  connected
      refused   —        failed: can't reach http://127.0.0.1:1/mcp: connection refused — check the url, and that the s…

    A server's page shows its endpoint, transport, login, the names its tools go by, its call timeout, the full reason it failed — its stderr included — and its tools.

  • An MCP server can be reconnected from /tools. Press Enter on a server's page: it reconnects in the background, the page shows it happening and how it went, and the chat gets one line — MCP db reconnected · 3 tools, or why it did not. A reconnect that fails does not take a server's tools away: one that had tools stays down with them, showing why the new start failed, and you can try again. A server you have just logged in to with iota mcp login no longer needs a new chat to use the login — reconnect it from its page.

  • MCP failures say what happened and what to do. A server that did not connect used to be reported in the MCP library's own words — Rust type names, when send initialize request, sometimes a proxy's whole HTML error page — with the actual reason buried or missing. Now the notice is one line that names the server, what went wrong and what to check:

    ⚠ MCP nb: can't reach https://example.com/mcp: connection refused — check the url, and that the server is running · details in /tools

    A 404, a 5xx, a web page where the MCP endpoint should be, a command that is not installed, a server that exits during startup (its last stderr line is shown), a handshake that never finishes and a rejected header are each worded the same way. The full cause and the server's stderr are on its page in /tools, and under the warning in a headless run.

  • rustls is 0.23.46 (RUSTSEC-2026-0346, -0347, -0348, -0349). Only the last one applied to iota: a network attacker who answered one connection could make later connections to the same host fall back from the post-quantum hybrid key exchange to X25519 alone — a loss of post-quantum protection, with no key exposed and no server authentication bypassed. The other three need a session store, Encrypted Client Hello or the brotli feature, none of which iota uses.

Fixed​

  • An MCP server that stops mid-session is shown as stopped. A stdio server that was killed or crashed used to stay connected in /tools, with nothing said in the chat. Now it shows as down as soon as /tools is opened or a call finds it gone, and the chat says so once, with the last line it wrote to stderr:

    ⚠ MCP db: exited (its last stderr line: "RuntimeError: database connection lost") — its tools will fail until it is reconnected from /tools · details in /tools

    Its tools stay available to the model, and a call to them answers with a sentence saying the server has exited and can be reconnected from /tools, instead of Transport closed.

  • A tool call an MCP server never answers no longer hangs forever. Every MCP tool call now has a deadline — 30 minutes by default — after which it is given up and the model is told why. A server whose tools legitimately run longer can raise it with tool_timeout_sec: in its mcp_servers entry.

  • A herdr pane no longer stays working after the chat runs another agent. When the model ran an agent from the shell — claude -p …, say — that agent's herdr integration took over iota's pane, and herdr then ignored iota: the pane showed working with the chat idle until it was closed. Inside herdr, the shell tool's commands and the MCP servers now start without HERDR_ENV, so an agent started there leaves the pane to iota. The herdr command line works as before, and an agent the model starts in a pane of its own still reports there.

  • Resizing a slow or busy iota no longer breaks the screen for good. When iota was starved of CPU — at background priority, or on a heavily loaded machine — one late answer from the terminal during a resize could put every later one off by one: the prompt drawn mid-screen with its top line gone, the last lines of a reply lost, and the same again on every later resize. Now a slow machine makes a resize slower, and at worst a drag repeats a few of a reply's last lines in the scrollback; nothing is lost, and the prompt stays whole at the bottom.

  • A background job that finishes while no model is chosen no longer leaves the chat busy. If its result woke a chat with no model yet and you cancelled the model choice, herdr, cmux or the terminal's progress indicator kept showing the chat as busy until the next turn. It now shows it idle.