Key facts
| Loop | tools array on /v1/chat/completions; model returns tool_calls with JSON arguments |
| Execution | Your code executes tools; the model never holds credentials |
| Streaming | Function calling works with streaming on live chat models |
| JSON mode | Pair strict tool schemas with JSON mode for structured output |
| Model support | Tool support varies by model; verify per model in the catalogue |
| Status | Function calling is live; assistants and responses endpoints are coming soon |
| Loop | Send tools, execute tool_calls, append results, repeat |
| Testing | Validate schemas and arguments; fail closed on invalid output |
TL;DR
- A tools array on /v1/chat/completions; your code executes every tool call.
- Streaming and JSON mode work alongside function calling on live chat models.
- Schema quality decides agent reliability; test with adversarial inputs.
- Design against chat completions — assistants endpoints are coming soon.
- Start free with plugsky-micro and plugsky-lite; a 14-day full-access trial covers larger models.
How it works, step by step
- Write strict JSON schemas for each tool with typed fields and enums.
- Implement the loop and validate every argument before execution.
- Log model, tool name, arguments and result for each call.
- Write strict schemas and test them before wiring the loop.
- Validate arguments, retry once, then fail closed on invalid output.
- Log full traces and run regression scenarios on every model change.
Try it yourself
Open the function calling schema generator →
Function calling for developers: what changes
For developers, function calling is a predictable loop: declare tools, receive structured calls, execute, return results, repeat. The interesting work is schema design, validation and failure handling — the parts that decide whether an agent is reliable in production.
The mechanics are OpenAI-compatible: declare tools as JSON schemas in the request, receive tool_calls with structured arguments, execute them in your own service, then append the results and continue the loop. Streaming and JSON mode work alongside tool calls on live chat models, and because 30+ models sit behind one endpoint you can route steps by capability while keeping a single integration.
Architecture and controls
Write schemas with strict types and enums, validate every argument before execution, retry once on invalid output and fail closed. Keep write tools idempotent, and stream responses so users see progress while tools run.
Integration pattern and rollout
Prototype with the function calling tester, generate or check schemas, then wire the loop into your service. Test with adversarial inputs — missing fields, wrong types, repeated calls — and log the full trace for debugging.
Design for failure: models occasionally produce arguments that violate the schema, so validate strictly, retry once with the error appended, then fail closed and surface the case. Give each tool its own identity with least-privilege scope, keep an idempotency key on writes, and maintain a regression suite of tool scenarios that runs whenever a model or schema changes.
Limits, evidence and cost
Tool support varies by model, and smaller models make more schema errors, so verify per model rather than assuming. Function calling is live; assistants and responses endpoints are coming soon, so design against chat completions.
Self-serve plans are flat monthly with unlimited fair-use usage, so tool loops do not add per-token billing — check the live pricing page. The free plan covers plugsky-micro and plugsky-lite with no card, and the 14-day full-access trial lets you test the full loop before committing.
Honest comparison
| Concern | Plugsky function calling | Vendor-locked tool platforms | Building in-house |
|---|---|---|---|
| Interface | OpenAI-style tools array on chat completions | Proprietary assistants API | Custom schema and runtime |
| Execution | Your code runs tools inside your boundary | Varies; often vendor-hosted tools | You build the executor |
| Model choice | 30+ models; tool support varies by model | Vendor catalogue only | You host each model |
| Residency | Region-locked planes; VPC, on-prem and air-gapped | Limited region choices | Wherever you deploy |
| Status | Live on chat completions | Varies by vendor | Months of engineering |
| Loop ergonomics | tools array and tool_calls on chat completions | Proprietary runtimes | You build the runtime |
Frequently asked questions
How does the function calling loop work?
You send a tools array with the request, the model returns tool_calls with JSON arguments, your code executes them, appends results and calls again until the model answers.
Does the model execute tools itself?
No. Execution happens in your code, inside your boundary. The model never receives credentials, and your executor enforces permissions and validation.
Which models support function calling?
Function calling is live on chat models, but tool support varies by model. Verify per model in the catalogue and test your schemas before production.
Where do I start with function calling?
Send a tools array on /v1/chat/completions, execute returned tool_calls, append results and repeat. Test schemas with the function calling tester.
What if the model returns invalid arguments?
Validate against the schema, retry once with the error appended, then fail closed and surface the case for review.
Does streaming work with tools?
Yes. Streaming and function calling are live, so you can show progress while tools execute.