Your own AI tool, from your own API — configured, never coded
Point at your API, map what it returns, tell the AI when to use it, publish. The whole build is Studio configuration — nothing to deploy.
A model that can only write text can't look up a balance or book an appointment. To do either, it needs a structured way to call a real system — the same problem the Model Context Protocol names. Building that connection normally means writing and hosting a tool server: code, a release, a redeploy every time a tool changes.
In Kav, the same result — a real API, wired into something an AI can call correctly and safely — is three configuration steps in Studio, not a line of code.
1. Point at your API
A connector instance names an address, which vendor contract it speaks, and a credential reference — never the credential's actual value, only a vault key pointing at it. Every new instance is created Draft and Mock by construction: it cannot reach a real system until a separate, explicit, audited act switches it to Active and a live mode. Nothing you configure while building this out can accidentally touch your production API.
2. Tell the AI what it gets back
A contract is a table, not a paragraph: which fields a caller must supply, which fields come back, and — the part worth pausing on — a plain-language description for each one. That description isn't a note for the next person reading the form. It's read by the model itself, the same text it uses to decide how to fill in and interpret every field.
3. Tell the AI when to reach for it
This is the part that actually does what a tool's description does in MCP — except it's four or five sentences, not code: a summary, a use_when written the way a person would actually ask, a do_not_use_when that keeps a similar-sounding tool from getting picked by mistake, and a disambiguation note for the genuinely unclear case.
Publish
That's the whole build. There's no separate deploy step, because there's nothing to deploy — a tenant's available tools are compiled fresh from these exact rows on every single turn. Publish the row and it's live immediately, scoped to your organization by the database itself, with the model never seeing anything it wasn't just given permission to see.
Why this is the harder version, on purpose
A hand-written tool server is a fixed list, the same for every caller, one release away from its next change. This is the opposite: every organization's tool set is its own configuration, changed by editing a row, checked for assurance and entitlement on every single call before it ever reaches your system. It does the job MCP describes — it just never asks you to write or host a server to do it.