provider_fields express more granular metadata.
The trading module is currently read-only. It does not place orders or execute trades - this functionality will be added in the next update.
What tools are available?
The following tools are listed for each provider. Please note that as many or as few as you need can be added at runtime. In addition, the output for each tool is structured according to defined trading schema - this is explained further in API reference.| Capability | Alpaca | Coinbase |
|---|---|---|
| Get account | get_account | get_account |
| List accounts | — | list_accounts |
| List portfolios | — | list_portfolios |
| Portfolio breakdown | — | get_portfolio_breakdown |
| List positions | list_positions | list_positions |
| Get position | get_position | — |
| Trading clock | get_clock | get_clock |
| List assets | list_assets | list_assets |
| Get asset | get_asset | get_asset |
| List orders | list_orders | list_orders |
| Get order | get_order | get_order |
| Portfolio history | get_portfolio_history | — |
What are some of the supported features?
The Trading module supports features that will be supported by all modules that are planned to be built. This includes aminimal flag, that allows for token optimisation with only schema output accepted. A strict option and demo option allows for tool outputs to be rejected or accepted depending on status code. Another feature involves the include or exclude parameter, which allows you to change what tools you want the model to see quickly. Lastly, concatenating tools from multiple providers is done simply via the + operator or the raw combine() function.
Minimal
Providers often include extra metadata that is useful for debugging but can be noisy context for LLMs and may be unnecessary for your project. Setminimal=True to omit provider metadata from returned objects. Concretely, this drops provider and provider_fields recursively from tool outputs.
Strict
OpenTools distinguishes between tool failures that should halt execution and tool failures that should be returned as structured error payloads. Usestrict() for production behavior (fatal tool errors raise), and demo() for prototyping (never raise based on fatal kinds).
Paper/Live
We support switching between sandbox and production environments via a singlepaper flag, which is currently possibe thorugh both providers.
This allows the same codepath to be used for demos, testing, and live deployments.
Include/Exclude
You can control which tools are exposed to the model at runtime usinginclude and exclude, either when constructing a service or when bundling tools.
This means you don’t have to use all the tools or you can choose not to include certain ones at runtime.
Combining providers
Multiple trading providers can be combined into a single tool surface using the+ operator. This allows you to use a unified service that exposes tools from all combined providers while preserving a single model and framework context.
This can be done as simply as tools = alpaca_tools + coinbase_tools
Framework compatibility
Trading services can optionally be bound to a specific agent framework using, for example,framework="langgraph".
When set, tools are exposed in a framework-native format without changing provider or domain logic.