Tools are how your agents interact with the outside world. Without tools, agents can only talk. With tools, they can look things up, create records, send emails, charge credit cards, or anything you expose to them.
Tools live inside Tool Sets, which are workspace-scoped collections that connect to a provider or your code. Point a tool set at an MCP server or OpenAPI spec and Cadenya loads the tools it finds. Define tools yourself for an HTTP API or Bare runtime. Assign tool sets to your agent variations, and those tools become available during objectives. Compare each option in Choose a tool set adapter.
Cadenya also gives an agent tools of its own, based on the variation’s config: get_memory and search_memory when it carries memory layers, tool_search when progressive discovery is on, and get_sub_agent_results when it has sub-agents assigned.
Adapters
Every tool set connects to a tool provider through an adapter. There are four types.
MCP
The MCP adapter connects to a Model Context Protocol server. Cadenya discovers tools from the server and keeps them in sync. Add a tool on your server and it shows up after the next sync; remove one and Cadenya marks it archived rather than dropping it, so a running objective never loses a tool out from under it.
Cadenya supports custom headers on MCP connections, so you can pass authentication tokens or any other headers your server expects. Walk it step by step in Connect an MCP server.
HTTP
The HTTP adapter connects to a standard REST API. Each tool maps to an endpoint with a method, path, headers, and an optional request body template. When an agent calls the tool, Cadenya renders the template with the agent’s arguments and fires the request.
HTTP tools send platform headers (x-cadenya-tool-call-id, x-cadenya-objective-id, x-cadenya-agent-id, x-cadenya-agent-variation-id) so your API can correlate requests back to the agent that made them. Define one by hand in Wrap an HTTP API.
OpenAPI
The OpenAPI adapter reads an OpenAPI specification, by URL or upload, and turns each operation into a tool. Cadenya syncs the operations and, for a spec it fetches by URL, re-checks it every hour. Custom headers go out both when fetching the spec and when calling a tool. Point Cadenya at a spec in Connect an OpenAPI spec.
Bare
The Bare adapter has no provider to sync from and fires nothing itself. You define each tool by hand, the same as HTTP, but when an agent calls one, Cadenya pauses the call and hands it to you: your own worker finds the waiting call, does the work, and returns the result. It is a reverse harness, so Cadenya never needs a route into your network. Build one in Run tools in your code.
Filtering
MCP servers might expose dozens of tools, but your agent rarely needs all of them. Tool sets support include and exclude filters so you control what gets synced.
Filters match on tool name, title, or description using exact match, prefix, suffix, contains, or regex. You can combine multiple conditions with AND/OR logic. A tool that fails the filter still syncs, marked Omitted rather than dropped, so it stays visible while the agent only ever gets the Available ones.
Fewer tools means less noise in the context window and better tool selection
by the model. Filter without mercy.
Approval
Some tools shouldn’t fire without a human in the loop. When a tool has requiresApproval enabled, the agent pauses and waits for someone to approve or deny the call before continuing. Approval requests have a 24-hour timeout.
You can set approval requirements per-tool, or use approval filters on the adapter to require approval for tools matching certain patterns. This is handy when you want blanket approval on everything from an MCP server except, say, read-only tools.
When an approval is requested, Cadenya sends a webhook so you can notify the right person. See the webhooks guide for the full flow.
Progressive discovery
By default, all tools assigned to a variation are loaded into the context window at the start of an objective. This works great when you have a handful of tools, but if your agent has access to 50+, that’s a lot of tokens spent on tool definitions the agent might never use.
Progressive discovery flips this: tools aren’t loaded upfront. Instead, the agent works from a catalog of tool names and searches for the ones it needs. Only matched tools get added to the context window, with their full definitions.
You configure progressive discovery on the agent variation, not on the tool set itself. It includes options for max tools per search and keyword hints that steer what the agent reaches for. The Preventing tool bloat guide puts it to work on a thousand-endpoint tool set.
Tool sets are assigned to agent variations, not to agents. This means different variations of the same agent can have access to different tools, which is useful for A/B testing whether more or fewer tools improves performance.
Check out the Agents guide for more on how variations work
and why this distinction matters. 
