Notifications
Clear all

How do I define custom tools for my AI agent?

3 Posts
4 Users
0 Reactions
54 Views
0
Topic starter

Im trying to get my agent to query a private SQL database for a project I need to wrap up by Friday and honestly Im hitting a wall. I saw some docs mentioning LangChain function calling but then I read on a discord that people are just using simple API wrappers instead? It feels like there are too many ways to do this. My logic was to just write a python script for the tool and pass it through, but im worried about the agent hallucinating the parameters. Is there a clean way to define these so the model doesnt get confused? Im working in London and trying to keep costs low so local execution is preferred...


3 Answers
12

Honestly, I had such a rough time with those heavy frameworks too. They just add so much bloat and overhead when all I wanted was a simple SQL query. Unfortunately, most of the standard tool-calling patterns are not as good as expected for local models, often leading to wasted tokens and weird errors. If youre trying to save money and keep it local, I found that skipping the fancy abstractions is actually way more stable. Here is what I ended up doing to finally get it working:

  • Write your own custom class inheriting from a base tool interface but keep it super lean.
  • Add a manual validation layer before the SQL query runs to catch bad inputs before hitting your db.
  • Use a lightweight local runner like Ollama Llama 3 8B Parameters to keep your inference costs at zero while testing. Basically, dont let the agent handle the raw SQL generation. Create a few hardcoded helper functions for standard queries and just let the agent pick the right one. It solves the hallucination problem because the agent is choosing between predefined options rather than guessing syntax. My setup runs on a Dell XPS 15 9530 Intel Core i9-13900H 32GB RAM, and it is snappy enough for my dev workflows. Just keep it simple and dont overengineer the tool definition, you'll be fine for your friday deadline. Reach out if you need a code snippet for that validation logic.


11

Ugh, I feel your pain. I spent all weekend trying to get those function calling patterns working and honestly it was a disaster. Everything kept breaking, and the latency was just killing my local setup. I eventually gave up on the heavy frameworks and just started using plain old JSON schemas for tool definitions. The model actually listens better if you keep the descriptions super simple and strictly formatted.

  • Write a small Python class that just handles the raw SQL execution.
  • Use a library like SQLAlchemy 2.0.35 ORM to abstract the queries so they dont explode if the syntax is slightly off.
  • Keep the tool definitions in a separate config file so you dont have to recompile your whole agent script every time you tweak a field. It was way cheaper than burning tokens on those fancy agent platforms. Honestly, just keeping it slim and local on my Apple MacBook Pro M3 Chip 18GB RAM saved me a ton of cash.


1

TL;DR: Use Pydantic models for your tool schemas. Trust me, I spent days debugging silent failures before realized the model just needs strict guidelines. Honestly, writing custom wrapper functions with typed parameters saved my life. My current setup forces explicit schema definitions and it cut the hallucination rate way down. It works locally too, which keeps it cheap. Just keep the tool descriptions super granular and you should be golden by Friday.


Share: