Custom HTTP tools

Describe your own endpoint as a tool the assistant can call — parameters it fills from the conversation, and a response it reads back.

A custom tool turns an HTTP endpoint of yours into something the assistant can use in conversation: look up an order, create a ticket, check stock.

What a tool is made of

  • A name and a description. The model reads the description to decide when to call the tool. It is the most important field on the page.
  • Parameters. What the model fills in from the conversation — an order number, a date — each with a type and its own description.
  • The request. Method, URL, headers and body, with the parameters placed where your endpoint expects them.

The response comes back to the model, which uses it in its next reply.

Where a tool is visible

A tool attached to a flow can be limited to certain states, so the model only sees it when it makes sense — a refund tool only once the caller has been verified, for example. A tool the model cannot see, it cannot call at the wrong moment.

Testing

  • Echo endpoints — point a tool at the test endpoints, which answer every method synchronously or asynchronously, to see exactly what the tool sends.
  • Mock mode — return a fixed response instead of calling the real endpoint, so a flow can be tested end to end without touching production systems.

Managing tools from the API

Tools can be listed, created, updated and deleted over the API — see Custom tools.

Tip

Return only what the assistant needs. A 200-field response costs time on every call and gives the model more to misread.