microsoft/semantic-kernel · error · AgentInitializationException

Unsupported tool type: {spec.type}

Error message

Unsupported tool type: {spec.type}

What it means

Raised by _build_tool when spec.type.lower() is not a registered tool type. Only builders registered via @_register_tool exist (currently 'code_interpreter' and 'file_search'); any other type produces a KeyError that is wrapped in this AgentInitializationException.

Source

Thrown at python/semantic_kernel/agents/open_ai/openai_assistant_agent.py:126


# Update _file_search
@_register_tool("file_search")
def _file_search(spec: ToolSpec, kernel: Kernel | None = None) -> tuple[list[AssistantToolParam], ToolResources]:
    vector_store_ids = spec.options.get("vector_store_ids")
    if not vector_store_ids or not isinstance(vector_store_ids, list) or not vector_store_ids[0]:
        raise AgentInitializationException(f"Missing or malformed 'vector_store_ids' in: {spec}")
    return OpenAIAssistantAgent.configure_file_search_tool(vector_store_ids=vector_store_ids)


def _build_tool(spec: ToolSpec, kernel: "Kernel") -> tuple[list[AssistantToolParam], ToolResources]:
    if not spec.type:
        raise AgentInitializationException("Tool spec must include a 'type' field.")

    try:
        builder = _TOOL_BUILDERS[spec.type.lower()]
    except KeyError as exc:
        raise AgentInitializationException(f"Unsupported tool type: {spec.type}") from exc

    sig = inspect.signature(builder)
    return builder(spec) if len(sig.parameters) == 1 else builder(spec, kernel)  # type: ignore[call-arg]


# endregion


@release_candidate
class AssistantAgentThread(AgentThread):
    """An OpenAI Assistant Agent Thread class."""

    def __init__(
        self,
        client: AsyncOpenAI,
        thread_id: str | None = None,
        messages: Iterable["ThreadCreateMessage"] | Omit = omit,
        metadata: dict[str, Any] | Omit = omit,

View on GitHub (pinned to c028a0c7dc)

Solutions

  1. Use only registered tool types: 'code_interpreter' or 'file_search'.
  2. For function/plugin tools, register them on the Kernel instead of as an assistant tool spec.
  3. Fix typos in the type string.
  4. If you need a custom tool type, register a builder with @_register_tool('your_type') before building.

Example fix

# before
tool = ToolSpec(type="retrieval", options={...})  # unsupported
# after
tool = ToolSpec(type="file_search", options={"vector_store_ids": ["vs_1"]})
Defensive patterns

Strategy: validation

Validate before calling

SUPPORTED_TOOL_TYPES = {"code_interpreter", "file_search"}
if spec.type and spec.type.lower() not in SUPPORTED_TOOL_TYPES:
    raise ValueError(
        f"Unsupported assistant tool type '{spec.type}'. "
        f"Supported: {sorted(SUPPORTED_TOOL_TYPES)}. Use the Kernel for function/plugin tools."
    )

Type guard

def is_supported_tool_type(t) -> bool:
    return isinstance(t, str) and t.lower() in {"code_interpreter", "file_search"}

Prevention

When it happens

Trigger: Setting ToolSpec.type to a value not in the registry, e.g. 'function', 'retrieval', 'web_search', or a typo like 'file_serch'. Case-insensitive (the lookup lowercases), so the issue is the value itself.

Common situations: Assisting function-calling tools are configured as assistant tools here (they are not; functions are registered on the kernel instead); using legacy OpenAI type names ('retrieval'); typos; expecting a tool type not yet supported by this declarative layer.

Related errors


AI-assisted analysis of microsoft/semantic-kernel@c028a0c7dc (2026-08-13). Data as JSON: /api/errors/9a840683da4078b0. Report an issue: GitHub.