> ## Documentation Index
> Fetch the complete documentation index at: https://opentools.page/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Tools

> What tools are in OpenTools, how they work, and why they exist

Tools are how LLMs safely interact with the real world **outside** their own training.

They allow an LLM to call **explicit, typed functions** (at least with OpenTools) that access external services like
Coinbase, Alpaca, or Gmail. Instead of guessing, hallucinating, or relying on stale
training data, a model can request fresh, authoritative information and act on it.

In OpenTools, tools are **first-class citizens**. These are structured capabilities ensuring easier setup and configuration into your application by providing structured output, concise error-handling and simpler auth handling under a unified methodology.

<Tip>
  When a user asks <em>“What’s the weather today?”</em>, the model doesn’t
  actually refer to its own knowledge. It's using external tools under the hood (just like the ones explained here).
</Tip>

***

## What is a tool?

Simply put, a **tool** is a function. Unfortunately, tools can look very different across
providers and frameworks, as there are few standards governing how they should be defined
or exposed to LLMs.

OpenTools defines tools around a small set of enforced principles:

* Structured input and output schemas, governed by a single domain (for example `trading.schemas`)
* Clear, unified error handling via a shared `OpenToolsError`
* A stable name and description designed explicitly for LLM consumption (`ToolSpec`)

In OpenTools, tools are **not** raw API calls and **not** prompt tricks.\
They are explicit, typed capabilities that a model may choose to invoke.

From the model’s perspective, a tool is inherently a brief JSON description, but for you it becomes a Pythonic function where capabilities can be added. OpenTools ensures that there is no prompt parsing, no manual JSON handling, and no provider logic leaking into your application code.

***

## Why tools exist?

LLMs are incredibly useful for useful applications such as answering queries quickly and accurately but **only** when they have the right context to use. This is when tools can be helpful.

They allow you to gain relevant and updated information even when the model's training date is months before the release of this data! In this case, OpenTools aims to amplify tool use cases by organising them not by provider alone but in **application**, such as integrating Alpaca and Coinbase into Trading, so that developers can rapidly deploy their projects in minutes.

Tools also ensure structured output and execution as they are governed outside the influence of the LLM's inherently probabilistic nature and using our pre-made tools, it will ensure that only relevant context reaches your preferred model without bloating the information you really want to build on top of.

***

## Why use our tools?

OpenTools is not a simple wrapper around an API endpoint. It comes with key improvements in the form of error-handling, auth configuration and structured output.

This essential difference allows for a developer to easily integrate our toosls:

1. It handles many different **Error** types which are specified under the <code>OpenToolsError</code> that will showcase what exactly happened in the flow to ensure minimal disruptions whether it be an authentication or model provider issue.
2. **Auth** is also made painfully simple so that you can just add your API keys and run!
3. **Output** is unified across domains so that you can expect the same output making it incredibly intuitive and easy to build on top of without having to handle extra edge-cases. We also support a minimal mode so that you can use only the output you need, reducing your token count along the way.

***

## A quick example

A concrete demonstration is detailed below, where the tool is registered and called allowing for the model to answer
a query more precisely.

<Steps>
  <Step title="Tool Registration">
    Before a user prompt is even sent, the model receives in its context a set of tools that are able to
    perform tasks that are given in the form of brief descriptions
  </Step>

  <Step title="Tool Decision">
    Once a prompt has been sent over, the model decides if a tool is worth using (this can be influenced through prompting by stating that a tool should be used)
  </Step>

  <Step title="Tool Calling">
    If the model actually decides to call the tool (function). It will await the result and then relay the results in plain English typically (OpenTools ensures only structured JSON is used).
  </Step>

  <Step title="Result">
    The model relays the results giving the user the needed context and understanding of the integrations they wanted
    to know about. The model successfully reasoned only through the help of the tool itself.
  </Step>
</Steps>

This loop can actually continue several times and not just once in this simple example. The model could, for example,
call a tool to determine positions available before executing a trade allowing for a more sophisticated agent which can
be done reliably using one of the frameworks OpenTools has integrated with.

***

## Next steps

<Columns cols={2}>
  <Card title="Trading" icon="up" href="/trading/overview">
    See how tools are implemented in a real module like Trading to connect to real providers.
  </Card>

  <Card title="Adapters" icon="plug" href="/adapters/models">
    Understand how tools are exposed to different model providers.
  </Card>
</Columns>
