Skip to main content
Tool availability gating filters unavailable tools at schema-build time, preventing the LLM from hallucinating calls to tools that can’t run.
The user requests work that needs a gated tool; unavailable tools are hidden from the schema so the model cannot call them.

Quick Start

1

Decorator with Availability Check

2

Class-Based Tool with Availability


How It Works


Implementation Methods

Function Decorator

BaseTool Protocol

Registry Functions


Availability Rules

Behavior Patterns

  1. No Check Method: Tool is always considered available
  2. Check Returns True: Tool included in LLM schema; last-success timestamp stamped
  3. Check Returns False: Tool hidden from LLM; cached False for 30 s
  4. Check Throws Exception: Flaky — served last-good within the grace window, otherwise hidden (see below)
The full behaviour, before and after the last-good grace window landed:

Exception Handling

A raised probe is treated as flaky, not final:
  • If the tool succeeded within the last 30 seconds, the last-good result is served and a DEBUG line is logged. The failure is not cached, so the next probe can recover immediately.
  • Otherwise (no prior success, or the last success is older than 30 s), the tool is hidden, cached as unavailable for 30 s, and a WARNING is logged.
This makes long-lived agents and gateways stable across brief daemon hiccups, import glitches, and network blips.

Plain Function Registry


Availability Caching

Availability checks are cached per-tool for 30 seconds so probes aren’t re-run on every schema build. The TTL and grace window are internal defaults (both 30 s) on ToolRegistry and are not user-tunable. When cache entries are cleared:
  • registry.unregister(name) — evicts the tool’s cache and last-success timestamp.
  • registry.register(new_tool, name=..., overwrite=True) — when the replacement is a different instance, prior availability state is evicted so a broken replacement can’t inherit the previous tool’s “healthy” status.
  • registry.clear() — wipes everything.
Expensive probes (network calls, subprocess spawns) don’t need @lru_cache — the registry already caches results for 30 s. Add @lru_cache only if you need longer caching.

Configuration Patterns

Environment-Based Availability

Service Discovery

Conditional Tool Loading


Best Practices

Availability checks run at schema-build time and must be fast (< 100ms recommended).Good: Environment variable checks, import tests, quick pings Bad: Full API calls, heavy file operations, long network requests
The registry already caches every probe result for 30 s — see Availability Caching. Don’t wrap probes in @lru_cache unless you need caching longer than 30 s.
Check critical dependencies first, avoid unnecessary work.
Design tools to degrade gracefully when dependencies are partially available.

Tools Overview

Core tool system and registration

Agent Configuration

Agent setup and tool integration