Tools
Tools let AI models call external capabilities such as APIs, databases, or internal business logic. In the current platform, tools are created separately and then attached to prompt versions so the runtime can validate and execute them consistently.
What tools are
Each tool record currently includes:
- a stable
tool_key - a name and description
- a
type - an execution
config - an
input_schema - activation state and usage relationships
The app surfaces prompt usage and agent usage so you can see where a tool is already wired into behavior.
Current tool types
- Name
manual_stub- Description
A deterministic fixture-like tool that returns a configured result. Useful for demos, testing, and staged workflow design.
- Name
http- Description
A server-executed outbound call to an allowlisted host with secret-backed headers and runtime validation.
Execution model
The runtime treats tools as controlled capabilities:
- arguments are validated against the declared schema
- outbound hosts are allowlisted for HTTP tools
- secrets are referenced indirectly rather than embedded inline
- execution is recorded and contributes to overall run latency
The current app also makes clear that tool-enabled prompt versions can be reused by both direct prompt runs and higher-level orchestration.
API workflow
Create a tool
curl -X POST "$API_BASE/api/tools" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"organizationId": "org_123",
"toolKey": "lookup_policy",
"name": "Lookup Policy",
"type": "http",
"config": {
"url": "https://api.example.com/policies",
"method": "POST",
"allowlist": ["api.example.com"]
},
"inputSchema": {
"type": "object",
"properties": {
"orderId": { "type": "string" }
}
}
}'
Attach a tool to a prompt version
curl -X POST "$API_BASE/api/prompt-versions/version_123/tools" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"organizationId": "org_123",
"toolId": "tool_123"
}'