Skip to main content
A tool describes a function your agent can call: its name, the parameters it takes, when it should be invoked, and what a successful result looks like. Roark uses that description to grade and mock tool calls in simulations: it checks the agent reached for the right tool at the right moment with sensible arguments, and it stands in a mock result so the conversation can carry on. Scope a tool to one agent with agent, or omit it for a project-wide tool.
A tool definition is grading and mock metadata, not an integration. In a simulation Roark scores whether your agent called the tool correctly and returns a mock result so the call can continue; it does not execute your backend. Defining a tool changes how Roark evaluates tool use, nothing about how your live agent runs.

Parameters

parameters is a flat map of parameter name to its type, one of string, number, or boolean. It describes the arguments the agent is expected to pass, so Roark can check the call carried the right ones:

Handler

handler records how the tool executes. Today it is reference metadata, like an agent’s prompt: Roark stores it but does not call it. It is read by the hosted runtime and connected-provider push once those consume it, so declaring a handler does not by itself run the tool. It is optional. One shape exists today, an http handler, a public endpoint the tool’s invocation would be dispatched to:
  • type is http (the discriminator that keeps future handler shapes additive).
  • url is a public http(s) endpoint.
  • method is optional, one of GET, POST, PUT, PATCH, or DELETE.
For the full field reference of every kind, see the Config DSL reference schema.