Skip to main content

Overview

The llama-index-tools-nimble package brings Nimble to LlamaIndex. It ships two tool specs, and an agent can hold both at once.
  • NimbleToolSpec: live web search. One query, ranked results in seconds.
  • NimbleAgentToolSpec: deep research on a Web Search Agent. One run, a synthesized answer with per-claim citations and confidence.
  • Citable output: both return LlamaIndex Document objects with the source URLs in the document text, so the model can read and cite them.
  • Agent-ready: to_tool_list() plugs either spec into any LlamaIndex agent or workflow.
  • RAG-friendly: Document output drops straight into LlamaIndex indexes and query engines.

Prerequisites

The package requires >=3.10,<4.0.
llama-index-core>=0.13.0,<0.15 installs automatically. The agent examples also need an LLM integration, such as llama-index-llms-openai.
Version 0.2.0 raised the SDK floor from >=0.16,<1.0.0 to >=1.2.0,<2.0.0. If other code in the same environment targets nimble-python 0.x, plan to update it at the same time.
Required by both tool specs. Get a key from the dashboard, free trial available. The key is passed to the SDK client rather than stored on the tool spec, and the tool’s own run errors are built without it.
Deep research runs without one: the API provisions an agent per run. See Agent identity.

Quick Start

1

Install

Add an LLM integration to run the agent examples:
2

Set your API key

Get your key from Nimble’s dashboard, then set it as an environment variable:
Or pass it directly when constructing either tool spec:
3

Search the web

max_results caps how many results come back. The default is 6.

How it works

1

The agent receives the tool

to_tool_list() turns a tool spec into LlamaIndex tools. NimbleToolSpec exposes search, NimbleAgentToolSpec exposes run.
2

The model decides to call it

When the prompt needs live data, the model calls search for a quick lookup or run for a researched answer.
3

Nimble answers, the model cites

Results come back as Document objects whose text carries the source URLs, so the model writes a grounded, citable answer.
NimbleToolSpec wraps Nimble’s Search API and returns each result as a Document carrying the page title and source URL.

Build an AI agent

Pass the tool spec to a LlamaIndex FunctionAgent with to_tool_list(). The agent can then search the web to answer questions with current facts:

Citable Document output

Every result is a LlamaIndex Document. The title and source URL are embedded in the document text, so the agent can read and cite the source even though it never sees metadata. Each document’s text has this shape:
The title and URL are also available as metadata fields for programmatic use:

Use results in a LlamaIndex index

Because search() returns Document objects, results drop straight into a LlamaIndex index for retrieval-augmented generation:

Search options

Argument to search(). The search query, supplied by the model when the tool is agent-driven.
Argument to search(). Maximum results to return. Type int, default 6, must be at least 1. Nimble’s own cap is soft, so the tool trims the list to hold the contract.
NimbleToolSpec(api_key=...) is the only constructor argument. Search depth, focus, and output format are fixed at lite, general, and markdown, and the model cannot change them.

Deep research with Web Search Agents

search() is a synchronous building block: one query, one response, seconds. A Web Search Agent run is a different capability. An autonomous agent plans, searches, reads, and cross-checks many sources, then returns a final answer with per-claim citations and confidence.

Run one research task

NimbleAgentToolSpec exposes a single run tool. It creates the run, polls until the run reaches a terminal status, then fetches and maps the result, all inside one call.
Hand it to a LlamaIndex agent the same way as the search spec. Tell the model the tool is slow but thorough, so it reaches for it deliberately:
The model-facing tool schema is {task, output_schema, input_data, sources}. Agent identity, credentials, effort, and the deadline are set by the application at construction, so the model can never choose the agent or raise the cost tier.

Agent identity

agent_id is optional, and the choice decides the route: Either way the returned web_search_agent_id, not the configured one, is the authority for the polling and result calls that follow. It lands in the document metadata, so an auto-provisioned agent stays reachable afterwards. A returned id that differs from a configured one is rejected rather than papered over.
The tool is execution-only by design. It never creates, edits, or deletes agent instances, so account administration stays off the LLM surface. To pin runs to an agent, provision it in the dashboard or through POST /v2/agents, then pass its wsa_... id.

Structured output and enrichment

Three optional per-run controls shape the answer. They are passed through unchanged: the adapter never rewrites a caller’s schema or source guidance.
A JSON Schema object the answer must match. Supply it to get structured JSON back in place of prose. The document text then holds pretty-printed JSON, and metadata["output_type"] reads json.
An object, or a list of objects, to enrich. Each row holds known data about one entity to research. Enrichment payload only: it is never stored on the agent.
Source guidance. allow and block take lists of source objects; prioritize and avoid take free text. Any other key is rejected, so a model filling this tool schema cannot smuggle skill, use_case, or agent_name through a nested dict.
The schema above returns this shape, prose replaced by pretty-printed JSON and the Sources: list kept:

