I’m working with LangChain and need help with tool loading. I know there are two ways to use tools - either import the class directly or use the load_tools helper function.
Here’s what I’m trying to do:
from langchain_community.agent_toolkits.load_tools import load_tools
# This works but I need to know the string name
my_tools = load_tools(['wikipedia'])
result = my_tools[0].invoke("Python programming")
print(result)
The problem is figuring out what string names I can use with load_tools. For example, I see that WikipediaQueryRun class corresponds to the string 'wikipedia', but how do I find these mappings for other tools?
Is there a way to discover what text identifiers are available for the load_tools function? I prefer this approach over importing individual tool classes because it’s cleaner.
That documentation approach works, but here’s another practical method I’ve used. You can inspect the tool registry at runtime with get_all_tool_names() from the same module. Gets you a dynamic list without hardcoding dictionary names.
from langchain_community.agent_toolkits.load_tools import get_all_tool_names
available_tools = get_all_tool_names()
print(available_tools)
Found this while debugging a production agent that needed to validate tool availability before initialization. It automatically includes standard and optional tools, plus any custom ones you’ve registered.
One heads up - some tools need additional dependencies installed. The string identifier might exist but load_tools will throw an import error if the required package isn’t there. Always wrap your load_tools calls in try-catch blocks for less common tools.
You can find the string mappings in the _EXTRA_LLM_TOOLS and _EXTRA_OPTIONAL_TOOLS dictionaries in LangChain’s source code. But there’s an easier way.
Just check langchain_community/agent_toolkits/load_tools.py. All the available string identifiers are defined there as dictionary keys.
Some common ones I use:
'wikipedia' for WikipediaQueryRun
'requests_all' for requests tools
'python_repl' for Python execution
'shell' for terminal commands
'llm-math' for math calculations
I hit this same issue last year building an agent system. Created a small script that imports the load_tools module and prints all available tool names:
from langchain_community.agent_toolkits.load_tools import _EXTRA_LLM_TOOLS, _EXTRA_OPTIONAL_TOOLS
print("Available tools:")
for tool_name in _EXTRA_LLM_TOOLS.keys():
print(f"- {tool_name}")
for tool_name in _EXTRA_OPTIONAL_TOOLS.keys():
print(f"- {tool_name}")
Gives you the complete list without digging through docs.
Hit this same problem building a multi-agent system last month. The solutions mentioned work, but I found something cleaner - just inspect the load_tools function directly using Python’s inspect module. You’ll see what tools are actually available without relying on hardcoded dictionaries that change between versions. Key thing is catching import errors gracefully since lots of tools have optional dependencies. I built a validation function that tries loading each tool and caches what’s actually available in my environment. Saved me hours debugging across different deployments where packages were missing. Runtime inspection beats static dictionary lookups because it shows your real setup.
Been there with tool discovery in LangChain. Manual approaches work but get tedious fast when you’re juggling multiple projects with different tool needs.
Hit the same wall building an agent system that had to dynamically load tools based on user requests. Got tired of constantly checking dictionaries and running scripts, so I automated the whole thing.
Built a workflow that scans available tools, validates dependencies, and keeps an updated registry. Runs on every deploy and catches missing packages before they break production.
Real game-changer is pairing this with automatic tool registration. New tools get discovered and added without touching anything manually. Same workflow handles validation, testing, and even spits out documentation.
What used to be manual lookups became a fully automated system. No more guessing string identifiers or dealing with runtime import errors.
You can build something similar with automation workflows. Way cleaner than hardcoded dictionary checks or runtime inspection.