← Tours

Tool-format taxonomy — tool_use vs XML vs OpenAI fn

Engineers picking a tool-calling format for a new agent.

45 minutes · 6 stops

Tour — Tool-format taxonomy

Three live formats. Each makes one thing easy and another annoying. The choice cascades into how you stream, how you parse, and what your provider abstraction looks like.

Pacing

BlockTime
Concept · tool-calling-formats15 min
Drill-down · Claude Code’s tool dispatch10 min
Drill-down · Strix’s XML parser10 min
Drill-down · Kimi Code’s openai-fn handler5 min
Insight + provider-abstraction concept5 min

Decision matrix

After the tour, fill in this matrix for your project:

QuestionYour answer
Will you support multiple providers?
Is streaming required?
Is the model instruction-following enough for XML?
Do you need parallel tool calls?
How important is provider-native feature surface?

The tour’s concept page maps each profile to a recommended format.

Output

You should be able to defend a choice between native, OpenAI-fn, or XML to a teammate in under 90 seconds, with the cascading consequences (streaming, partial JSON, provider abstraction) lined up.

For your specific projects

Swisscheese likely inherits the format of the underlying coding agent (tool_use for Claude Code, OpenAI fn for Codex). The interesting decision is at the harness layer: do reviewers speak the same format, or are they MCP tools? Pick based on whether you’ll ever ship third-party reviewers.

AI Act compliance wants the format that makes it easiest to audit tool calls. All three formats produce structured records, but JSON-string-of-JSON (OpenAI fn) is mildly worse for human auditors than nested objects (Anthropic) or tagged blocks (XML). Worth considering when you choose.

Itinerary

  1. Tool calling formats concept

    Side-by-side of the three formats with their tradeoffs. Read first.

  2. Claude Code project

    Native tool_use as designed; the cleanest case for a single-provider agent.

  3. Strix project

    XML <function> blocks; provider-agnostic and streams cleanly. The unconventional bet that pays back.

  4. Kimi Code project

    OpenAI fn-calling on a non-OpenAI provider — the de facto cross-provider standard.

  5. Streaming early stop on </function> insight

    Why XML format unlocks a free 10–20% per-step cost win.

  6. Provider abstraction concept

    How your format choice constrains the provider abstraction you'll need.