Build Your First AI Agent Tool in 10 Lines of Python

Someone I follow spent three hours on a live stream breaking this concept down. After the stream, I scrolled the comments: “Still confused.” “When do we use BaseTool vs @tool?” “My agent keeps calling the wrong function.” Three hours. Still confused.

Here’s what I’ve learned teaching hundreds of developers over the past two years: the confusion almost never comes from the code. It comes from the mental model. Get the mental model right, and the code writes itself in ten lines. Everything else is just error handling and polish.

Let me give you that mental model first. Then we’ll build something that would actually impress a hiring manager.

What a Tool Actually Is (And Why This Matters)

Ask most developers what an AI agent tool is, and they’ll say “a function the AI can call.” Technically correct. Completely useless as a mental model.

Here’s the better version: a tool is a function with a resume.

Your Python function has code. The tool has code, a name, a description, and a type signature. The LLM never reads your code. It reads the resume. The name, the docstring, the parameter types. That’s everything it gets. Based on that, it decides whether to call the function, when to call it, and with what arguments.

This changes everything about how you write tools. You stop thinking “how do I expose this function?” and start thinking “how do I describe this function so an LLM knows exactly when to use it?”

Your First Tool: Stock Price Lookup

Let’s stop the useless conceptual discussion or the multiply-two-numbers demo. Let’s build something real. We’ll use yfinance, Yahoo Finance’s unofficial Python library. It’s free, it has no API key requirements, and it pulls live market data.

Before we start: everything in this post goes into a single Python file. We’ll build it piece by piece so I can explain each part, but at the end you’ll have one complete script you can copy, save as agent.py, and run. I’ve included the full combined version at the bottom if you want to skip ahead.

Install what you need:

Create a new file called agent.py and start adding the imports and your first tool:

That’s it. Ten lines including the docstring.

Notice that the docstring isn’t just documentation for you. It’s the tool’s entire communication to the LLM. When an agent has ten tools available and someone asks “what’s Apple trading at?”, the LLM reads all ten docstrings and picks this one. Write a vague docstring and the agent picks the wrong tool, or picks nothing. Write a clear one and it works like magic.

Adding a Second Tool (This Is Where It Gets Interesting)

One tool alone isn’t much of an agent. Add a second tool right below the first one in the same agent.py file:

See what I did in that docstring? “NOT for stock prices. Use get_stock_price for current price data.” You’re giving the LLM explicit routing instructions. When tools have overlapping territory, you need that disambiguation right inside the description. Most tutorials skip this entirely, then wonder why the agent behaves unpredictably in production.

The Moment Everything Clicks

Now, still in the same agent.py file, add the code that wires these tools to an LLM and creates the agent loop:

That last one is the one I want you to sit with. The question doesn’t explicitly ask for a price or a description. The LLM reads the question, determines it needs both the financial data and the business context, calls both tools in sequence, and then writes a coherent answer combining both results.

You didn’t write any routing logic. No if/else for which tool to call. You described the tools clearly, and the model figured out the rest.

That’s the mental model shift. You’re not programming the decisions. You’re creating the options and describing them well enough that the LLM can make decisions itself.

What Most AI Agent Tool Tutorials Get Wrong

I’ve read a lot of these. A few patterns bother me.

The first is toy examples. Calculating factorial, converting Celsius to Fahrenheit. Those are fine for testing whether the decorator works. They’re useless for understanding why any of this is valuable, because the LLM already knows the answer without calling a tool. You never see the decision-making in action. You just see a function get called.

The second is skipping error handling entirely. Your tool will receive bad input. The ticker symbol will be misspelled. The API will time out. The data will be missing. If your tool throws an uncaught exception, the agent crashes. Returning a clean error string, as in the try/except blocks above, lets the agent recover gracefully. It might even retry with a corrected ticker, ask the user to clarify, or move on to a different approach. That flexibility matters enormously in production.

The third, and most frustrating, is skipping the docstring conversation. Tutorials show the decorator working but don’t explain that the docstring is the contract between you and the model. Every word affects tool selection behavior. “Get the current stock price” is a worse description than “Get the current stock price. Use when a user asks for a stock quote, current value, or how much a share costs.” The second version handles more edge cases in how real users phrase real questions.

