Questions
2 of 24
1What is a Tool in LangChain and how does it differ from a plain function or API call?
2What is the difference between the tool() helper, DynamicTool, and StructuredTool class?
3How does an LLM decide which tool to call — what role does the tool description play?
4What is the role of Zod schema in tool definitions and how does it map to OpenAI's function calling spec?
5What is a ToolNode in LangGraph and how does it differ from calling a tool manually inside a graph node?
6How do you wrap a REST API call with auth headers inside a Tool in TypeScript?
7How do you handle async errors and retries inside a Tool without crashing the agent loop?
8How do you pass runtime context (userId, authToken, DB connection) into a Tool using RunnableConfig?
9How do you build a Toolkit (grouped set of related tools) using BaseToolkit?
10How do you validate and sanitize tool output before it is passed back to the LLM?
11How do you stream tool call results back to the client in real time?
12How do you implement tool-level authorization — allowing certain tools only for certain users?
13How do you build stateful tools that read/write to a database across multiple agent turns?
14How do you prevent tool abuse or infinite loops where an agent keeps calling the same tool repeatedly?
15How do you implement parallel tool calling — when the LLM decides to call multiple tools simultaneously?
16How do you create a human-in-the-loop tool that pauses the agent and waits for user approval before executing?
17How do you unit test and mock tools in isolation without invoking the LLM?
18How do you implement tool call caching to avoid redundant API calls for identical inputs?
19How do you design a multi-agent system where one agent's tool is actually another agent (agent-as-tool pattern)?
20How does LangGraph's ToolNode handle tool call errors and surface them back into the message state?
21What is the difference between tool_choice: "auto", "required", and "none" when binding tools to an LLM?
22How do you implement dynamic tool loading — where the set of available tools changes based on user role or session state?
23How do you trace and observe tool call latency in production using LangSmith?
24What are the token cost implications of registering too many tools and how do you mitigate it?
langchainlangchain
Basics
Agents
Models
Messages
Tools
Middleware
Memory
MCP
Multi Agents
RAG
Context Engineering
Human in the loop
02 / 24

What is the difference between the tool() helper, DynamicTool, and StructuredTool class?

The tool() helper is a modern factory function that creates either a DynamicTool or DynamicStructuredTool behind the scenes, automatically handling runtime features like LangGraph state injection and cancellation. DynamicStructuredTool is a concrete class for structured argument tools with schema validation, while DynamicTool is a simpler class for tools that accept a single string input.

In LangChain, you have multiple ways to create tools, each offering different levels of abstraction and control. The tool() helper is the recommended high-level factory function that simplifies tool creation. DynamicStructuredTool is a concrete class for tools with structured, multi-parameter inputs validated by a schema, and DynamicTool is a simpler class for tools that accept a single string input.

The tool() helper is a higher‑level factory that builds either a DynamicTool or DynamicStructuredTool for you. It's the recommended approach for most use cases because it automatically wires in newer runtime features such as state injection from LangGraph, context propagation, cancellation (AbortSignal), and streaming (runtime.writer).

Using the tool() helper
Pros of `tool()` helper
  1. 1

    Less boilerplate; consistent pattern across projects

  2. 2

    Automatically gains new LangChain/LangGraph runtime features without code changes

  3. 3

    Easier onboarding for new developers following official docs

DynamicStructuredTool is a concrete class that extends StructuredTool. It is designed for tools that accept structured data (multiple named arguments) validated against a Zod or JSON schema. You instantiate it directly with a configuration object containing name, description, schema, and func.

Using DynamicStructuredTool directly
Pros of using `DynamicStructuredTool` directly
  1. 1

    More explicit and low-level control

  2. 2

    Useful when you need a custom subclass or to override parts of StructuredTool

  3. 3

    Appropriate for building lower‑level libraries where fine‑grained control is needed

DynamicTool is a simpler class for tools that accept a single string input. It uses a default StringInputToolSchema and is useful for wrapping legacy APIs or functions that operate on a single query string.

Using DynamicTool directly
Comparison Table
  1. 1

    tool(): Modern factory; creates DynamicTool/DynamicStructuredTool; recommended for most code; automatically handles runtime features (LangGraph state, cancellation, context)

  2. 2

    DynamicStructuredTool: Low-level class; for structured, multi-parameter input; requires manual instantiation; use when you need custom subclassing

  3. 3

    DynamicTool: Low-level class; for simple single-string input; less common; use for legacy APIs or simple wrappers

For the LLM, both approaches look identical—they expose the same name, description, and argument schema. The differences are in developer ergonomics and runtime integration rather than what the model sees. The official recommendation for maintainable, future‑proof code is to standardize on the tool() helper for all new tools and gradually migrate existing DynamicStructuredTool usages to this pattern.