Analyzed 31 days ago · 2 anonymous rescans remaining · register free to re-analyze any time.
Public analysis · read only
Register free to re-analyze

metatool-ai/metamcp

2,538 382 90 issues
TypeScript
MIT

Project Overview

anthropic / claude-opus-4-7

MetaMCP

Self-hosted proxy that aggregates multiple MCP servers into unified endpoints with middleware and auth.

AI Verdict
Clean— AI Trust Assessment

True Intent (AI Assessment)

A self-hosted middleware/gateway that aggregates and secures many MCP servers behind one unified, authenticated MCP/HTTP interface.

README Accuracy

Accurate

Notes

README description matches the code: MCP aggregation, middleware, OIDC/OAuth, namespaces, endpoints, and Docker-first deployment are all present in the source.

What Is This?

MetaMCP is a self-hostable gateway and orchestrator for Model Context Protocol (MCP) servers. It presents itself as a single MCP server to clients (Cursor, Claude Desktop, etc.) while, behind the scenes, aggregating tools and resources from many downstream MCP servers into unified 'namespaces' and 'endpoints'. It also exposes an admin web UI, a tRPC API, and OAuth/OIDC-secured HTTP endpoints for calling those aggregated tools.

The problem it addresses is fragmentation in the MCP ecosystem. Users typically wire each MCP server directly into each client, duplicating configuration, secrets, and rate limits, with no central place to inspect traffic, apply middleware (filtering, overrides, auditing), or restrict who can call which tools. MetaMCP centralizes that: one Docker deployment sits between clients and dozens of MCP servers, adds authentication, audit logs, rate limiting, tool overrides, and re-exposes everything as MCP or as an OpenAPI-style HTTP surface.

Target users are developers and small teams running AI agents/IDE assistants that consume MCP tools, plus organizations that want an on-prem MCP hub with SSO (OIDC), per-user API keys, and audit trails. Deployment is primarily via docker-compose; a nginx.conf example and dev container are provided. Clients connect either via MCP transports or via generated public endpoints.

Architecturally it is a TypeScript pnpm/turbo monorepo. The backend (apps/backend) is Express 5 + tRPC + better-auth, uses Drizzle ORM against PostgreSQL (18 migrations covering MCP servers, namespaces, endpoints, OAuth sessions/tokens, API keys, audit logs, tool overrides). It spawns downstream MCP servers (STDIO via cross-spawn/execa/spawn-rx) and proxies HTTP/SSE streams through /mcp-proxy and /metamcp routes. The frontend (apps/frontend) is Next.js 15 + React 19 + Radix UI + Tailwind, talking to the backend via tRPC. Shared packages provide Zod types, tRPC routers, and lint/TS configs.

No red flags observed. The code is a legitimate, actively maintained proxy; sensitive surfaces (auth handler, OAuth, spawning child processes) are isolated in dedicated modules, migrations show an evolving audit/OAuth security model, and pnpm overrides pin several vulnerable transitive dependencies to patched versions.

Your Report, Tab by Tab
At a Glance
2,538Stars
382Forks
90Open Issues
June 2026Last Active
Web App / Gateway (MCP proxy with admin UI)TypeScriptMIT
Technology Stack
LanguagesTypeScript, CSS, Shell, Dockerfile
RuntimeNode.js >=18 (pnpm 10)
FrameworkExpress 5 (backend), Next.js 15 + React 19 (frontend)
DatabasePostgreSQL via Drizzle ORM
Package Managerpnpm (workspaces + Turborepo)
Key Dependencies@modelcontextprotocol/sdk, @trpc/server, better-auth, drizzle-orm, express, next, zod, tailwindcss
Build ToolTurbo + tsup (backend/packages), Next.js/Turbopack (frontend)
Test FrameworkVitest (backend)