<?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 Adam Vu</title><link>https://vutg.me/tags/mcp/</link><description>Recent content in Mcp on Adam Vu</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 23 Dec 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://vutg.me/tags/mcp/index.xml" rel="self" type="application/rss+xml"/><item><title>Building a Central MCP Gateway</title><link>https://vutg.me/posts/building-a-central-mcp-gateway/</link><pubDate>Tue, 23 Dec 2025 00:00:00 +0000</pubDate><guid>https://vutg.me/posts/building-a-central-mcp-gateway/</guid><description>&lt;p&gt;MCP (Model Context Protocol) is the open standard that lets AI assistants like Claude talk
to external tools: databases, file systems, APIs, internal services. But there&amp;rsquo;s a catch:
out of the box, MCP servers run locally on each developer&amp;rsquo;s machine as a child process.&lt;/p&gt;
&lt;p&gt;That&amp;rsquo;s fine for a single person. For a team, it&amp;rsquo;s a headache.&lt;/p&gt;
&lt;p&gt;Every developer installs and maintains their own copy of every MCP server. Tool updates get
rolled out one laptop at a time. Access to internal resources (like your production database
or a shared file store) means exposing them to every dev machine. There&amp;rsquo;s no audit trail, no
centralized config, no way to revoke someone&amp;rsquo;s access without touching their machine.&lt;/p&gt;</description></item></channel></rss>