* docs: add AI provider integration guide and Supported AI Providers section Add a step-by-step guide for AI infrastructure companies to implement ai.Model and contribute a provider to go-micro. Covers the full lifecycle: skeleton, tool call handling, tests, registration, and PR checklist. Add a "Supported AI Providers" section to the project README that lists current providers (Anthropic, OpenAI) in a table and links to the integration guide with a call-to-action for new providers and sponsors. Streamline the "Adding a New Provider" section in ai/README.md to point to the new guide instead of duplicating a full code listing. * fix: remove nonexistent Discord link from README * fix(website): set content container width to 800px on desktop Move the 800px max-width from .markdown-body up to .content so the entire content pane (not just the inner body) is sized correctly. The container now fills up to 800px beside the sidebar. * feat(ai): wire Atlas Cloud into server and auto-detection Import atlascloud provider in the micro server so it is available when running micro run / micro server. Add atlascloud to AutoDetectProvider so --ai_base_url with an atlascloud domain selects the right provider automatically. * feat(ai): add Google Gemini provider Add ai/gemini implementing ai.Model for Google's Gemini API. Uses the native generateContent endpoint with system_instruction, contents/parts, and functionDeclarations — not an OpenAI shim. Default model gemini-2.5-flash, auth via x-goog-api-key header. Wire into micro server imports and AutoDetectProvider (matches googleapis.com and google in base URL). Update README.md and ai/README.md with provider listing. * feat(ai): add Groq, Mistral, and Together AI providers Add three new OpenAI-compatible providers: - ai/groq: ultra-fast inference, default model llama-3.3-70b-versatile - ai/mistral: Mistral AI, default model mistral-large-latest - ai/together: Together AI, default model Llama-3.3-70B-Instruct-Turbo All three are wired into the micro server imports and AutoDetectProvider. README and ai/README updated with the full provider table. * feat(ai): add ai/tools helper and 'micro chat' interactive agent Extract the registry-discovery + RPC-execution loop from the web agent playground into a reusable ai/tools package: - tools.New(reg) creates a Set bound to a registry - Set.Discover() walks the registry and returns []ai.Tool with LLM-safe (underscored) names, remembering the mapping back to the original dotted form - Set.Handler(client) returns an ai.ToolHandler that resolves the safe name and issues the RPC Add cmd/micro/chat — an interactive 'micro chat' REPL that uses ai/tools to let users talk to their services through any registered AI provider. Supports --prompt for single-shot use, auto-detects the provider from --base_url, and falls back to the provider's conventional env var (ANTHROPIC_API_KEY, etc). Update README with the new command and the programmatic example. * feat(examples): add gRPC interop example Add examples/grpc-interop showing that any standard gRPC client can call a go-micro service — no go-micro SDK required on the client side. Includes: - proto/greeter.proto with generated Go, gRPC, and micro stubs - server/ using go-micro gRPC transport - client/ using stock google.golang.org/grpc (no go-micro imports) - README with Python example and explanation of how routing works Addresses the confusion from issue #2818 where users didn't know that go-micro gRPC services are callable by any gRPC client. --------- Co-authored-by: Claude <noreply@anthropic.com>
gRPC Interop Example
This example shows that any standard gRPC client can call a go-micro service — no go-micro SDK required on the client side.
The server is a normal go-micro service using the gRPC transport. The client is a plain google.golang.org/grpc client with no go-micro imports.
How it works
go-micro's gRPC server uses a grpc.UnknownServiceHandler that catches all incoming requests and routes them by parsing the standard gRPC method path (/package.Service/Method). This means any language with gRPC support (Python, Java, Rust, etc.) can call go-micro services using generated protobuf stubs.
Running
Start the server:
cd examples/grpc-interop
go run ./server/
In another terminal, call it with the standard gRPC client:
cd examples/grpc-interop
go run ./client/ --name Alice
# Response: Hello Alice
Calling from other languages
Generate stubs from proto/greeter.proto in your language of choice and point them at localhost:50051. For example, with Python:
pip install grpcio-tools
python -m grpc_tools.protoc -Iproto --python_out=. --grpc_python_out=. proto/greeter.proto
import grpc
import greeter_pb2
import greeter_pb2_grpc
channel = grpc.insecure_channel("localhost:50051")
stub = greeter_pb2_grpc.GreeterStub(channel)
response = stub.Hello(greeter_pb2.HelloRequest(name="Alice"))
print(response.message) # Hello Alice
Key points
- The go-micro server registers handlers via
pb.RegisterGreeterHandler() - The standard gRPC client uses stubs generated by
protoc-gen-go-grpc - Both share the same
.protofile — that's the contract - The server uses protobuf encoding on the wire, same as any gRPC service
- Service discovery (mDNS, consul, etc.) is only needed for go-micro-to-go-micro calls; direct gRPC clients connect by address
Regenerating proto stubs
protoc --go_out=. --go_opt=paths=source_relative \
--go-grpc_out=. --go-grpc_opt=paths=source_relative \
--micro_out=. --micro_opt=paths=source_relative \
proto/greeter.proto
Requires protoc-gen-go, protoc-gen-go-grpc, and protoc-gen-micro.