<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>MCP on</title><link>/tags/mcp/</link><description>Recent content in MCP on</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 10 Jul 2025 00:00:00 +0000</lastBuildDate><atom:link href="/tags/mcp/index.xml" rel="self" type="application/rss+xml"/><item><title>Lesson 6: Agent Architectures — Building autonomous agents in Go</title><link>/post/go/go-ai-agent-architectures/</link><pubDate>Thu, 10 Jul 2025 00:00:00 +0000</pubDate><guid>/post/go/go-ai-agent-architectures/</guid><description>&lt;p&gt;An agent is a loop: observe, think, act, repeat. The LLM is the &amp;ldquo;think&amp;rdquo; step — it decides what to do next given the current state. Your Go code handles &amp;ldquo;observe&amp;rdquo; (gathering context), &amp;ldquo;act&amp;rdquo; (executing tool calls), and the loop control that keeps everything running. I&amp;rsquo;ve built agents that write and execute code, agents that browse the web, and agents that orchestrate multi-step data pipelines. The underlying architecture is always the same few patterns, and Go&amp;rsquo;s concurrency makes the execution layer clean and fast.&lt;/p&gt;</description></item><item><title>Lesson 5: Embedding and Vector Search — Semantic search in Go without Python</title><link>/post/go/go-ai-embeddings/</link><pubDate>Sun, 18 May 2025 00:00:00 +0000</pubDate><guid>/post/go/go-ai-embeddings/</guid><description>&lt;p&gt;For a long time, embedding-based semantic search felt like Python territory. The tutorials all pointed to LangChain, FAISS, and numpy. But the actual operations — generate an embedding vector, store it in a database, query for nearest neighbors — map directly onto Go&amp;rsquo;s strengths: clean HTTP client code for the embedding API, &lt;code&gt;pgx&lt;/code&gt; for PostgreSQL with pgvector, and fast concurrent query pipelines. I&amp;rsquo;ve built production semantic search systems entirely in Go and they&amp;rsquo;re fast, maintainable, and don&amp;rsquo;t require a Python sidecar.&lt;/p&gt;</description></item><item><title>Lesson 4: Tool Calling Patterns — Letting the LLM invoke your Go functions</title><link>/post/go/go-ai-tool-calling/</link><pubDate>Wed, 12 Mar 2025 00:00:00 +0000</pubDate><guid>/post/go/go-ai-tool-calling/</guid><description>&lt;p&gt;Tool calling is where LLM integrations get genuinely powerful. Without tool calling, you&amp;rsquo;re limited to asking the model to generate text. With tool calling, you can build a conversational interface where the model decides which of your functions to call, calls them, incorporates the results into its reasoning, and decides whether to call more tools or return a final answer. I&amp;rsquo;ve used this to build support assistants that query databases, coding assistants that run test suites, and research tools that fetch live web content — all driven by the model&amp;rsquo;s judgment about which tools to invoke.&lt;/p&gt;</description></item><item><title>Lesson 3: Streaming Responses — Token-by-token output without buffering the whole response</title><link>/post/go/go-ai-streaming/</link><pubDate>Wed, 18 Dec 2024 00:00:00 +0000</pubDate><guid>/post/go/go-ai-streaming/</guid><description>&lt;p&gt;If you&amp;rsquo;ve ever used a non-streaming LLM endpoint in a user-facing feature, you know the experience it creates: the user submits a question, watches a spinner for 8 seconds, then suddenly gets a wall of text. Streaming changes this completely — the user sees output appearing word by word, which feels responsive and alive even when the total time-to-complete is identical. In Go, streaming LLM responses means reading Server-Sent Events (SSE) from the API and piping them to the client in real time. It&amp;rsquo;s genuinely one of the nicer concurrency patterns I&amp;rsquo;ve implemented.&lt;/p&gt;</description></item><item><title>Lesson 2: LLM API Clients — Calling Claude, GPT, and Groq from Go</title><link>/post/go/go-ai-llm-clients/</link><pubDate>Sun, 06 Oct 2024 00:00:00 +0000</pubDate><guid>/post/go/go-ai-llm-clients/</guid><description>&lt;p&gt;Most Go developers approach LLM APIs the same way they approach any REST API — write an HTTP client, handle errors, parse JSON. That instinct is correct, but LLM APIs have a few characteristics that require specific handling: they&amp;rsquo;re slow (seconds, not milliseconds), they have complex nested response structures, they support streaming, and the model selection and token management have real cost implications. This lesson is about building Go clients that handle all of this properly.&lt;/p&gt;</description></item><item><title>Lesson 1: Building MCP Servers in Go — Give AI agents tools with the Model Context Protocol</title><link>/post/go/go-ai-mcp-servers/</link><pubDate>Tue, 30 Jul 2024 00:00:00 +0000</pubDate><guid>/post/go/go-ai-mcp-servers/</guid><description>&lt;p&gt;When Claude or another AI assistant needs to look up a database record, call an internal API, or read a file from your filesystem, it can&amp;rsquo;t do that on its own — it needs tools. The Model Context Protocol (MCP) is Anthropic&amp;rsquo;s open standard for giving AI agents exactly those tools. An MCP server is a small program you write that exposes tools via a JSON-RPC protocol; the AI client calls your server to invoke them. I find this genuinely exciting as a Go developer: Go&amp;rsquo;s concurrency model and fast startup time make it a natural fit for MCP servers.&lt;/p&gt;</description></item></channel></rss>