MCP Connector

Route and Manage AI Agent Resources

Wanaku is a governed action proxy that puts policy, identity, and audit between AI agents and the backend systems they act on.

Works with keycloakapache camelkubernetesopenshift

88
Spark score
out of 100
Updated 8 days ago
Source checked Sep 15, 2026
Version 0.2.0
Models
universal

Add to Favorites

Why it matters

Centralize routing and resource management for AI agents, acting as a gateway between multiple MCP servers with extensive integration capabilities.

Outcomes

What it gets done

01

Provide unified access to AI agents and resources.

02

Bridge MCP servers for seamless inter-server communication.

03

Leverage 300+ Apache Camel components for broad integration.

04

Secure access with built-in authentication and authorization.

Source

Get it from source

Spark does not host a copy of it.

Open source

Reports

Agent outcome reports

No reports yet

Overview

Wanaku MCP Router MCP Server

Wanaku is a governed action proxy that sits between AI agents and the systems they act on, enforcing policy, identity, and audit on every tool call instead of letting agents reach backends directly. It auto-discovers tools from upstream MCP servers, isolates them by namespace, and authenticates actions through oauth2-proxy and Keycloak. Use it when AI agents need governed, audited access to real backend systems; skip it if you only need a single MCP server with no policy or identity layer.

What it does

Wanaku is a governed action proxy for AI agents: it sits between agents and the systems they act on, intercepting tool calls, agent-to-agent messages, and inference traffic. Integration developers build Apache Camel routes and publish them as tools; agents call those tools with parameters, but Wanaku runs the actual work - the agent never touches backend systems directly - so policy, identity, data controls, and audit happen in the proxy rather than in the agent itself.

When to use - and when NOT to

Use it when you need to put a governed, auditable layer between AI agents and the real systems they can act on - enforcing policy (LLM-powered evaluators plus WASM action scripts that classify, filter, and block tool calls), identity and auth (via oauth2-proxy and Keycloak, enforced before actions reach backends), and namespace isolation across teams, tenants, or environments. It also auto-discovers tools from upstream MCP servers and re-exposes them locally, so an agent's tool catalog can grow without the client knowing the tools are forwarded.
It's not a fit if you just need a single MCP server exposing your own tools with no policy or identity layer in between - Wanaku's value is specifically the proxy/governance boundary, and running it adds that layer's operational surface (oauth2-proxy, Keycloak, the management API) rather than removing it.

Capabilities

Agent isolation keeps agents talking to Wanaku instead of backend systems directly. Policy enforcement runs LLM-powered evaluators and WASM action scripts in the proxy layer to classify, filter, and block tool calls. Identity and auth flow through oauth2-proxy and Keycloak, enforced before actions reach backends, with Wanaku also serving RFC 9728 OAuth Protected Resource Metadata at /.well-known/oauth-protected-resource/{namespace}/mcp (set WANAKU_AUTH_ISSUER to your Keycloak realm URL to populate authorization_servers). Tool discovery auto-discovers tools from upstream MCP servers registered as forwards via the management API, and namespace isolation organizes tools and resources per team, tenant, or environment. The architecture is extensible through feature crates and a composable filter pipeline, there's a web admin dashboard for managing tools, resources, prompts, and forwards, and multi-arch container images (x86_64, aarch64) publish automatically.

How to install

On Linux or macOS, the early-access installer detects the platform, verifies the release checksum, and installs wanaku-server into $HOME/bin (override with WANAKU_INSTALL_DIR):

curl -fsSL https://raw.githubusercontent.com/wanaku-ai/wanaku/main/get-wanaku.sh | bash

Or run as a container: podman run -p 8080:8080 -p 8081:8081 quay.io/wanaku/wanaku-server, optionally mounting a wanaku.yaml to preload forwards. Building from source needs Rust 1.96+ and Yarn for the admin UI: cargo build && cargo run (the first build compiles the admin UI automatically if ui/admin/dist/ is missing). Once running, the MCP endpoint is at http://localhost:8081/mcp (or /{namespace}/mcp), the management REST API is at http://localhost:8080/api/v1/..., and the admin dashboard is at http://localhost:8080/admin/. Register an upstream MCP server as a forward with a POST to /api/v1/forwards, then refresh it to auto-discover its tools - all of them then appear in the local catalog with the calling client unaware they're forwarded. The project is Apache 2.0 licensed.

Who it's for

