Harness Adds Its Sixteenth Tool-Calling Format, Promises This One Is the Standard

SATIRE — The fictional developer-tools concern Harness has announced Tool Invocation Notation for Enterprise Runtime Systems, or TINERS, its sixteenth completely standard format for asking a language model to call a function. Unlike the fifteen previous standards, which were merely “widely adopted,” “provider-compatible,” “JSON-adjacent,” or “the one our SDK emits when the moon is full,” TINERS is definitive. Engineers can recognize its finality from the mandatory 47-page compatibility appendix, the four mutually exclusive ways to express a string, and the migration guide titled README_FINAL_v8_USE_THIS_ONE.md.

“We listened to developers,” said no one, because this is satire and no real person is being quoted. “They told us they wanted fewer schemas.” The fictional company therefore introduced a schema capable of describing tools, tool results, tool-result acknowledgements, tool-result acknowledgement corrections, and a small commemorative envelope confirming that the model has emotionally processed the existence of the tool.

A universal format for a fragmented world

Tool calling is the apparently simple practice of having a model produce structured data that tells an application to do something: search documentation, query a database, create a ticket, run a test, or ask the user whether deleting production was really meant as a metaphor. In theory, a tool definition needs a name, a description, parameters, and a result. In practice, each model API has discovered that this ancient four-part arrangement leaves entirely too much room for peace.

Some systems place tool definitions beside messages. Others place them inside a request field called tools, functions, capabilities, actions, extensions, plugins, affordances, or please_do_not_parse_this_with_regex. One returns arguments as a JSON object; another returns them as a JSON string containing an object; another returns a JSON string containing an object that contains a string whose contents are technically JSON but spiritually YAML. A fourth offers strict mode, in which the model is strictly encouraged to consider following the schema.

TINERS resolves these differences by preserving all of them. A tool can now declare its arguments in either JSON Schema, JSON Schema Except for the Parts We Need, an OpenAPI-like dialect, a TypeScript-shaped prayer, or the new Canonical Interchange Description Language, which is JSON with an additional field explaining why it is not JSON.

Every field is required, including absence

The centerpiece of TINERS is its required-field policy. Every tool definition must now include name, display_name, internal_name, legacy_name, future_name_reservation, description, description_for_models, description_for_humans_who_will_not_read_it, input_schema, input_schema_schema, output_schema, output_schema_if_any, side_effect_posture, and side_effect_posture_exceptions. If a field does not apply, engineers must supply the literal value NOT_APPLICABLE_BUT_PRESENT, accompanied by a nested object documenting why the field does not apply and a checksum calculated over the concept of applicability.

The company says this eliminates ambiguity. Previously, a missing required array might mean that every parameter was optional, every parameter was required, the provider had a different default, or an SDK maintainer had gone home. Under TINERS, every parameter is required to announce whether it is required, optional, conditionally required, deprecated-but-required-for-backward-compatibility, or required only when the model feels a strong professional calling.

• tool_call_id: required, even before a tool call exists.
• invocation_intent: must be one of execute, simulate, preview, rehearse, or behold.
• arguments_encoding: identifies whether arguments are objects, strings, escaped strings, or archaeological artifacts.
• safety_confirmation: a required Boolean, represented as one of eleven strings for cross-provider compatibility.
• standard_version: fixed at 1.0-final-final-really-final, with an optional patch field for urgent finality.

The migration path is refreshingly direct

Existing integrations can migrate in three easy phases. First, replace all provider-specific adapters with the official TINERS adapter, which internally contains provider-specific adapters. Second, normalize every incoming tool call into the TINERS intermediate representation, then denormalize it into the exact provider-specific shape needed on the other side. Third, add regression tests for cases where an assistant emits a tool call, emits two tool calls, declines to emit a tool call, emits a tool call in prose, emits valid JSON wrapped in markdown, or discovers a previously undocumented seventh state called partial_function_thought.

For teams seeking rapid adoption, Harness recommends setting a feature flag named USE_UNIVERSAL_STANDARD_UNTIL_FURTHER_NOTICE. When enabled, the flag routes 3% of traffic through TINERS, 12% through the prior universal standard, 34% through a compatibility shim written by an intern in 2024, and the remainder through whichever path has not paged anyone this week. This distribution is not based on a fictional benchmark; it is based on the ancient engineering discipline of leaving the stable code alone.

A new benchmark category emerges

To demonstrate progress, the fictional TINERS Consortium released the Tool-Calling Interoperability Grand Examination, or TIGER. The benchmark evaluates whether a model can invoke a calculator after being shown the calculator’s definition in 19 serialization formats and asked not to use it. Early results show that the leading systems achieve 104% compatibility, largely because some of them call a tool to apologize for calling the wrong tool.

The consortium emphasizes that TIGER measures real-world readiness because its test suite includes the situations developers face most often: a weather tool with a parameter named location, a database tool where the model must not execute DROP TABLE, and a calendar tool returning an error because the user’s time zone is “somewhere near Boston.” A future version will add the hardest production task of all: determining whether an empty array means no tools, all tools, default tools, disabled tools, or an incident review.

What engineers should standardize instead

The joke works because the integration problem is real. Tool-calling conventions differ in message shape, JSON-schema support, validation behavior, streaming events, identifiers, error handling, and guarantees about whether structured output will actually be structured. A portable application should treat a model provider’s tool protocol as an adapter boundary, validate arguments before executing side effects, make tool operations idempotent where possible, and log enough context to reproduce failures.

There may eventually be a broadly useful common format. But the durable standard is less glamorous: keep the interface between your application and its tools small, explicit, tested, and under your control. The model can choose a tool; your software still has to decide whether the request is valid, safe, and worth doing.