Releases

• What's New in Go Micro: v6.6.0
• What's New in Go Micro: v6.3.15
• What's New in Go Micro: v5.15.0
• What's New in Go Micro: v5.13.0

What's New in Go Micro: v6.6.0

Go Micro v6.6.0 is a harness reliability release. The theme is the same services → agents → workflows lifecycle, but with more of the first-agent path covered by local checks and more recovery paths made deterministic when agents resume, retry, delegate, or notify.

The first-agent path is harder to break

The README, website docs, examples, and 0→hero guide chain now have more harness coverage. The CLI and docs keep the path from install troubleshooting through micro agent demo, quickcheck, examples, the smallest first-agent, debugging, and 0→hero in one consistent order.

That matters because the first agent is where framework promises become real: scaffold a service, run it, chat with an agent, inspect what happened, and then graduate to workflows.

Plan/delegate recovery is steadier

Plan/delegate got another reliability pass across side effects, notification replay, plan-only actions, timeout completion, and completed-plan recovery. These fixes are not flashy, but they are exactly the kind of harness work that keeps an agent from repeating work or losing state when a multi-step run is interrupted.

Provider fallback keeps improving

AtlasCloud fallback handling now recovers more awkward provider outputs, including workspace repair calls, empty-argument text tool calls, spoken notification replays, and A2A fallback artifact text. The goal is pragmatic interop: when a provider response is close enough to a safe tool call, the harness should repair it; when it is not, the failure should stay visible.

Security checks joined the loop

CI now includes a govulncheck gate and the autonomous loop can route vulnerability failures into triage. The release also includes toolchain and dependency updates for reachable CVEs, keeping the service framework side of the harness current while agent features continue to land.

Read the changelog

The full release notes are in the CHANGELOG.

What's New in Go Micro: v6.3.15

Go Micro v6.3.15 is a small but useful harness release: less friction for the first agent, better streaming provider coverage, and more reliable execution when models and delegates do not behave perfectly.

Anthropic now streams

The Anthropic provider now supports Messages SSE streaming and is registered as a streaming-capable provider. That means Go Micro agents can use Anthropic in the same streaming path as the other streaming-capable providers, with request/response parser coverage and provider capability docs kept in sync.

The first-agent path is easier to start

The on-ramp now has a smallest runnable first-agent example: a mock-model, no-secret agent you can run before adding provider keys. The CLI and docs also point new users toward the maintained first-agent path after scaffold/run milestones, so the next step after a service is clearer: run the example, build the agent, debug it, then walk the 0→hero services → agents → workflows path.

Plan/delegate is more deterministic

Plan/delegate runs got another reliability pass. Completed plan steps are preserved, ordering is guarded, notify-before-completion is required in the flow path, and checkpoint continuation is more stable. These are the kinds of harness fixes that matter when an agent does real work over multiple tool calls instead of just answering a prompt.

Tool-call recovery keeps improving

Provider text tool-call fallback paths now recover more of the awkward cases: tagged calls, Create-suffixed calls, mixed text/tool-call output, and AtlasCloud follow-up calls. The goal is pragmatic: when a weaker or non-standard provider emits something close to a tool call, the harness should still make progress when it can do so safely.

A2A payment groundwork

The A2A gateway now has the shared payment-mandate foundation needed for AP2-style agent payment flows. It is groundwork, not a full product story yet, but it keeps Go Micro’s agent interop and paid-tool direction moving together.

Read the changelog

The full release notes are in the CHANGELOG.

What's New in Go Micro: v5.15.0

Making Microservices AI-Native with MCP

The Vision

Imagine telling Claude: “Why is user 123’s order stuck?”

Claude responds by:

1. Calling your users service to check the account
2. Calling your orders service to inspect the order
3. Calling your payments service to verify the transaction
4. Giving you a complete diagnosis

No API wrappers. No manual integrations. Your services just work with AI.

What is MCP?

Model Context Protocol is Anthropic’s open standard for connecting AI models to external tools. Think of it like a microservices registry, but for AI.

With MCP, your go-micro services become tools that Claude can discover and call directly.

The Integration

For Library Users (Just Add Comments!)

package main

import (
    "context"
    "go-micro.dev/v5"
    "go-micro.dev/v5/gateway/mcp"
)

type UserService struct{}

// GetUser retrieves a user by ID. Returns user profile with email and preferences.
//
// @example {"id": "user-123"}
func (s *UserService) GetUser(ctx context.Context, req *GetUserRequest, rsp *GetUserResponse) error {
    // implementation
    return nil
}

type GetUserRequest struct {
    ID string `json:"id" description:"User's unique identifier"`
}

type GetUserResponse struct {
    User *User `json:"user" description:"The user object"`
}

func main() {
    service := micro.NewService(micro.Name("users"))
    service.Init()

    // Register handler - docs extracted automatically from comments!
    service.Server().Handle(service.Server().NewHandler(new(UserService)))

    // Add MCP gateway
    go mcp.Serve(mcp.Options{
        Registry: service.Options().Registry,
        Address:  ":3000",
    })

    service.Run()
}

