MCP Infrastructure

These packages let you run an internal registry where MCP servers can register themselves, be discovered by capability, and have their health monitored automatically. You'd adopt them to solve the problem of finding and managing MCP servers across a team or organization without relying on a public directory or ad‑hoc documentation. The most distinctive thing is that the catalog itself is exposed as an MCP server, so any MCP client can query it using the same protocol the registered servers speak.

These packages automatically detect changes in MCP server tool schemas between git tags and generate changelogs, migration guides, and machine-readable diffs. You would adopt them to eliminate the manual work of tracking schema changes across releases and producing documentation that helps users understand what broke and how to migrate. The tool works as both a CLI and a GitHub Action that posts auto-updating PR comments, and it pairs with a companion package that prevents breaking changes while this one documents them.

These packages give you a full-featured API gateway for MCP servers, handling authentication, rate limiting, schema validation, tool allowlists, fan-out routing, response caching, audit logging, and OpenTelemetry observability. You would adopt them to add production-grade access control, traffic management, and observability to an MCP server deployment without building these capabilities from scratch. Each capability ships as a separate package with a framework-neutral core and thin Express or Fastify adapters, so you can compose exactly the pipeline you need and run it on either framework with the same tenant context flowing through every stage.

These packages give you a diff engine and CI policy for MCP tool schemas, classifying every change between two `Tool[]` snapshots as breaking, non-breaking, or patch. You'd adopt them to prevent breaking MCP consumers when you add, remove, or rename tool fields, catching unintended changes before a release. The core library returns `Result<T>` objects instead of throwing, and the CI package enforces policy through a pipe-delimited acknowledgment file that lets you explicitly allow intentional breaking changes.

These packages give you a production-ready MCP server with Express 5, pluggable auth, rate limiting, idempotency, structured logging, OpenTelemetry tracing, and dual Streamable HTTP/SSE transports. You'd adopt them to skip building the operational scaffolding around an MCP server—auth, observability, security middleware, and transport session management—and instead focus on writing tools. The most distinctive thing is that every concern (auth, observability, transport, tools) is a separate, independently installable package, but the engine package wires them together into a single middleware pipeline with auto-discovery of `.tool.ts` files.

These packages let you run a single MCP server that serves multiple tenants, with each tenant getting its own rate limits, tool visibility, cost tracking, and isolated artifact storage. You'd adopt them to avoid standing up a separate MCP server per customer while still enforcing per-tenant boundaries on usage, access, and billing. The distinctive thing is that every concern—tenant resolution, rate limiting, visibility, cost accounting, artifact storage, config isolation, and observability—is a separate package you compose into a single middleware function that wraps any MCP server's request handlers.

These packages give AI coding agents a catalog of reusable skills—each a structured markdown file that tells the agent what a specific `@reaatech` package does, when to use it, and how to install it. You would adopt them to stop writing ad-hoc tool-use instructions for your agent and instead give it a discoverable, versioned library of capabilities it can pull from on demand. The most distinctive thing is that the skills follow Anthropic's progressive-disclosure pattern: the agent reads a one-line description to decide relevance, then loads the full body only when it reaches for that skill, keeping context small and decisions fast.

These packages give you an MCP server that receives webhooks from services like Stripe, GitHub, and Twilio, normalizes them into a consistent event format, and exposes them to AI agents through subscription-based polling. You would adopt them to bridge third-party webhooks into agent workflows without writing custom ingestion or validation code for each source. The packages are layered so you can run the bundled server with a single command, or import just the storage, webhook handlers, or MCP tool definitions as libraries.