osFoundry / Platform
Tool configs
Define new tools as inputs + handler. Anything you can call from Maestro.
What it is
Tool configs are how you teach osFoundry's agents to do things you can't get from a built-in feature. A tool config is a small definition with two parts: the inputs it accepts (the named parameters and their types) and a handler (what actually runs when the tool is called). Once defined, the tool joins the set of things Maestro, osFoundry's agent runtime, can invoke while it works — the same way it uses chat, search, or file operations. If you can describe an action as "here are the arguments, here is what to run," you can turn it into a tool your agents call by name.
Inside osFoundry this lives in Studio, alongside the rest of your agent and workflow configuration, so a tool you define is available to the agents, loops, and teams you build in the same workspace. Because osFoundry is bring-your-own-key and local-first, the handler runs from your workspace with your own credentials and keys — there's no reseller sitting between your agent and the service it calls, and no per-seat gate on how many tools you define or how often they run. The input schema is what the model reads to decide when and how to call the tool, so a clear set of named inputs is what makes the agent use it correctly; the handler is the part you control end to end.
Why it matters: most real agent work depends on actions specific to your stack — hitting an internal API, running a script, pulling from a system only you have access to. Rather than waiting for a feature to cover each one, tool configs let you add exactly the capability you need and have Maestro use it immediately. The tool becomes a reusable building block: define it once, and every agent or workflow in the workspace can call it.
Key capabilities
- Define a tool from two pieces: the inputs it takes and the handler that runs when it's called
- Named, typed inputs give the model a clear contract for when and how to invoke the tool
- Any tool you define becomes callable by Maestro, osFoundry's agent runtime, by name
- Handlers run from your own workspace with your own keys — BYOK, no reseller in the path
- Reuse a defined tool across the agents, loops, and teams you build in the same Studio
Use cases
- Developer: wraps an internal REST endpoint as a tool with typed inputs so an agent can query it during a task without hardcoding the call
- Ops engineer: defines a tool whose handler runs a maintenance script, then lets a scheduled agent invoke it as a routine step
- Team lead: adds one custom lookup tool in Studio and reuses it across every agent and workflow in the workspace instead of rebuilding it per agent
Frequently asked questions
What exactly is a tool config in osFoundry?
It's a definition with two parts: the inputs the tool accepts (its named, typed parameters) and a handler that runs when the tool is invoked. After you define it, the tool is available for Maestro to call while an agent works.
What can a tool's handler do?
The handler is the action that runs on invocation — the seed principle is that a tool can be anything you can call from Maestro. You define the inputs the agent passes in, and the handler carries out the work using your workspace and your own credentials.
How is this different from a hosted platform's plugins?
osFoundry is bring-your-own-key and local-first, so tools run from your workspace with your keys rather than through a reseller, and there are no per-seat fees limiting how many you define. You add the capability you need instead of waiting for a built-in feature to cover it.