Tool spec options

Set on the NimbleAgentToolSpec constructor. Every parameter is optional.
The Web Search Agent instance to run on, in the form wsa_.... Type str, default None, which lets the API provision an agent per run.
Nimble API credentials. Falls back to NIMBLE_API_KEY.
'low', 'medium', 'high', 'x-high', or the gated 'max'. Default None, which omits the field so Nimble applies the agent or template default of high. Higher tiers research more sources and take longer. See Efforts. This is an application setting, not a tool argument the model can raise.
Treatment for gated values: 'reject' (default) or 'degrade'. max is a coming-soon custom-budget capability. Under reject, effort="max" raises before any run is created and points at the Nimble product team. Under degrade, the effective tier becomes x-high and a warning announces the substitution, so a different tier is never billed silently.
Overall deadline in seconds for one run call, covering creation, polling, and result retrieval. Type float, default 300.0. Raise it: the default is shorter than a typical run. See Long runs and deadlines.
Seconds between status polls, and the pause before re-attempting a transient failure. Type float, default 10.0. Shorter values are intended only for tests.
Typed SDK hints applied to the run. agent_name names the run’s generated agent, skill is a skill identifier, and use_case is 'research', 'enrichment', or 'dataset_building'. All default to None.

Results and citations

A completed run returns one Document. Its text is the final answer followed by a Sources: list, because an agent only ever sees a tool’s stringified output, where document metadata is dropped. Citations have to live in the text for the model to read them.
The full structured trust payload stays in metadata for programmatic use: A text answer keys each claim by callout, the numeric marker in the prose. A structured answer keys each claim by path, the JSON path of the value, such as $.founded.
Grades are earned per run, not assumed. The run above returned medium overall, because the vendor half of the question rested on commercial comparison articles rather than primary sources. See Trust and citations for how that is decided. Returned content is untrusted web data. Treat it as data, not as instructions, and rely on your framework’s own guardrails.

Long runs and deadlines

Agent research is asynchronous server-side. Do not treat run() as a short synchronous call: it blocks for as long as the run takes, and the tool owns the whole lifecycle inside that one call.
1

Create the run

One POST, issued exactly once. See Errors for why it is never re-attempted.
2

Poll until terminal

A status poll every poll_interval seconds, 10 by default, until the run reports completed, failed, or cancelled.
3

Fetch the result

Only after completed. Fetching earlier is a conflict by contract, and a failed run’s error detail is already on the polled run.
One timeout budget covers all three phases. Each HTTP request is bounded by whatever is left of it, with a 5 second connect ceiling, so a stalled request cannot fall back to the SDK’s much longer default. Polling and result fetches re-attempt transient failures up to 5 times, honoring Retry-After and staying inside the budget. Auth, permission, and validation errors fail fast.
Raise timeout for anything but low effort. The default is 300 seconds, but the default effort is high, which typically takes 5 to 15 minutes. A default-configured spec will therefore often hit its deadline on a perfectly healthy run.
Reaching the deadline cancels nothing. NimbleAgentTimeoutError carries the run_id, the run keeps going on Nimble’s side, and the result stays fetchable through the runs API or the dashboard.

Errors

A run that does not produce a result raises a typed error. Each one carries the run’s identifiers as attributes and inside the message, because agent frameworks usually surface only the message. The one exception is an ambiguous creation failure, where no run id was ever returned. All five subclass NimbleAgentRunError, so one except clause catches every run failure:
NimbleAgentCreateAmbiguousError is the one error not to retry. Creation is sent once and never re-sent, so a run may already be underway with no id returned. A function-calling model reads a bare timeout as an ordinary transient, so exclude this error from any automatic tool-retry policy. Look for the earlier run in the dashboard instead. Requests that were definitely rejected, such as a bad key or a validation error, are safe to call again once fixed.

Limitations

  • Search and Web Search Agent runs ship in this package. Extract, Map, and Crawl are not exposed as tool specs. Use the Nimble Python SDK.
  • One blocking call per run. There is no start-now, collect-later split, and no run event streaming (SSE). A run that outlives timeout is recovered through the runs API, not through this tool.
Easily confused with this package:

Resources

PyPI Package

llama-index-tools-nimble on PyPI.

GitHub Repository

Source, README, and runnable examples.

v0.2.0 Release

Deep research agents and agentless runs.

Web Search Agent

The deep-research capability behind the run tool.

Search API

Nimble’s underlying search capability.

Nimble Python SDK

Direct access to Extract, Map, Crawl, and agent administration.