What are the best practices for tool definition in LangChain to avoid agent hallucination?

All answers to this question.

The most effective way to solve this is by using the @tool decorator combined with Pydantic v2 models. You need to provide a very descriptive docstring because that is essentially the "manual" the LLM reads to understand when and how to use the function. If your SQL tool requires a specific company_id, define it as a required field in a Pydantic class. Also, using models like GPT-4o or Claude 3.5 Sonnet helps, as they have native "tool-calling" capabilities that are much more reliable than the older zero-shot ReAct patterns which relied on parsing raw text.

   Answered 2025-09-12 by Cynthia Reed

Have you tried using "Few-Shot" prompting in your system message to show the agent exactly what a successful tool call and observation looks like?

   Answered 2025-09-14 by Brian Hall

• Brian, few-shotting is helpful, but if the schema is complex, it often fails. I recommend the "OutputParser" approach where you force the model to return JSON that matches your schema. If the JSON is invalid, you can pass the error back to the LLM to "fix" its own mistake. This "self-correction" loop is a standard pattern in advanced agentic workflows to ensure the SQL query actually executes.

     Commented 2025-09-15 by Kenneth Moore

I always use the validate_tools=True flag in my chains. It throws an immediate error if the model tries to call something outside the defined scope, which is better than a silent failure.

   Answered 2025-09-16 by Lisa Bennett

• Excellent point, Lisa. Fail-fast mechanisms are critical when your agent has permission to interact with production databases; you don't want a hallucinated "DROP TABLE" command running!

     Commented 2025-09-17 by Brandon Taylor