The Pydantic Upgrade (When You Need It)

For simple tools with one or two string parameters, the @tool decorator is everything you need. When you’re dealing with complex inputs, date ranges, multiple optional filters, or nested data, Pydantic validation adds structure that helps both you and the model:

Note: This Pydantic version is an optional upgrade. You don’t need it for the basic agent we’re building. If you want to add it, drop it into the same agent.py file alongside the other tools and include it in the tools list. For your first run, the two tools above are plenty.

The Pydantic schema does two things. It gives the LLM richer parameter guidance, because the field descriptions end up in the schema the model sees. And it validates inputs before your function body ever runs. If the model sends an invalid period string, Pydantic catches it before you hit the API. That’s one less failure mode you have to debug at 11 PM.

Now Scale It Up: The Enterprise Version

Here’s where my background kicks in. Thirty years in enterprise IT across Fortune 100 companies. Data platforms that handle millions of records. Systems entire divisions depend on daily.

The tools above connect to Yahoo Finance. Interesting, and free. But the same pattern, almost unchanged, connects to your company’s Oracle data warehouse:

Same decorator. Same pattern. Now your agent can answer “How’s the APAC pipeline looking for Q1 2025?” by querying your actual data warehouse. Extend this to Snowflake, BigQuery, your internal REST APIs, your Salesforce CRM, your ServiceNow tickets, and suddenly you’re not building demos anymore.

That’s the thing about this pattern. It doesn’t care what’s on the other side of the function. Stock data, SQL queries, REST calls, file system reads. The interface between the LLM and the outside world is always the same: a clear description, a clean input schema, a useful return value.

A Note on Production Reality

What’s above is enough to get something working today. Before you put it in front of actual users, add these three things.

Timeouts. External API calls fail. Wrap them with a timeout so your agent doesn’t hang indefinitely waiting for a response that isn’t coming.

Logging. Log every tool call: what was requested, what was returned, how long it took. This is how you debug agent behavior in production. LangSmith, LangChain’s observability platform, handles this automatically if you’re already in that ecosystem.

Rate limiting. If the LLM decides to call your data warehouse tool 50 times in a complex workflow, your infrastructure team will find you. A simple counter or token bucket at the tool level prevents the worst scenarios.

The BaseTool class, rather than the @tool decorator, gives you more control over initialization and async behavior. That matters when your tools connect to connection pools or shared resources. For what we’ve built here, the decorator is exactly right.

The Full Working Example

Here’s everything end to end, ready to run:

To run it:

Open your terminal, navigate to the folder where you saved agent.py, and run:

python agent.py

You should see three responses printed to your terminal, one for each question. The first will show Microsoft’s current stock price. The second will explain what Nvidia does. The third is the interesting one. The agent will call both tools on its own, pull Apple’s price and business summary, and give you a combined answer about whether the stock seems expensive for what the company does.

If you get an authentication error, double-check that you replaced “your-key-here” with your actual OpenAI API key. If you don’t have one, sign up at platform.openai.com (https://platform.openai.com/), add a few dollars of credit, and generate a key under API Keys.

If you want to play with it interactively instead of running the three pre-written questions, replace the three print(ask(…)) lines at the bottom with this:

Now you can type any question and watch the agent decide which tools to use in real time.

One More Thing

The title of this post promises 10 lines. And it’s true. The core of a working tool is under 10 lines. But that was never really the point.

The point is that once you understand the pattern, you stop seeing “AI agent tools” as a magical or complicated concept. You see them for what they are: functions with good descriptions, connected to a model that can read those descriptions and make routing decisions.

The real skill isn’t writing the decorator. It’s knowing what to describe, how to describe it, and what your tool should return so the LLM can do something useful with the result. Write that well, and you can replace “stock price lookup” with any function your organization needs an AI to interact with.

The pattern scales. From a weekend side project to production systems handling real enterprise queries with real business consequences.

That’s the part no three-hour livestream can shortcut. But now at least you have the mental model.