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 |
| Registry | Version tool schemas centrally and treat them as interfaces |
| Boundary | Tools execute inside your network; the model holds no credentials |
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.
- A tool registry with owners and versions prevents an unmanaged execution surface.
- Authorization stays in your gateway; the model only proposes calls.
- 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.
- Create a tool registry with schema versions, owners and review gates.
- Route execution through a gateway with per-tool identity and policy.
- Define deprecation and rollback paths for tool changes.
Try it yourself
Open the tool registry builder →
Function calling for enterprise architects: what changes
Enterprise architects treat function calling as an integration pattern: a contract between model output and real systems. Done well, tools look like versioned interfaces with owners, policies and audit; done badly, they become an unmanaged execution surface.
Function calling on Plugsky is a loop around /v1/chat/completions: you send a tools array of JSON schemas, the model returns tool_calls with arguments, your code executes them inside your own boundary, appends the results and calls again until the model produces a final answer. Streaming works with tools, and JSON mode pairs with strict schemas for structured output. Tool support varies by model, so verify it per model in the catalogue.
Architecture and controls
Maintain a tool registry with schema versions and owners, route execution through a gateway that enforces policy, and give each tool its own identity and least-privilege scope. Keep execution inside your network boundary.
Integration pattern and rollout
Standardise the loop across teams: shared schema conventions, argument validation, idempotency keys and trace logging. Review tools like any API change, including deprecation and rollback paths.
Treat tool schemas as code-execution boundaries. Validate every argument against the schema before it reaches a system, scope each tool to least privilege, make write operations idempotent, and fail closed on invalid output. The model never holds credentials; your executor does. Log model, tool name, arguments and result for every call so reviewers can reconstruct decisions.
Limits, evidence and cost
The model is not a policy engine: authorization stays with your gateway and services. Plan for tool version drift and model differences, and be explicit that function calling is live while assistants-style endpoints remain roadmap items.
Function calling is available on live chat models across plans — see the live pricing page for current tiers. Start free with plugsky-micro and plugsky-lite and no card, then use the 14-day full-access trial to evaluate larger models against your tool scenarios.
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 |
| Tool governance | Registry, gateway and least-privilege identity | Vendor portal | You run every control |
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.
How do we govern tools across teams?
Keep a registry with schema versions and owners, route execution through a gateway, and review tools like any API change.
Who holds credentials for tools?
Your executor does. Give each tool its own identity with least-privilege scope, and never pass credentials to the model.
What about model differences?
Tool support varies by model. Standardise on models that pass your schema tests, and keep the loop model-agnostic where possible.