deepset-ai/haystack · error · NotImplementedError

SearchableToolset does not support adding new tools after in

Error message

SearchableToolset does not support adding new tools after initialization.

What it means

SearchableToolset.add() is intentionally disabled: the tool catalog is fixed at construction (plus warm_up-time flattening), so adding tools after initialization is not supported and raises NotImplementedError.

Source

Thrown at haystack/tools/searchable_toolset.py:146

        self._discovered_tools: dict[str, Tool] = {}
        self._bootstrap_tool: Tool | None = None
        self._document_store: InMemoryDocumentStore | None = None
        self._passthrough: bool | None = None

        # Optional per-run name filter, set on the copies returned by spawn(). When set, iteration only
        # yields tools whose name is in this set, and search is scoped to it. None means no filtering.
        self._selected_tool_names: set[str] | None = None

        # Initialize parent with empty tools list - we manage tools dynamically
        super().__init__(tools=[])

    def __add__(self, other: Tool | Toolset | list[Tool]) -> "Toolset":
        """Concatenation is not supported for SearchableToolset."""
        raise NotImplementedError("SearchableToolset does not support concatenation.")

    def add(self, tool: Tool | Toolset) -> None:
        """Adding new tools after initialization is not supported for SearchableToolset."""
        raise NotImplementedError("SearchableToolset does not support adding new tools after initialization.")

    def warm_up(self) -> None:
        """
        Prepare the toolset for use.

        Warms up the catalog (so lazy toolsets like MCPToolset can connect) and flattens it. Above the passthrough
        threshold, it also indexes the catalog and creates the search_tools bootstrap tool.

        This method is idempotent: it only warms up the toolset the first time it is called.

        :raises ValueError: If the flattened catalog contains tools with duplicate names.
        """
        if self._passthrough is not None:
            return

        # Warm up the catalog first (triggers lazy connections like MCPToolset), then flatten — lazy toolsets will
        # have their real tools available.
        warm_up_tools(self._raw_catalog)

View on GitHub (pinned to e318778c9b)

Solutions

  1. Pass all tools up front via SearchableToolset(catalog=[...]) including the tool you intended to add
  2. Rebuild the toolset with the expanded catalog instead of mutating it
  3. Use a plain Toolset if post-init mutation is required

Example fix

// before
ts = SearchableToolset(catalog=tools)
ts.add(new_tool)

// after
ts = SearchableToolset(catalog=[*tools, new_tool])
Defensive patterns

Strategy: fallback

Validate before calling

def register_tool(toolset, tool):
    from haystack.tools import SearchableToolset
    if isinstance(toolset, SearchableToolset):
        raise TypeError("Rebuild SearchableToolset with the tool in catalog instead of add()")
    toolset.add(tool)

Type guard

def is_mutable_toolset(toolset) -> bool:
    from haystack.tools import SearchableToolset
    return not isinstance(toolset, SearchableToolset)

Try / catch

try:
    toolset.add(new_tool)
except NotImplementedError:
    toolset = SearchableToolset(catalog=[*current_catalog, new_tool])

Prevention

When it happens

Trigger: searchable_toolset.add(new_tool) after construction, often in agent setup code that incrementally registers tools.

Common situations: Code that dynamically registers tools into a toolset post-init; migrating from regular Toolset (where add works) to SearchableToolset without updating setup logic.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


AI-assisted analysis of deepset-ai/haystack@e318778c9b (2026-08-30). Data as JSON: /api/errors/d03c3dfdf51a1ba1. Report an issue: GitHub.