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:
typeishttp(the discriminator that keeps future handler shapes additive).urlis a publichttp(s)endpoint.methodis optional, one ofGET,POST,PUT,PATCH, orDELETE.
For the full field reference of every kind, see the Config DSL reference schema.