​
Buyer-side validation

Emitted tool_calls[] reflect model output, not provider-verified intent.
For tool-calling responses, emitted tool_calls[] reflect model output, not provider-verified intent. Buyer-side agent frameworks MUST validate before execution. Malibu delivers the parsed OpenAI-compatible shape. It does not decide whether a requested tool name or argument payload is safe for your agent policy. Treat emitted tool calls with the same trust posture you would apply to a model running on local hardware: parsed output, not provider-verified intent.

​
What Malibu guarantees about a tool_calls[] payload

  • Declared names only. Malibu emits a tool call only when its name is in the tools array you sent with that request. Calls to any other name come back as plain text, not as tool_calls[].
  • Well-formed arguments. function.arguments is a JSON-encoded string holding a JSON object. Duplicate keys and malformed JSON are never emitted as a tool call.
  • OpenAI wire shape. Your existing OpenAI-based parsing and validation code works unchanged.
  • Size caps. Each emitted function.arguments is capped at 1 MiB, all arguments in one response at 2 MiB, and argument nesting at 32 levels. On the request side, each role: "tool" message is capped at 256 KiB. See Tool calling → Limits.
  • Signed receipt. The provider’s signed receipt covers the response output, tool_calls[] included. Verifying it tells you which provider signed which output for which prompt. It doesn’t tell you the call is safe to run.

​
What Malibu does NOT do

  • Check the arguments against your tool’s parameters schema. A call can name a declared tool and still leave out required fields or carry values of the wrong type.
  • Judge whether the arguments are safe. For example: is path inside your sandbox, is sql read-only, is command on your executable allowlist?
  • Confirm the model “meant” to call this tool. A model can be prompt-injected into emitting a call to a declared tool, and the receipt will still verify that it did.
  • Rate-limit tool calls per user or session. That’s your app’s policy.

​
Minimum validation checklist

Before you execute any emitted tool call:
  1. Name allowlist. Is call.function.name one of the tools you registered for this request and this user?
  2. Schema check. Does json.loads(call.function.arguments) validate against the JSON schema you declared for that tool?
  3. Argument-level policy. For each argument that points at a resource (a path, URL, SQL statement, or shell command), does it satisfy your agent’s isolation policy?
  4. Rate limits. Is the user or session still within its tool-call budget?
  5. Confirmation for destructive actions. For tools that change state, require user confirmation or a dry run first.

​
Frameworks

Agent frameworks such as Cline, LangChain, and LlamaIndex parse Malibu’s tool_calls[] like any OpenAI response. How much validation happens before a tool runs depends on the framework and on how you configure it: approval prompts, argument schemas, allowlists. This obligation is the same whether the model runs on OpenAI, on a local Ollama, or on a Malibu provider. If you write your own agent code, put the validator between the model response and the tool executor. Don’t skip it because the receipt verified.