<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Gen-LLM on Shaaf's blog</title><link>https://shaaf.dev/tags/gen-llm/</link><description>Recent content in Gen-LLM on Shaaf's blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 08 Jan 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://shaaf.dev/tags/gen-llm/index.xml" rel="self" type="application/rss+xml"/><item><title>Two Essential Patterns for Building MCP Servers</title><link>https://shaaf.dev/post/2026-01-08-two-essential-patterns-for-buildingm-mcp-servers/</link><pubDate>Thu, 08 Jan 2026 00:00:00 +0000</pubDate><guid>https://shaaf.dev/post/2026-01-08-two-essential-patterns-for-buildingm-mcp-servers/</guid><description>&lt;p>When building Model Context Protocol (MCP) servers, I learned two critical design patterns the hard way. What started as a straightforward implementation of a Keycloak administration server quickly became unwieldy—until I discovered &lt;strong>Intent Multiplexing&lt;/strong> and the &lt;strong>Command Pattern&lt;/strong>. Together, these patterns transformed a maintenance nightmare into an elegant, extensible architecture.&lt;/p>
&lt;p>This post shares those lessons so you can avoid the same pitfalls.&lt;/p>
&lt;p>Replicate each operation from your API and viola! you have a tool explosion. And that might not seem evident in the first place, but becomes a serious problem. An LLM might not be able to handle that large context, it might even start to halluncinate.&lt;/p></description></item></channel></rss>