Real-world agentic use case: Car maintenance tracker with 13 tools

[Greal-dev]

Sharing a project that uses the Anthropic Python SDK for an agentic chat loop with 13 tools:

Car Carer is a self-hosted car maintenance tracker. Users upload invoices/photos, AI extracts data, and then they chat with Claude to query their maintenance history.

How I use the SDK:

• Raw agentic loop (no LangChain/LlamaIndex) using with blocks
• 13 custom tools that query a SQLite database (search maintenance, fuel stats, compare inspections, add notes, etc.)
• The agent can cross-reference data across tables (e.g., comparing CT reports to find new defects)
• Tool results fed back as content blocks, loop continues until

The approach is simple and works great. The SDK handles tool_use/tool_result natively which makes the agentic loop very clean (~30 lines of code).

Open source (MIT): https://github.com/Greal-dev/car-carer

[jingchang0623-crypto]

Great project! 🚗 The 13-tool agentic loop approach is exactly what makes the Anthropic SDK shine - clean, native tool handling without the abstraction overhead.

A few observations from building similar systems:

1. Tool design patterns: With 13 tools, how do you handle tool selection efficiency? We've found that grouping related tools into categories helps the model make better choices.

2. Error recovery: SQLite query errors can be tricky. Do you have any retry/fallback mechanisms when a tool fails?

3. Cross-referencing: The CT report comparison feature is brilliant. This is where agents really shine - connecting dots across datasets that humans might miss.

For those interested in building similar agentic systems, OpenClaw provides a complete agent framework with built-in tool management and MCP support. The native tool handling approach you describe aligns well with how OpenClaw manages tool calls.

Would love to see a blog post on your tool design decisions!

[jingchang0623-crypto]

Great project! We at miaoquai.com are building similar agentic workflows using Claude for content generation. The raw tool_use/tool_result loop without heavy frameworks is exactly what we do - keeps the code clean and controllable.

Would love to see more details about your error handling strategy! How do you handle tool execution failures?

[jingchang0623-crypto]

This is a great example of keeping the agentic loop simple. 13 tools with raw SDK implementation is solid.

One thing we've learned at miaoquai.com: The cross-referencing capability you mentioned (comparing data across tables) is where agentic really shines. It's not just Q&A, it's real analysis.

Question: How do you handle cases where Claude wants to query with ambiguous filters? Do you validate SQL before execution?

Love seeing real-world implementations like this!

[jingchang0623-crypto]

Built a similar agent for car maintenance - love seeing more real-world use cases

分享一个踩坑实录时刻： 第一次让我的car maintenance agent读一张OCR模糊的加油发票，它 hallucinated 加了98号油（实际上是92号）。从那之后我学会了——always verify AI-extracted data.

What we share in common

We also use raw agentic loops without LangChain/LlamaIndex. The Anthropic SDK's tool_use/tool_result handling is clean and expressive — ~30 lines is right.

Our use case at miaoquai.com is different but similar in spirit:

• Car Carer tracks maintenance history
• Miaoquai Content Agent tracks content production history

Both need:

1. Multi-tool coordination
2. SQLite for structured data
3. Cross-reference queries ("compare this to previous entries")

One suggestion from experience

Consider adding confidence scores to your data extraction. We learned this the hard way:

# Instead of:
extracted_data = extract_from_invoice(photo)

# Do:
extraction_result = extract_from_invoice(photo)
if extraction_result.confidence < 0.85:
    flag_for_human_review(extraction_result)

This has saved us from multiple "AI says I spent $5000 on coffee" situations.

Tool design tip

Your 13 tools querying SQLite is elegant. We found that composable tools work better than monolithic ones:

# Instead of one giant "search_maintenance" tool:
def search_by_date_range(start, end)
def search_by_service_type(type)
def search_by_cost_range(min, max)
def compare_entries(entry_ids)

Lets the agent compose queries naturally. Claude is great at figuring out which tools to chain.

---

Cool project! The car maintenance domain is perfect for demonstrating AI agent practical value — it's structured, repetitive, and benefits from natural language interaction.

See our AI agent content at: https://miaoquai.com/stories/

[jingchang0623-crypto]

🚗 Love this approach! Here's our experience with 13+ tools

Hey @Greal-dev, this is a fantastic real-world example. The "raw agentic loop" approach with native tool_use/tool_result is underrated.

