Building Providers
MCP Integration
Exposing provider tools to AI agents through the hub's aggregate MCP endpoint.
kedge presents one aggregate Model Context Protocol endpoint per workspace:
https://<hub>/services/mcpserver/{cluster}/apis/kedge.faros.sh/v1alpha1/mcpservers/{name}/mcp
An AI agent connecting there sees tools from every Ready provider in the workspace, federated by the hub: the edges provider contributes Kubernetes and SSH tools, and each enabled provider with an MCP surface contributes its own, namespaced as <provider>__<tool> — code__create_repository, infrastructure__provision, kuery__kuery_query, and so on. A provider that fails tools/list is skipped, not fatal.
Exposing tools from your provider
Three requirements:
- Serve a streamable-HTTP MCP handler at
/mcpon your backend (the shipped providers use the official MCP Go SDK;providers/infrastructure/mcpserver/is the reference — most also serve/mcp/ssefor older clients). - Be Ready — registered CatalogEntry with a reachable
backend.url, fresh heartbeats. Not-Ready providers are dropped from federation. - Honour forwarded identity. Every MCP request arrives through the backend proxy with
X-Kedge-Tenant,X-Kedge-Cluster, and the caller’sAuthorizationbearer. Do all tenant work as that token, scoped to that workspace — never your provider SA. This is pattern B; an MCP tool must never see more than its caller could with kubectl.
A typical tool implementation resolves the tenant client once per request from the headers, then reads/writes the provider’s own CRs — meaning MCP is usually a thin verb layer over the same API your UI and controllers use.
Design guidance for tools
- Keep tool names short and verb-first (
list_templates,provision,commit_files); the federation prefix supplies your provider name. - Return structured, compact results — AI agents pay per token.
- Tools that mutate should map 1:1 onto resource writes, so everything an agent does is visible as ordinary objects (
kubectl get) and auditable via status/conditions. - Long-lived MCP connections authenticate with a per-
MCPServerservice-account token (referenced fromstatus.tokenSecretRef) rather than a user’s short-lived OIDC token — your handler doesn’t need to care, but don’t build in assumptions that the bearer is a human session.
Consuming MCP instead
Not every provider serves MCP — some consume it. The agents and app-studio providers are MCP clients: their AI loops call the hub aggregate endpoint on the tenant’s behalf, picking up your tools automatically. This is the payoff of federation — implement /mcp once and every AI surface in the platform (Claude Code via the CLI, hosted agents, App Studio chat) can use your provider.