That’s it. Your service is now AI-accessible with automatic documentation.

For CLI Users (Just a Flag)

# Development with MCP
micro run --mcp-address :3000

# Production with MCP
micro server --mcp-address :3000

The CLI integration uses the same underlying library, so you get the same functionality either way.

How It Works

1. Service Discovery: MCP gateway queries your registry (mdns/consul/etcd)
2. Auto-Exposure: Each service endpoint becomes an MCP tool
3. Schema Conversion: Request/response types → JSON Schema for AI
4. Dynamic Updates: New services appear as tools automatically

For example, if you have:

type UsersService struct{}

func (u *UsersService) Get(ctx context.Context, req *GetRequest, rsp *GetResponse) error {
    // ...
}

func (u *UsersService) Create(ctx context.Context, req *CreateRequest, rsp *CreateResponse) error {
    // ...
}

Claude sees:

Tools:
- users.UsersService.Get
- users.UsersService.Create

And can call them with natural language: “Get user 123’s details”

Real-World Use Cases

1. AI-Powered Customer Support

# Claude can help support agents
User: "Why is my order taking so long?"

Claude: Let me check...
→ Calls orders.Orders.Get with user's order ID
→ Calls shipping.Shipping.Track with tracking number
→ Calls inventory.Inventory.Check with product ID

Claude: "Your order is waiting for inventory. The product
is expected to be restocked on Feb 15. Would you like to
switch to an in-stock alternative?"

2. Debugging Production Issues

# Tell Claude the symptoms, it investigates
You: "Users can't log in. Check if it's the auth service."

Claude:
→ Calls health.Check on auth service
→ Calls metrics.Get for error rates
→ Calls logs.Recent for auth failures
→ Calls database.ConnectionPool for connection issues

Claude: "The auth service is healthy but the connection
pool is exhausted. Current: 100/100. Recommend increasing
pool size or checking for connection leaks."

3. Automated Operations

# Claude as an operations assistant
You: "Scale up the worker service"

Claude:
→ Calls infrastructure.Services.List to find workers
→ Calls infrastructure.Services.Scale with new count
→ Calls metrics.Monitor to watch the scale-up

Claude: "Scaled from 3 to 5 workers. All healthy and
processing jobs normally."

4. AI Data Analysis

# Claude can query your services for insights
You: "Show me revenue trends for the last quarter"

Claude:
→ Calls analytics.Revenue.GetTrends with date range
→ Calls analytics.Revenue.Compare with previous quarter
→ Calls analytics.Revenue.TopProducts

Claude: "Revenue is up 23% vs Q4. Top driver is product X
with 45% growth. However, churn increased 5% — recommend
investigating retention."

Deployment Patterns

Pattern 1: Embedded Gateway

Add MCP directly to your services:

func main() {
    service := micro.NewService(...)

    go mcp.Serve(mcp.Options{
        Registry: service.Options().Registry,
        Address:  ":3000",
    })

    service.Run()
}

Best for: Simple deployments, quick prototypes

Pattern 2: Standalone Gateway

Deploy a dedicated MCP gateway service:

// cmd/mcp-gateway/main.go
package main

import (
    "go-micro.dev/v5/gateway/mcp"
    "go-micro.dev/v5/registry/consul"
)

func main() {
    mcp.ListenAndServe(":3000", mcp.Options{
        Registry: consul.NewRegistry(),
    })
}

Best for: Production, multiple services, centralized auth

Pattern 3: Docker Compose

version: '3.8'

services:
  users:
    build: ./users
    environment:
      - MICRO_REGISTRY=mdns

  orders:
    build: ./orders
    environment:
      - MICRO_REGISTRY=mdns

  mcp-gateway:
    build: ./mcp-gateway
    ports:
      - "3000:3000"
    environment:
      - MICRO_REGISTRY=mdns

Best for: Local development, testing

Pattern 4: Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mcp-gateway
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: mcp-gateway
        image: myregistry/mcp-gateway:latest
        ports:
        - containerPort: 3000
        env:
        - name: MICRO_REGISTRY
          value: "consul"
        - name: MICRO_REGISTRY_ADDRESS
          value: "consul:8500"

Best for: Production at scale

Security Considerations

Add Authentication

mcp.Serve(mcp.Options{
    Registry: registry.DefaultRegistry,
    Address:  ":3000",
    AuthFunc: func(r *http.Request) error {
        token := r.Header.Get("Authorization")
        if !validateToken(token) {
            return errors.New("unauthorized")
        }
        return nil
    },
})

Network Isolation

Deploy MCP gateway in a private network:

              Internet
                 │
          ┌──────▼────────┐
          │  micro server │  :8080 (public)
          │   + Auth      │
          └──────┬────────┘
                 │
          ┌──────▼────────┐
          │  MCP Gateway  │  :3000 (private)
          └──────┬────────┘
                 │
      ┌──────────┼──────────┐
      │          │          │
  ┌───▼───┐  ┌──▼────┐  ┌──▼────┐
  │ users │  │ orders│  │payments│
  └───────┘  └───────┘  └────────┘
  (private)  (private)  (private)