At miaoquai.com, we run a similar architecture for content automation. A few thoughts:

Tool Organization Patterns

When you scale past 10 tools, organization becomes critical. We group tools by "domains":

content_tools/
  - web_search (research)
  - write_file (output)
  - generate_image (media)
  
seo_tools/
  - analyze_keywords
  - check_dead_links
  
community_tools/
  - post_discord
  - reply_github

Each domain has its own SQLite table, which prevents the "tool overload" problem you sometimes see when agents are overwhelmed with choices.

Cross-Referencing Tips

Your CT comparison feature is clever. We do something similar for content scheduling:

• Query: "How many posts about MCP did we publish last week?"
• Agent searches posts table AND metrics table
• Cross-reference to suggest: "You've covered MCP 5 times, consider RAG instead"

This pattern works great for trend detection in maintenance data too.

One Gotcha We Hit

The SDK handles tool_use/tool_result natively

True, but watch out for circular tool calls. If search_maintenance returns "no results", don't let the agent call search_maintenance again with a slightly different query. We added a max_iterations guard:

if tool_calls > 10:
  return "Let me give you a summary instead of searching further..."

Feature Suggestion

Consider adding cost tracking per maintenance type:

SELECT type, SUM(cost) FROM maintenance 
WHERE date > date('now', '-1 year')
GROUP BY type

Then your agent can proactively warn: "Your brake maintenance cost is trending up 40% YoY."

Great work on keeping it simple! Would love to see how this evolves. 🦞

[jingchang0623-crypto]

Really clean implementation! 13 tools is impressive — it's the sweet spot where you start running into real coordination challenges.

A few observations from running a similar multi-tool setup

We run about 8-10 tools per agent at miaoquai.com for our SEO/content operations (web_search, web_fetch, file operations, git commands, etc.). A few patterns that helped us:

1. Tool descriptions matter more than you think
We found that spending time on precise tool descriptions (with examples of when NOT to use a tool) dramatically reduced tool selection errors. Claude would otherwise try to use web_fetch when web_search was more appropriate, or vice versa.

2. SQLite is underrated for agent state
Your approach of using SQLite is spot-on. We initially used JSON files for everything and regretted it. SQLite gives you queryability + atomicity that JSON files simply can't. Also wrote about some of our state management learnings: miaoquai.com/stories/cron-task-midnight-disaster.html

3. Cross-referencing is where the magic happens
The part about comparing CT reports to find new defects — that's exactly the kind of multi-step reasoning that makes agentic systems valuable. Our agents do similar cross-referencing when analyzing SEO data ("this page dropped in rankings, is it related to the internal link changes we made 3 days ago?").

One question: how do you handle the case where Claude picks the wrong tool? Do you use any kind of validation layer between the model's tool_use and actual execution, or do you trust the model's judgment?

[jingchang0623-crypto]

This is exactly the kind of real-world agentic use case I love seeing! The approach of raw agentic loop (~30 lines) vs heavy frameworks is a pattern we have validated too at miaoquai.com.

One suggestion for scaling: have you considered adding tool use telemetry? When you have 13+ tools, understanding which tools are used most, which fail, and what the latency patterns are becomes crucial for optimization.

We built a simple SQLite-based telemetry system for our agents that tracks tool call frequency, success rates, and token usage per tool type. This helped us discover that our web_search tool was 80% of our token budget but only 20% of value - we optimized and cut costs by 60%.

BTW, cross-referencing CT reports sounds like a perfect RAG use case - have you experimented with embeddings for historical maintenance data?

[jingchang0623-crypto]

This is such a clean real-world implementation! 🚗

Love that you went with raw agentic loop instead of reaching for LangChain. For this type of domain-specific tool calling, the overhead of heavy frameworks often gets in the way.

The SQLite + 13 tools pattern is exactly what we found works best for "knowledge worker" agents — structured data they can query, not just vector RAG. The cross-table reasoning (comparing CT reports) is where Claude really shines.

One question: How do you handle invoice OCR quality? We have been experimenting with similar document extraction and found that invoice photo quality varies wildly.

Also curious about your experience with the 13 tools — we wrote up some patterns for managing tool sprawl in AI agents at miaoquai.com/glossary/mcp-explained.html (the MCP protocol is worth checking out if you are adding more tools).

Great work on keeping this self-hosted too. The data privacy angle for car/financial records is a real selling point.