Claude/update docs roadmap f zd2 j

examples/mcp/platform/README.md

@@ -63,10 +63,10 @@ service := micro.New("platform",
     mcp.WithMCP(":3001"),  // This one line makes everything AI-accessible
 )
 
-service.Handle(users)
-service.Handle(posts)
-service.Handle(&CommentService{})
-service.Handle(&MailService{})
+service.Handle(&Users{})
+service.Handle(&Posts{})
+service.Handle(&Comments{})
+service.Handle(&Mail{})
 ```
 
 Each handler method becomes an MCP tool. The `@example` tags in doc comments give agents sample inputs to learn from.

internal/website/blog/7.md

@@ -13,16 +13,20 @@ Here's the pitch: you have microservices. They already have well-defined endpoin
 
 With Go Micro + MCP, that gap is **zero lines of code**.
 
-## The Setup: A Real Blogging Platform
+## The Setup: A Blogging Platform
 
-We'll use a microblogging platform built on Go Micro with four services as a demo:
+We'll use a blogging platform as our example — inspired by [micro/blog](https://github.com/micro/blog), a real microblogging platform built on Go Micro with four domains:
 
 - **Users** — signup, login, profiles
 - **Posts** — blog posts with markdown, tags, link previews
 - **Comments** — threaded comments on posts
 - **Mail** — internal messaging
 
-These services exist today. They were built for human users interacting through a web UI. No one was thinking about AI agents when they were written.
+### A Note on Architecture
+
+Go Micro has always been a framework for building **multi-service, multi-process** systems. The [micro/blog](https://github.com/micro/blog) platform is a great example — each service runs as its own binary, communicates over RPC, and is independently deployable. If that's what you're after, check it out.
+
+For this walkthrough, we take a different approach: a **modular monolith**. All four domains live in a single process. This is a perfectly valid starting point — you get the clean separation of handler interfaces without the operational overhead of multiple services. And because Go Micro's handler registration works the same way in both models, you can break these out into separate services later as your team or requirements grow. No rewrite needed.
 
 ## One Line to Agent-Enable Everything
 
@@ -40,7 +44,7 @@ service.Handle(&Mail{})
 
 That `mcp.WithMCP(":3001")` starts an MCP gateway that:
 
-1. Discovers all registered handlers from the service registry
+1. Discovers all registered handlers on the service
 2. Converts Go method signatures into JSON tool schemas
 3. Extracts descriptions from doc comments
 4. Serves it all as MCP-compliant tool definitions
@@ -156,21 +160,17 @@ type CreatePostRequest struct {
 
 ## Adding MCP to Existing Services
 
-If you already have Go Micro services running (like micro/blog), you have three options:
+This demo runs everything in one process, but if you already have Go Micro services running as separate processes (like [micro/blog](https://github.com/micro/blog)), you have two additional options beyond the in-process approach shown above:
 
-### Option 1: One-line in your service
-```go
-service := micro.New("blog",
-    mcp.WithMCP(":3001"),  // Add this line
-)
-```
+### Option 1: Standalone gateway binary
+
+Point a gateway at your service registry and it discovers all running services automatically:
 
-### Option 2: Standalone gateway binary
 ```bash
 micro-mcp-gateway --registry consul:8500 --address :3001
 ```
 
-### Option 3: Sidecar in your deployment
+### Option 2: Sidecar in your deployment
 ```yaml
 # docker-compose.yml
 services:
@@ -184,7 +184,7 @@ services:
       - "3001:3001"
 ```
 
-All three discover services from the same registry. Zero changes to your service code.
+Both discover services from the registry and expose them as MCP tools. Zero changes to your service code.
 
 ## Production Considerations
 
@@ -220,4 +220,6 @@ The full example is at [`examples/mcp/platform/`](https://github.com/micro/go-mi
 
 We're working on a Kubernetes operator that automatically deploys MCP gateways alongside your services, request/response caching to reduce redundant calls from agents, and multi-tenant namespace isolation. See the [roadmap](/docs/roadmap-2026) for details.
 
-The core idea is simple: microservices already have the right structure for AI tools. We just needed to bridge the protocol gap. With MCP, that bridge is one line of code.
+The core idea is simple: well-structured services — whether running as a modular monolith or as independently deployed microservices — already have the right shape for AI tools. We just needed to bridge the protocol gap. With MCP, that bridge is one line of code.
+
+Whether you start with a single process like this demo or go straight to multi-service like [micro/blog](https://github.com/micro/blog), the MCP integration works the same way.