Tool types
Duvi supports three kinds of tool. All three attach to a single agent and are described to the model the same way. What differs is who decides which tools exist.
| Kind | At the other end | You define |
|---|---|---|
| Action | One endpoint of yours, one method | Every header, query parameter and body field |
| MCP server | A server that publishes its own set of tools | The address and any headers it needs |
| Connector | A service Duvi already knows, such as Shopify or Stripe | Which of its tools the agent may use |
Actions are the ones you shape field by field, so they have their own reference. Connectors need little more than a button, and the catalogue is in Connectors.
Whatever the kind, the agent reads a description and decides when to call. It never decides what the call looks like.
Value sources
Every header, query parameter and body field says where its value comes from. That setting is the safety model.
| Value source | Filled by | Trustworthy |
|---|---|---|
| Fixed value | You, once, when you define the tool | Yes |
| Stored key | Duvi, at call time | Yes |
| From the signed-in customer | Duvi, from verified identity. The agent never sees it. | Yes |
| From your website | The page the widget is on | No. The visitor can read and change it. |
| Ask the customer | The agent, from what was said in conversation | No. It is whatever they claimed. |
For every field, with its exact shape and the eleven types a value the agent collects can take, see Value sources.
Stored keys
A stored key is a named secret belonging to one agent. Create it once, from Credentials or from the tool that needs it, then reference it by name in any tool header. Duvi never shows the value again, to you or to the model.
| Operation | Available |
|---|---|
| Create a key | Yes |
| List key names and dates | Yes |
| Read a value back | No, by design |
| Update or delete a key | Not currently supported |
Call your API as the customer
When your API should return one person’s data rather than everybody’s, it needs to be called as that person. An integration turns a signed-in visitor into a token your API will accept, and a tool points at it.
| Sign-in | What the call carries |
|---|---|
| No sign-in | Nothing that identifies a person. Right for public lookups such as stock or opening hours. |
| Sign in as the customer | A token minted for this customer, so your endpoint can only return their data. |
Signing in as the customer needs a Token URL, a Client ID and a client secret you have already stored as a key. Scope and Audience are optional and set by your provider. Which detail identifies the customer names the claim to read from the token your identity endpoint returns, which is sub unless you say otherwise.
On calls there is no browser session to read, so Fall back to a verified phone number on calls lets the number the carrier reports stand in as the customer. Treat that as a separate decision from browser identity, because it proves a different thing.
The exchange follows RFC 8693 and carries an actor token alongside the customer, naming the agent and the conversation it is acting in. Your authorization server can therefore audit which agent acted, in which conversation, on whose behalf.
If Duvi cannot mint a token, it does not make the call. The agent is told it could not authenticate rather than calling your endpoint as nobody. Identity itself is set up in Customer identity.