Platform and security teams operationalizing AI agents who need policy enforcement, identity, and audit sitting between agents and the systems those agents can reach, rather than trusting each agent to behave.

Source README

Wanaku - A Governed Action Proxy for AI Agents

License
Build
Release

Wanaku is a governed action proxy for AI agents. It sits between agents and the systems they act on, intercepting tool calls, agent-to-agent messages, and inference traffic. Integration developers build Apache Camel routes and publish them as tools; agents call those tools with parameters, but Wanaku runs the actual work - the agent never touches backend systems directly. Policy, identity, data controls, and audit happen in the proxy, not in the agent.

The project name comes from the origins of the word Guanaco, a camelid native to
South America.

Key Features

  • Agent Isolation - Agents call tools through Wanaku; they never reach backend systems directly
  • Policy Enforcement - LLM-powered evaluators + WASM action scripts classify, filter, and block tool calls in the proxy layer
  • Identity & Auth - Authentication and authorization via oauth2-proxy and Keycloak, enforced before actions reach backends
  • Tool Discovery - Auto-discover tools from upstream MCP servers; integration developers publish Camel routes as tools
  • Namespace Isolation - Organize tools and resources across isolated namespaces per team, tenant, or environment
  • Extensible Architecture - Plugin system via feature crates and a composable filter pipeline
  • Admin Dashboard - Web UI for managing tools, resources, prompts, and forwards
  • Container-Ready - Multi-arch images (x86_64, aarch64) published automatically

Quick Start

Install

Download the latest early-access build on Linux or macOS:

curl -fsSL https://raw.githubusercontent.com/wanaku-ai/wanaku/main/get-wanaku.sh | bash

The installer detects the host platform, verifies the release checksum, and installs wanaku-server into $HOME/bin. Override the destination with WANAKU_INSTALL_DIR.

Container

podman run -p 8080:8080 -p 8081:8081 quay.io/wanaku/wanaku-server

To preload forwards, mount a wanaku.yaml:

podman run -p 8080:8080 -p 8081:8081 \
  -v ./wanaku.yaml:/etc/wanaku/wanaku.yaml \
  quay.io/wanaku/wanaku-server \
  --wanaku-config /etc/wanaku/wanaku.yaml

From Source

cargo build
cargo run

The first cargo build automatically builds the admin UI via yarn if ui/admin/dist/ is missing.

Endpoints

Endpoint Address Description
MCP http://localhost:8081/mcp MCP protocol endpoint (or /{namespace}/mcp for namespaced access)
Management API http://localhost:8080/api/v1/... CRUD for tools, resources, prompts, forwards, namespaces
Admin UI http://localhost:8080/admin/ Web dashboard

Learn Wanaku

The easiest way to learn Wanaku is by following the guided tutorial.

The reference documentation, including the complete installation and configuration instructions, is available in the usage guide.

Configuration

Drop a wanaku.yaml in the working directory to preload forward definitions:

forwards:
  - name: "upstream-mcp"
    address: "http://remote.example.com/mcp"

If no config file is provided, the server starts with an empty registry that can be populated via the management API.

Management API Examples

Register a remote MCP server as a forward (its tools are auto-discovered):

curl -X POST http://localhost:8080/api/v1/forwards \
  -H "Content-Type: application/json" \
  -d '{
    "name": "upstream-mcp",
    "address": "http://remote.example.com/mcp"
  }'

Refresh tools from the forward (auto-discover):

curl -X POST http://localhost:8080/api/v1/forwards/upstream-mcp/refreshes

All tools from the remote server now appear in your local catalog. The client has no idea they're forwarded.

Authentication

Authentication is handled externally by oauth2-proxy. Two instances sit in front of the MCP and management ports, sharing an SSO cookie:

  • MCP proxy (:4180:8081) - protects MCP endpoints, any authenticated user
  • Management proxy (:4181:8080) - protects the admin UI and REST API, admin role required

Wanaku also serves RFC 9728 OAuth Protected Resource Metadata at /.well-known/oauth-protected-resource/{namespace}/mcp. Set WANAKU_AUTH_ISSUER to your Keycloak realm URL to populate the authorization_servers field.

See deploy/auth/README.md for setup instructions (Docker Compose and local development).

Documentation

The Wanaku Documentation website contains the full project documentation.

Contributors working on the project may want to refer to the development documentation:

Community

Related Projects

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.