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 |
| Oversight | Human review for state-changing actions; audit every tool call |
| Deployment | Tools can run in-region, on-prem or air-gapped on your side |
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.
- Read-only tools first; state changes stay behind named human approval.
- Every call is attributable: model, arguments, result and approver.
- 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.
- Pilot read-only tools on citizen-facing enquiries with full tracing.
- Require named staff approval before any state-changing action.
- Run tools inside the approved deployment boundary with RBAC.
Try it yourself
Open the function calling tester →
Function calling for government teams: what changes
Government function calling connects models to case systems, registries and service workflows, so oversight matters as much as capability. Every tool call should be attributable, reviewable and bounded by the authority the user actually holds.
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
Restrict tools to approved systems and data, enforce human review for state-changing actions, and log model, arguments, result and approver for each call. Run tools in-region or air-gapped where classification requires it.
Integration pattern and rollout
Pilot with read-only tools that answer citizen enquiries or locate case status, prove the audit trail end to end, then add tools that prepare actions for staff approval. Keep the executor under your own identity and network boundary.
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
Function calling does not confer legal authority, and automation bias is a real risk: staff must retain meaningful review. Certification posture is readiness in progress, so document the controls you can evidence.
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 |
| Oversight | Human review for actions; complete audit trail | Limited approval features | You design accountability |
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.
Can function calling run air-gapped?
Yes. Tools execute in your environment, so an air-gapped deployment keeps both inference and execution inside the boundary.
How do we keep human oversight?
Restrict tools to read-only or proposal actions, and require named staff approval before any state change.
What is logged for each call?
Model, tool name, arguments, result and approver. That trail supports review, appeals and audit.