new blog UI+articles

Author: edujuan

blog/2025-01-15-introducing-utcp.md

@@ -0,0 +1,108 @@
+---
+slug: introducing-utcp
+title: Introducing UTCP - The Direct Alternative to MCP
+tags: [announcement, utcp, mcp, tool-calling, ai-agents]
+---
+
+# Introducing UTCP: The Direct Alternative to MCP
+
+We're excited to introduce the **Universal Tool Calling Protocol (UTCP)** — a modern, flexible, and scalable standard for defining and interacting with tools across a wide variety of communication protocols.
+
+<!--truncate-->
+
+## Why UTCP?
+
+While the Model Context Protocol (MCP) has made strides in standardizing AI-tool interactions, it comes with inherent limitations that UTCP addresses head-on:
+
+### 🚀 **Zero Latency Overhead**
+Unlike MCP's proxy-based architecture, UTCP enables direct tool calls without intermediary layers. Your AI agents communicate directly with tools, eliminating unnecessary latency.
+
+### 🔒 **Enhanced Security**
+UTCP's design principles prioritize security from the ground up. With direct protocol support and built-in authentication mechanisms, you get enterprise-grade security without compromising performance.
+
+### 🌐 **Protocol Flexibility**
+While MCP is limited to specific transport mechanisms, UTCP works seamlessly across:
+- HTTP/HTTPS
+- GraphQL
+- gRPC
+- WebSockets
+- CLI interfaces
+- Custom protocols
+
+## Key Features
+
+### Direct Tool Integration
+```typescript
+// Example: Direct HTTP tool call with UTCP
+const weatherTool = {
+  name: "get_weather",
+  description: "Get current weather for a location",
+  provider: {
+    type: "http",
+    endpoint: "https://api.weather.com/v1/current",
+    method: "GET"
+  },
+  parameters: {
+    location: { type: "string", description: "City name" }
+  }
+}
+```
+
+### Universal Protocol Support
+UTCP isn't bound to a single communication method. Whether your tool speaks HTTP, GraphQL, or even CLI commands, UTCP can handle it:
+
+```yaml
+# GraphQL Tool Definition
+name: user_search
+provider:
+  type: graphql
+  endpoint: https://api.example.com/graphql
+  query: |
+    query GetUser($id: ID!) {
+      user(id: $id) { name email }
+    }
+```
+
+### Built-in Authentication
+Security is paramount. UTCP supports multiple authentication methods out of the box:
+
+```json
+{
+  "auth": {
+    "type": "bearer",
+    "token": "${API_KEY}"
+  }
+}
+```
+
+## Getting Started
+
+Ready to try UTCP? Here's how you can get started:
+
+1. **Explore the Documentation**: Check out our comprehensive [documentation](/docs) to understand UTCP's capabilities
+2. **Browse the Registry**: Visit our [tool registry](/registry) to see available UTCP-compatible tools
+3. **Join the Community**: Connect with other developers on our [Discord](https://discord.gg/ZpMbQ8jRbD)
+
+## The Road Ahead
+
+UTCP is more than just a protocol — it's a vision for the future of AI-tool interactions. We're building:
+
+- **Expanded Protocol Support**: More communication protocols and standards
+- **Enhanced Tooling**: Better development tools and SDKs
+- **Community Growth**: A thriving ecosystem of tools and integrations
+
+## Community and Contributions
+
+UTCP is open source and community-driven. We welcome contributions, feedback, and collaboration from developers worldwide. Whether you're building tools, implementing clients, or improving the specification, there's a place for you in the UTCP community.
+
+### Get Involved
+- 📖 **Documentation**: Help improve our docs and guides
+- 🔧 **Tool Development**: Create new UTCP-compatible tools
+- 🐛 **Issue Reporting**: Report bugs and suggest improvements
+- 💬 **Community Support**: Help other developers on Discord
+
+---
+
+*UTCP represents the next evolution in AI-tool communication. Join us in building a more direct, efficient, and secure future for AI agent interactions.*
+
+**Ready to dive in?** [Start with our documentation](/docs) or [explore the tool registry](/registry) today!

blog/2025-01-16-mcp-servers-nightmare.md

@@ -0,0 +1,93 @@
+---
+slug: mcp-servers-nightmare
+title: MCP servers are a nightmare for engineers
+tags: [mcp, servers, scalability, authentication, engineering, tool-calling]
+---
+
+# MCP servers are a nightmare for engineers
+
+> *"If you have more than five tools, an MCP rollout feels like spawning a new micro-service for **every** function call. We ended up with 40 tiny servers, 40 sets of secrets, and one giant Ops headache."*  
+> — *Engineering team at a Series B startup*  
+
+MCP (Model Context Protocol) was supposed to "standardise tool calling for LLMs." Instead it created a forest of mini-services that crumble under real-world scale and expose brand-new security holes. Here's why production teams are quietly ripping MCP back out of their stacks.
+
+<!--truncate-->
+
+---
+
+## 1. One API ⇒ One MCP server ⇒ One scaling nightmare
+
+**Design flaw:** Every tool definition lives behind its own long-running MCP server. A project with 20 tools is now a 20-service deployment. Horizontal scaling becomes a Knuthian combinatorial explosion:
+
+```yaml
+# naïve K8s layout
+weather-mcp   ×  N replicas
+db-mcp        ×  N replicas
+payment-mcp   ×  N replicas
+# ... and so on
+```
+
+*   **Orchestration overhead:** service discovery, health checks, autoscaling rules, and CI/CD pipelines multiply linearly.  
+*   **Resource thrash:** idle MCP servers still hold sockets and memory; at peak they compete for the same CPU shares.  
+*   **Cold-start pain:** spawning a new server per customer or per tenant means hundreds of containers during load spikes — exactly the kind of burst K8s is slowest to absorb.  
+
+Even MCP contributors admit that "one server per API sounds crazy if you're doing backend" after wrestling with dozens of them in production.
+
+---
+
+## 2. “Bring-your-own-auth” is a security trap
+
+The spec punts on authentication, so every vendor rolled their own:
+
+* **OAuth, mutual-TLS, Static tokens,** or — far too often — **nothing at all.** Engineers joke that "the S in MCP stands for Security" precisely because it doesn't.  
+* **Key-store of doom:** each server needs credentials for the upstream tool *and* for the calling agent. When one leaks, the blast radius includes *every* downstream service accessible through that server. Hackers love a single vault full of all your API keys.  
+* **Proven attack vectors:** MCP servers often run with elevated privileges and expose additional attack surface through their custom authentication mechanisms.  
+
+The security model fundamentally breaks down when you have dozens of independent servers, each implementing their own auth patterns.
+
+---
+
+## 3. Debugging distributed auth failures, not latency numbers
+
+Latency is fixable with caches; **broken auth flows** cascade:
+
+1. Token refresh fails in one MCP server.  
+2. All agents routed to that pod get 401s.  
+3. Autoscaler spawns more replicas of the *broken* image.  
+4. Your incident channel fills with “tool unavailable” alerts while dashboards stay green (the servers are *up*, just unauthorised).
+
+Tracing the root cause means correlating logs across **agent → client SDK → MCP server → tool → identity provider**. That’s five codebases, often in five languages.
+
+---
+
+## 4. MCP locks you *out* of real scaling patterns
+
+MCP’s JSON-RPC-over-stdio/HTTP tunnel ignores native features of the protocols it proxies:
+
+* **WebSockets & streaming gRPC**: forced back into polling loops; throughput nose-dives when messages surge.  
+* **Binary blobs**: base64 inflation wrecks memory-bandwidth-sensitive workloads (vision, audio).  
+* **Fan-out fan-in patterns**: you still need a coordinator outside MCP, defeating its “single interface” pitch.  
+
+Teams building high-frequency trading bots reported a 20× drop in tick rate once they moved feeds through MCP.
+
+---
+
+## A labyrinth of servers
+
+If you've already tackled the operational complexity listed above and think MCP servers are a good investment of your engineering time, go ahead — just make sure to budget for the maintenance work that's inevitably needed. Another option is to adopt existing MCP server frameworks and accept the architectural trade-offs.
+
+To solve this problem at scale, we've been experimenting with a more boring approach: **UTCP (Universal Tool Calling Protocol)**. The idea is simple: let your agents speak the tool's native protocol directly, without a proxy layer.
+
+The architecture is much less interesting: tools are just API definitions, calls go direct to the service, and you reuse whatever auth infrastructure you already have. It scales like any stateless API because that's exactly what it is.
+
+---
+
+### Bottom line
+
+**MCP is great for what it was designed for:** sharing prompts, resources, and context between AI systems. When you need to give an LLM access to your company knowledge base or standardize prompt templates, MCP shines.
+
+**But tool calling? That's where MCP becomes a nightmare.**
+
+Forcing every API call through a JSON-RPC proxy server turns simple HTTP requests into distributed systems nightmares. You end up with **microservices-sprawl-as-a-spec** combined with DIY security theatre. If your architecture already struggles with too many services and secrets, MCP's tool calling approach adds gasoline to the fire.
+
+For tool calling, the fastest fix is the simplest: delete the proxy, call the API directly.

blog/authors.yml

@@ -0,0 +1,11 @@
+utcp-team:
+  name: UTCP Team
+  title: Core Contributors
+  url: https://github.com/universal-tool-calling-protocol
+  image_url: /img/black-logo-square.png
+  
+utcp-maintainer:
+  name: UTCP Maintainer
+  title: Protocol Maintainer
+  url: https://github.com/universal-tool-calling-protocol
+  image_url: /img/black-logo-square.png

docusaurus.config.ts

@@ -50,6 +50,16 @@ const config: Config = {
           showLastUpdateTime: true,
           includeCurrentVersion: true,
         },
+        blog: {
+          showReadingTime: true,
+          feedOptions: {
+            type: ['rss', 'atom'],
+            xslt: true,
+          },
+          editUrl: 'https://github.com/universal-tool-calling-protocol/utcp-specification/tree/main/',
+          blogSidebarCount: 'ALL',
+          blogSidebarTitle: 'All posts',
+        },
         theme: {
           customCss: './src/css/custom.css',
         },
@@ -113,13 +123,7 @@ const config: Config = {
           position: 'left',
           label: 'Docs',
         },
-        {
-          type: 'doc',
-          docId: 'about-us',
-          position: 'left',
-          label: 'About',
-          docsPluginId: 'about',
-        },
+
         {
           type: 'doc',
           docId: 'RFC',
@@ -130,16 +134,15 @@ const config: Config = {
         {
           to: '/registry',
           position: 'left',
-          label: 'Registry',
+          label: 'Tool Registry',
         },
         {
           type: 'docsVersionDropdown',
           position: 'right',
           docsPluginId: 'default',
         },
         {
-          href: 'https://github.com/universal-tool-calling-protocol',
-          label: 'GitHub',
+          type: 'custom-github',
           position: 'right',
         },
         {
@@ -209,8 +212,33 @@ const config: Config = {
           ],
         },
         {
-          title: 'Legal',
+          title: 'Resources',
           items: [
+            {
+              label: 'Blog',
+              to: '/blog',
+            },
+            {
+              label: 'Registry',
+              to: '/registry',
+            },
+          ],
+        },
+        {
+          title: 'About',
+          items: [
+            {
+              label: 'About Us',
+              to: '/about/about-us',
+            },
+            {
+              label: 'RFC',
+              to: '/about/RFC',
+            },
+            {
+              label: 'Contributing',
+              to: '/about/contributing',
+            },
             {
               label: 'Impressum',
               to: '/about/impressum',