<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Llm-Tools on René Zander | AI Automation Consultant</title><link>https://renezander.com/tags/llm-tools/</link><description>Recent content in Llm-Tools on René Zander | AI Automation Consultant</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 13 Apr 2026 10:00:00 +0200</lastBuildDate><atom:link href="https://renezander.com/tags/llm-tools/index.xml" rel="self" type="application/rss+xml"/><item><title>MCP Servers Explained: What Model Context Protocol Does</title><link>https://renezander.com/blog/mcp-servers-explained/</link><pubDate>Mon, 13 Apr 2026 10:00:00 +0200</pubDate><guid>https://renezander.com/blog/mcp-servers-explained/</guid><description>&lt;p&gt;If you have heard &amp;ldquo;MCP&amp;rdquo; thrown around in the last year without getting a clear answer on what it is, here is the explainer that stays grounded in what it actually does, not what the marketing decks claim.&lt;/p&gt;
&lt;p&gt;I run an MCP server in production. It exposes my task manager to every LLM client I use, daily, as a systemd service on a Debian VPS. That constant use is where this explainer comes from. No conference slides, no speculation about where the protocol is heading in five years. Just what MCP is, what it replaces, and when you should bother writing one.&lt;/p&gt;</description></item><item><title>Build MCP Server TypeScript: Complete Tutorial with Claude</title><link>https://renezander.com/blog/build-mcp-server-typescript/</link><pubDate>Mon, 30 Mar 2026 11:00:00 +0100</pubDate><guid>https://renezander.com/blog/build-mcp-server-typescript/</guid><description>&lt;p&gt;Most teams do not need a custom MCP server. If you have one LLM app, one integration, and one codebase, calling the vendor API directly is faster to ship and easier to debug. The moment you have two Claude surfaces (Claude Desktop plus Claude Code, or Claude Code plus Cursor) hitting the same internal system, you stop duplicating tool code. That is when you build MCP server TypeScript projects worth maintaining.&lt;/p&gt;</description></item><item><title>Claude API Tool Use: Function Calling Guide for Production</title><link>https://renezander.com/guides/claude-api-tool-use/</link><pubDate>Thu, 26 Mar 2026 07:00:00 +0100</pubDate><guid>https://renezander.com/guides/claude-api-tool-use/</guid><description>&lt;p&gt;Tool use is the default pattern for any Claude workload beyond chat. If you are building anything that reads from a database, hits an API, writes a file, or decides between branches of logic, you should be using tools. If you are not, you are probably over-prompting and under-engineering.&lt;/p&gt;
&lt;p&gt;I run ten Claude-powered agents in production as bash scripts on a Debian VPS. Every one of them uses tool use, not prompt chaining, to decide what to do next. The model picks a tool, I execute it, I feed the result back, the model continues. That loop is boring, predictable, and debuggable. It beats &amp;ldquo;parse the JSON out of the model&amp;rsquo;s free-form answer&amp;rdquo; every time.&lt;/p&gt;</description></item></channel></rss>