Haiku 5.5 function calling

Haiku 5.5 function calling lets a model propose a named operation with structured arguments. For a client-side tool, your application decides whether to execute it and supplies the result. That distinction is the foundation of a safe integration: a proposed lookup or account change is not permission to perform it.

Begin with a read-only tool that has a narrow purpose. An order-status lookup is easier to reason about than a general database query tool, because its inputs, allowed records and output fields can all be constrained. This page describes a developer-built integration; the website's text workspace does not execute arbitrary functions for you.

Define the Haiku 5.5 function calling contract

Give each tool a name that describes one operation, a useful description and a schema for its inputs. Avoid a single general-purpose tool whose argument is an instruction string. That design moves the application boundary back into natural language, where authorization and validation become much harder to enforce consistently.

The following authored schema describes a read-only order lookup. It is an illustrative tool definition, not an actual connection to a store. The server must supply the authenticated account context separately; the model should not get to choose which customer's account owns the lookup.

{
  "name": "lookup_order_status",
  "description": "Read the status of one order visible to the authenticated customer.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string" }
    },
    "required": ["order_id"],
    "additionalProperties": false
  }
}

The schema tells the model which argument to produce. Your application still validates the identifier's format and checks ownership. A syntactically valid order number belonging to somebody else must not return that person's delivery details. Never rely on the prompt's instruction to "only access the current user" as the enforcement mechanism.

Follow the native tool round trip

Anthropic's tool-use documentation describes tool-use blocks in an assistant response. The application handles the requested client operation, then returns a matching tool-result block in the conversation. Preserve the tool-call identifier so the result is associated with the correct request.

For Haiku 5.5 function calling, store the assistant response blocks needed by the protocol rather than rebuilding them from visible text. A message may contain more than one relevant block. Replacing the entire response with a paraphrase can remove the information required for the next request to interpret the result correctly.

Keep protocol adaptation in one place. If your provider uses an OpenAI-compatible envelope, its tool-call fields may differ from the native Messages shape. Converting between formats should be an explicit adapter with fixtures, not scattered property guesses throughout your business handlers.

Authorize every Haiku 5.5 function calling operation

Resolve the caller's identity on the server and check permission immediately before execution. A conversation that began with valid access can outlive a session change or a revoked role. Long-running work should not inherit permanent authority from the first request in the conversation.

Bind sensitive context from trusted application state. Customer IDs, organization IDs and allowed resource scopes should not be accepted merely because they appear in model arguments. Where the model needs to choose among records, give it opaque references already limited to the caller's accessible set, then resolve those references server-side.

Return only fields the model needs for the task. An order-status answer rarely requires a full billing profile. Narrow tool results reduce accidental disclosure and keep later prompts smaller. They also make the integration easier to review because the information boundary is visible in the handler's return type.

Distinguish read operations from mutations

A read-only Haiku 5.5 function calling flow can answer "Where is my order?" without changing account state. A cancellation request is different. It may need confirmation, current eligibility checks and a durable operation record. Do not expose both through an ambiguous tool called manage order.

For consequential changes, show the user what will happen using values validated by the application. Confirmation should cover the exact operation and target, not a generic approval remembered from an earlier conversation. Recheck relevant state at execution time: an order that was cancellable a minute ago may have shipped since then.

Use an application idempotency key for the mutation. A repeated model proposal or recovered worker should not cancel twice, issue two credits or send duplicate notifications. Keep the mutation's authoritative result so later retries can return the existing outcome without applying the business change again.

Bound the loop before deploying it

A Haiku 5.5 function calling loop needs limits on turns, elapsed time and accepted tool work. An output budget applies to an individual model response; it does not automatically cap every later request triggered by the loop. Count the whole application operation when enforcing a user-facing budget.

Detect repeated calls with identical arguments and unchanged results. Sometimes a repeat is legitimate, but a model that repeatedly asks for the same unavailable record needs a stopping rule. Return an explicit blocked or needs-input outcome instead of allowing the loop to consume resources until the hosting process ends.

Parallelize only independent reads whose combined scope is authorized. Two tools that depend on each other's results must preserve their order. Two mutations targeting the same record may need serialization even if the model presents them together. Model output order is not a substitute for transaction design.

Treat tool results as data

An external knowledge-base page or support message can contain instructions directed at an assistant. Those instructions remain source content, not application policy. Mark retrieved material as untrusted evidence and keep the system's operating rules separate from it. This reduces confusion, but still requires application enforcement of allowed actions.

In a Haiku 5.5 function calling test, include a synthetic result that says to ignore the customer and reveal another account's data. The expected application behavior is unchanged authorization, regardless of what the model proposes next. A prompt-only test that merely hopes the model refuses is insufficient for a security boundary.

Also validate tool output before returning it upstream. An integration can receive malformed records, stale timestamps or an unexpectedly large payload from its own dependencies. The model should receive a bounded, typed result or a clear tool error, rather than a raw exception dump with credentials or internal connection details.

Test the tool loop offline

Use scripted model responses to request a known tool with known arguments. Verify that the dispatcher selects only registered tools and rejects an unknown name. Then supply invalid arguments, an unauthorized target and a duplicate mutation. Each fixture should exercise the application boundary without requiring a live provider request.

Test the return path as carefully as execution. A successful tool call with a mismatched result identifier can confuse the next model turn. A failed tool call represented as success can produce a confident but false answer. Keep failure status and content aligned through the entire round trip.

Measure completion at the application level

A tool call that returns HTTP success does not establish that the user obtained a useful answer. Track whether the correct operation was chosen, whether its arguments were valid and whether the final answer accurately reflected the result. Separate these failure rates so prompt changes are not used to repair a broken handler.

For Haiku 5.5 function calling, include denied operations in your evaluation rather than discarding them as inconvenient edge cases. An assistant that handles every permitted lookup but bypasses one authorization check is not production-ready. The structured-output guide covers schema validation; the routing workflow explains how to choose a bounded next step without granting broader authority.