Only the HTTP gateway is public. MCP gateway and services are internal.

Library vs CLI

Both approaches use the same underlying library (go-micro.dev/v5/gateway/mcp):

The CLI is just a convenient wrapper around the library.

Getting Started

Install

go get go-micro.dev/v5@v5.16.0

Library Usage

import "go-micro.dev/v5/gateway/mcp"

go mcp.Serve(mcp.Options{
    Registry: service.Options().Registry,
    Address:  ":3000",
})

CLI Usage

micro run --mcp-address :3000
# or
micro server --mcp-address :3000

Test It

# List available tools
curl http://localhost:3000/mcp/tools

# Call a tool
curl -X POST http://localhost:3000/mcp/call \
  -d '{"tool": "users.Users.Get", "input": {"id": "123"}}'

New in v5.16.0: Stdio Transport & Auto-Documentation

We’ve added two major features that make MCP even more powerful:

1. Stdio Transport for Claude Code

Use go-micro services directly in Claude Code with stdio transport:

# Start MCP server with stdio (no HTTP needed)
micro mcp serve

Add to Claude Code config (~/.claude/claude_desktop_config.json):

{
  "mcpServers": {
    "my-services": {
      "command": "micro",
      "args": ["mcp", "serve"]
    }
  }
}

Now Claude Code can discover and call your services directly!

2. Automatic Documentation Extraction

Services now automatically extract documentation from Go comments:

// GetUser retrieves a user by ID from the database.
//
// @example {"id": "user-123"}
func (s *UserService) GetUser(ctx context.Context, req *GetUserRequest, rsp *GetUserResponse) error {
    // implementation
}

// Register handler - docs extracted automatically!
handler := service.Server().NewHandler(new(UserService))

No manual configuration needed! Claude understands your service from your code comments.

3. MCP Command Line Tools

The new micro mcp command provides utilities for working with MCP:

# Start MCP server (stdio by default)
micro mcp serve

# Start with HTTP
micro mcp serve --address :3000

# List available tools
micro mcp list

# Test a tool
micro mcp test users.Users.Get

What’s Next?

We’re continuing to evolve MCP support:

• Streaming responses for long-running operations
• Rate limiting and usage tracking
• MCP server discovery (browse available gateways)
• Enhanced schema generation from struct tags

Philosophy

Go Micro has always been about composable microservices. MCP extends that philosophy:

• Your services, your way: MCP doesn’t change how you build services
• Library-first: Works for all users, not just CLI users
• Zero vendor lock-in: Open protocol, works with any MCP client
• Production-ready: Security, auth, and scaling built-in

AI is becoming infrastructure. Your services should be ready.

Try It Today

# Update to v5.16.0
go get go-micro.dev/v5@v5.16.0

# Add MCP to your service
import "go-micro.dev/v5/gateway/mcp"
go mcp.Serve(mcp.Options{
    Registry: service.Options().Registry,
    Address:  ":3000",
})

# Or use the CLI
micro run --mcp-address :3000

See the MCP Gateway documentation for full details.

What's New in Go Micro: v5.13.0

The Problem

Go Micro has always been great for building microservices:

micro new myservice
cd myservice
micro run

But getting those services to production? That was on you. You’d need to figure out Docker, Kubernetes, or write your own deployment scripts.

We tried to solve this with Micro v3 — a full platform-as-a-service. But it was too much. Too complex. Nobody wanted another platform to manage.

The Solution

The new approach is simple: systemd + SSH.

Every Linux server has systemd. It’s battle-tested, it manages processes, it restarts them when they crash, it handles logging. Why reinvent it?

One-Time Server Setup

ssh user@server
curl -fsSL https://go-micro.dev/install.sh | sh
sudo micro init --server

This creates:

• /opt/micro/bin/ — where your binaries live
• /opt/micro/config/ — environment files
• A systemd template for managing services

Deploy

micro deploy user@server

That’s it. The command:

1. Builds your services for Linux
2. Copies binaries via SSH
3. Configures systemd services
4. Verifies everything is running

Manage

micro status --remote user@server
micro logs --remote user@server
micro logs myservice --remote user@server -f

Named Deploy Targets

Add deploy targets to your micro.mu:

service users
    path ./users
    port 8081

service web
    path ./web
    port 8080

deploy prod
    ssh deploy@prod.example.com

deploy staging
    ssh deploy@staging.example.com

Then:

micro deploy prod
micro deploy staging

Philosophy

• systemd is the standard — don’t fight it, use it
• SSH is the transport — no custom agents or protocols
• Errors guide you — every failure tells you how to fix it
• No platform — just your server, your services

What’s Next?

This is just the beginning. We’re thinking about:

• Secrets management — integrating with vault/sops
• Multi-server deploys — deploy to a fleet
• Metrics — Prometheus endpoints out of the box
• Rolling updates — zero-downtime deployments

Try It

go install go-micro.dev/v5/cmd/micro@v5.13.0
micro new myapp
cd myapp
micro run

# When you're ready to deploy:
micro deploy user@your-server

See the deployment guide for full documentation.