Skip to content

TAPI Design

Toolapi shortcomings

The following are the problems which prompt a redesign of the toolapi:

  • Fixed exchange data structures force frequent toolapi updates when iterating on tool data
  • Opaque communication format and websockets make ad-hoc LLM coded solutions hard
  • Compiled Rust core is difficult for targets like pyodide
  • No caching forces large data transfers on every call

Original design goals that have proven themselves: - Tools are really easy to deploy and to call - Interface makes language-agnostic tool / server combinations easy - Live progress messages and abortion is possible

New and improved TAPI

In the new version, we will no longer enforce structures like phantoms or sequences. Instead, any data can be sent via CBOR. Phantoms and sequences use widespread open-source standards like Pulseq or BIfTI. Big data is not sent in the message directly, instead TAPI introduces data pointers. These are CAS (content-addressable storage) references where the message just contains the hash of the binary blob. The server or the client can then, at any time, request this data from another. This allows two things: - The server can cache phantoms and other data and only request on change (new hash) - The client can opt to not even download data and act purely as server control script

A second improvement will be extended server and slimmed-down client libraries. The server supports a websocket connection, but also messages over HTTP (and even other channels?). It also can communicate in other formats like JSON or messagepack instead of CBOR. This server library is written in Rust and provides a python wrapper and is designed to run directly on Linux or Windows (no WASM or other hindrances). The client on the other hand never uses wrappers; there is a native Rust, Python and JS client. It only supports one of the options (possibly the idiomatic WebSockets + CBOR). Those native wrappers then can run in the Browser or even Pyodide directly. Other applications (like talking to a tool over HTTP+JSON) are documented but not provided as libraries. This and a documented exchange format should make it really easy for LLMs to grasp the idea and write ad-hoc clients for unsupported languages.