DEV Community: optml

Securing AI Agents with 42 Built-in Plugins

optml — Wed, 04 Mar 2026 08:37:26 +0000

In Part 1, we covered why MCP gateways matter. In Part 2, we set up ContextForge and executed tool calls. Now let's talk about what makes ContextForge genuinely different from other MCP proxies: the plugin pipeline.

ContextForge ships with 42 built-in plugins covering security, performance, content processing, input validation, and policy enforcement. In this post, we'll enable them, see them in action, and understand how they protect AI agents in production.

How the Plugin Pipeline Works

Every tool call and resource fetch passes through a chain of plugins, organized by hooks:

Agent Request
     ↓
[tool_pre_invoke]     ← Validate, filter, rate-limit BEFORE the tool runs
     ↓
  Tool Execution
     ↓
[tool_post_invoke]    ← Filter, compress, audit AFTER the tool returns
     ↓
Response to Agent

The same pattern applies to resources (resource_pre_fetch / resource_post_fetch) and prompts (prompt_pre_fetch / prompt_post_fetch).

Plugins execute in priority order within each hook band. Same-priority plugins run in parallel for performance.

Plugin Modes

Mode	Behavior
`enforce`	Block requests that violate the plugin's rules
`permissive`	Log violations but allow the request through
`disabled`	Plugin is not loaded

The 42 Plugins at a Glance

Category	Count	Key Plugins
Security & Compliance	13	PII Filter, Secrets Detection, SQL Sanitizer, VirusTotal, Content Moderation
Performance & Optimization	8	Rate Limiter, Circuit Breaker, Cache, Watchdog, TOON Encoder
Content Processing	9	HTML→Markdown, JSON Repair, Code Formatter, Summarizer
Input Validation	6	Schema Guard, Argument Normalizer, SPARC Validator
Networking	4	Header Injector, Vault, Webhook Notification
Policy Engine	1	Unified PDP (Cedar + OPA + RBAC + MAC combined)

Plus 3 Rust-powered plugins (PyO3) for performance-critical paths: PII Filter, Secrets Detection, Encoded Exfil Detection.

Deep Dive: Key Plugins in Action

PII Filter — Mask Sensitive Data

The PII Filter scans tool responses for personally identifiable information and masks it before it reaches the LLM.

What it catches:

Social Security Numbers: 123-45-6789 → ***-**-****
Email addresses: john@company.com → ****@****
Credit card numbers, phone numbers, IP addresses

Rust-powered variant: The PIIDetectorRust plugin uses PyO3 bindings for 10x faster detection on high-throughput paths.

# Verified: Rust PII detector in action
from pii_filter import PIIDetectorRust

detector = PIIDetectorRust()
result = detector.detect("My email is john@test.com and SSN is 123-45-6789")
# Returns: [PIIFinding(type="email", ...), PIIFinding(type="ssn", ...)]

DenyList — Block Prohibited Content

Define words or patterns that must never appear in tool responses:

# plugins/config.yaml
- name: "DenyList"
  mode: "enforce"
  config:
    denied_words: ["innovative", "revolutionary", "groundbreaking"]
    action: "block"

In enforce mode, any tool response containing these words is immediately blocked. Useful for preventing AI hallucination buzzwords, competitor names, or regulated terms.

TOON Encoder — Save 30-70% on LLM Tokens

TOON (Tool Output Optimized Notation) is a custom encoding that compresses JSON tool results before they're sent to the LLM:

Standard JSON:  {"name": "John", "role": "admin", "active": true}
TOON encoded:   n:John|r:admin|a:1

Real-world measurement: 15% reduction on small JSON, 30-70% on larger payloads. This directly reduces LLM API costs.

Rate Limiter — Per-Team, Per-User Throttling

- name: "RateLimiter"
  mode: "enforce"
  config:
    requests_per_minute: 60
    burst: 10

Prevent runaway agents from overwhelming backend systems or burning through API quotas.

URL Reputation — Block Malicious Endpoints

Checks URLs in tool arguments against threat intelligence feeds:

Agent tries to call: fetch_url("http://malicious.example.com/payload")
     ↓
URL Reputation Plugin: ⛔ BLOCKED (known malicious domain)

Cached Tool Results — Avoid Redundant Calls

If an agent calls the same tool with the same arguments within the cache TTL, the cached result is returned instantly:

First call:  get_current_time(timezone="UTC")  → 150ms (real call)
Second call: get_current_time(timezone="UTC")  → 2ms (cached)

Summarizer — LLM-Powered Response Compression

For large tool responses (documentation, logs, data dumps), the Summarizer plugin calls a secondary LLM to compress the content:

- name: "Summarizer"
  mode: "enforce"
  config:
    provider: "anthropic"
    anthropic:
      model: "claude-haiku-4-5-20251001"
      max_tokens: 256
    threshold_chars: 500

Responses exceeding the threshold are automatically summarized before reaching the primary agent.

Unified PDP — Multi-Engine Policy Decisions

The Unified PDP plugin integrates four policy engines into one interface:

Cedar — AWS's policy language
OPA — Open Policy Agent (Rego)
RBAC — Native role-based access control
MAC — Mandatory Access Control (Bell-LaPadula model)

- name: "UnifiedPDPPlugin"
  mode: "enforce"
  config:
    engines: ["native_rbac"]  # Start simple, add Cedar/OPA as needed

Running 28 Plugins Simultaneously

We tested 28 plugins running at the same time. Here's the verified configuration:

Total plugins: 42
Enabled: 28  |  Disabled: 14

Hooks distribution:
├─ tool_pre_invoke:     17 plugins
├─ tool_post_invoke:    26 plugins
├─ resource_pre_fetch:   7 plugins
├─ resource_post_fetch: 14 plugins
├─ prompt_pre_fetch:    10 plugins
└─ prompt_post_fetch:    7 plugins

Modes: enforce=18, permissive=10

Performance impact: With 28 plugins active, health endpoint response stayed at 4ms, gateway queries at 7ms. The parallel execution model keeps latency low.

Observability: See Everything

Prometheus Metrics

curl http://localhost:8000/metrics/prometheus
# 801 lines, 44 metric definitions

Key metrics include:

mcp_tool_calls_total — per-tool call counts
mcp_plugin_executions_total — per-plugin execution counts
mcp_tool_call_duration_seconds — latency histograms
mcp_active_sessions — concurrent session gauge

Aggregated JSON Metrics

curl http://localhost:8000/metrics
# Structured summary: tools, resources, servers, prompts, a2a_agents

Tool Annotations

Each tool exposes metadata about its behavior:

{
  "name": "get_current_time",
  "annotations": {
    "readOnlyHint": true,
    "openWorldHint": true
  }
}

Agents can use these hints to make smarter decisions about tool usage.

Enabling Plugins

All plugin configuration lives in plugins/config.yaml:

plugins:
  - name: "PIIFilterPlugin"
    mode: "enforce"        # enforce | permissive | disabled
    priority: 10           # Lower = runs first
    hooks:
      - "tool_post_invoke"
      - "resource_post_fetch"
    config:
      patterns:
        - type: "ssn"
          regex: "\\d{3}-\\d{2}-\\d{4}"
          mask: "***-**-****"

Enable the plugin system in .env:

PLUGINS_ENABLED=true
PLUGINS_CONFIG_FILE=plugins/config.yaml

Check the status via Admin API:

curl http://localhost:8000/admin/plugins/stats \
  -H "Authorization: Bearer ${TOKEN}"

Load Testing Results

We ran Locust with 10 concurrent users for 30 seconds against a gateway with 28 active plugins:

Endpoint	Avg Response	p99
`/health`	4ms	12ms
`/gateways`	7ms	22ms
`/servers`	13ms	38ms
`/admin/`	43ms	95ms

~290 requests total, zero failures. The plugin pipeline adds minimal overhead.

Infrastructure We Verified

Component	Details
HTTPS/TLS	TLS 1.3, AEAD-AES256-GCM-SHA384, RSA-4096 self-signed certs
PostgreSQL	Alembic migrations, 60 tables created, full CRUD verified
Redis	v8.6.1, PING/PONG connectivity, caching layer
Rust Plugins	PIIDetectorRust built via maturin, detect/mask verified
Load Test	Locust 10 users / 30s, 4-43ms avg response

The Full Picture

AI Agent
   ↓
[ContextForge Gateway]
   ├─ JWT Authentication
   ├─ Token Scoping (what can you see?)
   ├─ RBAC (what can you do?)
   ├─ Plugin Pipeline:
   │   ├─ PII Filter (mask sensitive data)
   │   ├─ Rate Limiter (throttle per team)
   │   ├─ DenyList (block prohibited content)
   │   ├─ SQL Sanitizer (prevent injection)
   │   ├─ TOON Encoder (compress for LLM)
   │   ├─ URL Reputation (block malicious URLs)
   │   ├─ Watchdog (track response times)
   │   └─ ... 35 more plugins
   ├─ Prometheus Metrics
   └─ Audit Logging
   ↓
Backend Tools (MCP, REST, gRPC, A2A)

Summary

ContextForge isn't just an MCP proxy — it's a governance layer for AI agents. The 42 built-in plugins give you:

Data protection without modifying agent code
Cost optimization through TOON compression and caching
Compliance with PII filtering, audit logs, and policy engines
Reliability with rate limiting, circuit breakers, and watchdogs
Visibility with Prometheus metrics and structured logging

All open source, all configurable, all running with minimal latency overhead.

ContextForge is open source under Apache 2.0.

IBM / mcp-context-forge

An AI Gateway, registry, and proxy that sits in front of any MCP, A2A, or REST/gRPC APIs, exposing a unified endpoint with centralized discovery, guardrails and management. Optimizes Agent & Tool calling, and supports plugins.

ContextForge

An open source registry and proxy that federates MCP, A2A, and REST/gRPC APIs with centralized governance, discovery, and observability. Optimizes Agent & Tool calling, and supports plugins.

ContextForge is an open source registry and proxy that federates tools, agents, and APIs into one clean endpoint for your AI clients. It provides centralized governance, discovery, and observability across your AI infrastructure:

Tools Gateway — MCP, REST, gRPC-to-MCP translation, and TOON compression
Agent Gateway — A2A protocol, OpenAI-compatible and Anthropic agent routing
API Gateway — Rate limiting, auth, retries, and reverse proxy for REST services
Plugin Extensibility — 40+ plugins for additional transports, protocols, and integrations
Observability — OpenTelemetry tracing with Phoenix, Jaeger, Zipkin, and other OTLP backends

It runs as a fully compliant MCP server, deployable via PyPI or Docker, and scales to multi-cluster environments on Kubernetes with Redis-backed federation and caching.

Overview & Goals
Quick Start…

View on GitHub

Getting Started with ContextForge: From Zero to Tool Calls in 15 Minutes

optml — Wed, 04 Mar 2026 08:36:32 +0000

In Part 1, we covered why you need an MCP gateway. Now let's get hands-on.

By the end of this post, you'll have:

A running ContextForge gateway
An MCP server registered and discoverable
Tool calls executing through the gateway
Admin UI up and running

All on your local machine, in about 15 minutes.

Prerequisites

Python 3.12+
uv (package manager) — pip install uv if you don't have it
Git

Step 1: Clone and Configure

git clone https://github.com/IBM/mcp-context-forge.git
cd mcp-context-forge
cp .env.example .env

Edit .env — change these default values for local development:

# Admin UI login
BASIC_AUTH_PASSWORD=Dev@Local2026!

# JWT signing key (32+ characters)
JWT_SECRET_KEY=contextforge-dev-secret-key-2026-not-for-prod

# Stored secrets encryption key
AUTH_ENCRYPTION_SECRET=contextforge-dev-encryption-salt-2026

# Platform admin account
PLATFORM_ADMIN_EMAIL=admin@example.com
PLATFORM_ADMIN_PASSWORD=Dev@Admin2026!

Step 2: Install Dependencies

make install-dev

This creates a virtual environment at ~/.venv/mcpgateway and installs ~289 packages including dev dependencies.

Verify:

make check-env-dev

Note: Use check-env-dev, not check-env. The latter reads .env.example defaults and will flag security warnings.

Step 3: Run the Tests (Optional but Recommended)

make test

13,755+ tests, 99% coverage, ~67 seconds. Some tests skip based on your environment (no Rust, no PostgreSQL, etc.) — that's normal. Zero failures = success.

Step 4: Start the Dev Server

make dev

You now have:

API: http://localhost:8000
Swagger Docs: http://localhost:8000/docs
Admin UI: http://localhost:8000/admin/login

Step 5: Log Into the Admin UI

Open http://localhost:8000/admin/login:

Field	Value
Email	`admin@example.com`
Password	`Dev@Admin2026!`

On first login, you'll be asked to change your password. Set it to something like Dev@Admin2026!New#1.

The database is file-based SQLite (mcp.db), so your changed password persists across server restarts.

Step 6: Generate a JWT Token

API calls require a Bearer token. Open a new terminal:

source ~/.venv/mcpgateway/bin/activate

python -m mcpgateway.utils.create_jwt_token \
  --username admin@example.com \
  --exp 10080 \
  --secret contextforge-dev-secret-key-2026-not-for-prod \
  --admin

# Save the output
export TOKEN="<paste-the-generated-token>"

Important: The --admin flag is required. Without it, admin API calls return "Authorization token required".

Step 7: Register an MCP Server

We'll use mcp-server-time as an example. ContextForge's translate command converts stdio MCP servers to SSE:

Terminal 1 — Start the MCP server:

source ~/.venv/mcpgateway/bin/activate

python -m mcpgateway.translate \
  --stdio "uvx mcp-server-time --local-timezone UTC" \
  --port 9000

Output:

Multi-protocol server ready → SSE: http://127.0.0.1:9000/sse

Terminal 2 — Register it with the gateway:

curl -s -X POST http://localhost:8000/gateways \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"name": "time-server", "url": "http://localhost:9000/sse"}' \
  | python -m json.tool

Response:

{
    "id": "4ba5541fd0bc486ea68830e39b1febdb",
    "name": "time-server",
    "url": "http://localhost:9000/sse",
    "transport": "SSE",
    "enabled": true,
    "reachable": true
}

Note: The URL must include /sse — that's where the translate server exposes its SSE endpoint.

Step 8: Discover Tools

curl -s http://localhost:8000/tools \
  -H "Authorization: Bearer ${TOKEN}" \
  | python -m json.tool

You should see tools like get_current_time automatically discovered from the registered server.

Step 9: Execute a Tool Call

curl -s -X POST http://localhost:8000/tools/get_current_time/call \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"arguments": {"timezone": "America/New_York"}}' \
  | python -m json.tool

You get back the current time — routed through ContextForge, logged, and ready for plugin processing.

Step 10: Explore the Admin Dashboard

Go back to http://localhost:8000/admin/ and explore:

Section	What You'll See
Dashboard	Server/tool/resource counts, system health
Gateways	Your registered `time-server`
Tools	`get_current_time` discovered from the server
Plugins	42 available plugins (enable/disable from config)
Servers	Virtual server management
Logs	Request/response audit trail

Step 11: Check the API Docs

Visit http://localhost:8000/docs for the full Swagger UI:

344 API endpoints documented with OpenAPI 3.1.0
Try-it-out functionality for every endpoint
Schema definitions for all request/response models

What We Just Did

                    ┌────────────────────┐
mcp-server-time ──→ │                    │
  (stdio→SSE)       │   ContextForge     │ ← Admin UI
                    │   Gateway :8000    │ ← Swagger Docs
                    │                    │ ← JWT Auth
                    └────────────────────┘
                              ↑
                    curl / AI Agent / SDK

In 15 minutes, we set up a fully functional MCP gateway with:

Authentication (JWT)
Server discovery
Tool execution
Admin dashboard
API documentation

Bonus: HTTPS in 30 Seconds

ContextForge ships with self-signed certificate generation:

# If certs don't exist yet, they'll be created automatically
SSL=true CERT_FILE=certs/cert.pem KEY_FILE=certs/key.pem make serve-ssl

Result: TLS 1.3, AEAD-AES256-GCM-SHA384, RSA-4096 — production-grade encryption.

Bonus: PostgreSQL Backend

Swap SQLite for PostgreSQL with one environment variable:

DATABASE_URL="postgresql+psycopg://user:pass@localhost:5432/mcp" make dev

Alembic migrations run automatically, creating 60 tables. Same API, same features, production-ready persistence.

What's Next

In Part 3, we'll enable plugins and see the real power of ContextForge:

PII filtering that masks sensitive data before it reaches the LLM
Rate limiting per team and per user
TOON compression that saves 30-70% on LLM tokens
28 plugins running simultaneously in a pipeline
Prometheus metrics and observability

ContextForge is open source under Apache 2.0.

IBM / mcp-context-forge

An AI Gateway, registry, and proxy that sits in front of any MCP, A2A, or REST/gRPC APIs, exposing a unified endpoint with centralized discovery, guardrails and management. Optimizes Agent & Tool calling, and supports plugins.

ContextForge

An open source registry and proxy that federates MCP, A2A, and REST/gRPC APIs with centralized governance, discovery, and observability. Optimizes Agent & Tool calling, and supports plugins.

Tools Gateway — MCP, REST, gRPC-to-MCP translation, and TOON compression
Agent Gateway — A2A protocol, OpenAI-compatible and Anthropic agent routing
API Gateway — Rate limiting, auth, retries, and reverse proxy for REST services
Plugin Extensibility — 40+ plugins for additional transports, protocols, and integrations
Observability — OpenTelemetry tracing with Phoenix, Jaeger, Zipkin, and other OTLP backends

It runs as a fully compliant MCP server, deployable via PyPI or Docker, and scales to multi-cluster environments on Kubernetes with Redis-backed federation and caching.

Overview & Goals
Quick Start…

View on GitHub

In Part 3, we enable the plugin pipeline and see what makes ContextForge genuinely different.

Why You Need an MCP Gateway for Enterprise AI Agents

optml — Wed, 04 Mar 2026 08:35:43 +0000

MCP adoption is accelerating — but so are the risks. Every AI agent with direct API access is a potential data leak, permission escalation, or compliance violation waiting to happen.

What if you could govern every AI agent tool call through a single layer?

This is Part 1 of a 3-part series on ContextForge, an open-source MCP gateway that brings enterprise-grade security, observability, and 42 built-in plugins to AI agent infrastructure.

The Problem: AI Agents Without Guard Rails

Imagine your company adopts an AI agent platform. Different teams spin up agents:

                          ┌→ SAP ERP (REST)
HR Agent ─────────────────┼→ Employee DB (SQL)
                          └→ Slack API

                          ┌→ Salesforce (REST)
Sales Agent ──────────────┼→ Internal CRM (gRPC)
                          └→ Email Service

                          ┌→ Jenkins (REST)
DevOps Agent ─────────────┼→ GitHub API
                          └→ Cloud Infrastructure

Each agent connects directly to each API. What could go wrong?

Problem	Real-World Scenario
Data Leaks	HR agent accidentally sends employee SSNs to the LLM
Permission Chaos	An intern's agent runs `DROP TABLE` on production
No Audit Trail	"Who called what API when?" — nobody knows
Connection Sprawl	100 APIs x 50 agents = 5,000 individual connections
Cost Blindness	No idea which team is burning through LLM tokens

These aren't hypothetical risks. They're the inevitable result of letting AI agents access enterprise systems without centralized governance.

The Solution: Put a Gateway in the Middle

ContextForge sits between your AI agents and your backend systems:

                                                ┌→ SAP ERP
HR Agent ─────────┐                             ├→ Employee DB
                  │    ┌────────────────────┐   ├→ Salesforce
Sales Agent ──────┼───→│   ContextForge     │──→├→ CRM (gRPC→MCP auto-convert)
                  │    │                    │   ├→ Jenkins
DevOps Agent ─────┘    │  Security · Audit  │   ├→ GitHub
                       │  Plugin Pipeline   │   └→ Cloud APIs
AI Platform ──────────→│                    │
(Claude Code, etc.)    └────────────────────┘

Every request flows through the gateway. Every response gets filtered. Everything gets logged.

What ContextForge Actually Does

1. Turns Your Existing APIs into AI Tools — Automatically

Enterprises already have hundreds of REST and gRPC APIs. ContextForge converts them into MCP tools without modifying the original services:

Existing SAP REST API  → Register in ContextForge → Agents use it as a "tool"
Existing gRPC service  → Auto-discovery via Reflection → MCP tool, no schema needed

No code changes to existing systems. Your investment is protected.

2. Prevents Data Leaks at the Gateway Level

Every tool call and response passes through a plugin pipeline:

Agent Request: "Look up John's employee record"
     ↓
[ContextForge Plugin Pipeline]
     ├─ PII Filter        → SSN 123-45-6789 → ***-**-****
     ├─ Secrets Detection  → DB password detected → masked
     ├─ SQL Sanitizer      → SQL injection attempt → blocked
     └─ DenyList           → Prohibited keywords → blocked
     ↓
Only safe results reach the agent

GDPR, HIPAA, SOC 2 — compliance is enforced at the infrastructure layer, not in application code.

3. Isolates Teams with Multi-Tenancy

Different teams see different tools, enforced by a two-layer security model:

Layer 1 — Token Scoping: Controls what you can see (data filtering)
Layer 2 — RBAC: Controls what you can do (permission checks)

HR Team Agent     → Can only access HR servers (payroll, employee DB)
Sales Team Agent  → Can only access CRM, Salesforce
Intern's Agent    → Read-only (viewer role), write/delete returns 403

Role	Can See (Token Scoping)	Can Do (RBAC)
platform_admin	Everything	Everything
team_admin	Team tools	Team management + tool execution
developer	Team tools	Tool execution
viewer	Team tools	Read only

4. Tracks Costs and Usage

ContextForge Observability:
├─ Prometheus Metrics   → Per-team, per-agent API call counts
├─ TOON Compression     → 30-70% LLM token reduction (= cost savings)
├─ Rate Limiter         → Per-team, per-user call limits
├─ Token Catalog        → Per-token quotas, expiry, usage tracking
└─ Audit Logs           → Full record of who did what, when

Finally, you can answer: "How much did AI agent operations cost this month?"

5. Deploys Like Enterprise Software

AI Platform (Cloud)
       ↓
ContextForge (OCP / K8s / Docker)
├─ Helm Charts       → Auto-scaling (HPA)
├─ PostgreSQL        → Persistent storage
├─ Redis             → Caching / sessions
├─ TLS 1.3           → End-to-end encryption
├─ NetworkPolicy     → Network isolation
└─ OAuth / SSO       → Enterprise identity (Entra, Okta, Keycloak)

By the Numbers

Metric	Value
Built-in plugins	42
Unit tests	13,755+
Code coverage	99%
Supported protocols	MCP, A2A, REST→MCP, gRPC→MCP
API endpoints	344 (OpenAPI 3.1.0)
Supported databases	SQLite, PostgreSQL, MySQL, MariaDB
Deployment options	Docker, K8s Helm, OpenShift, AWS/Azure/GCP/IBM Cloud

A Real-World Scenario

1. Employee asks AI platform:
   "Analyze last week's production incident logs"

2. AI agent calls tools through ContextForge:
   ├─ Splunk API (REST→MCP auto-convert) → Fetch logs
   ├─ Jira API → Search related issues
   └─ PagerDuty API → Retrieve incident history

3. ContextForge plugin pipeline:
   ├─ PII Filter → Mask customer PII in logs
   ├─ TOON Compression → Reduce token usage on large log data
   └─ Audit Log → Record "who accessed production logs"

4. Agent delivers safe, filtered analysis

Without vs. With

	Without ContextForge	With ContextForge
API connections	Each agent implements its own	Register once, share everywhere
Security	Handled in each agent's code	Applied uniformly at the gateway
Auditing	Build it yourself	Built-in (Prometheus + logging)
Permissions	Configure per API	Unified RBAC + token scoping
Cost tracking	Not possible	Per-team, per-token usage tracking
Adding new APIs	Modify agent code	Just register the REST/gRPC endpoint

What's Next

In Part 2, we'll get hands-on: clone the repo, start a dev server, register an MCP server, and execute tool calls — all in under 15 minutes.

In Part 3, we'll deep-dive into the 42-plugin pipeline: PII filtering, rate limiting, circuit breakers, LLM summarization, and the unique TOON compression that saves 30-70% on LLM tokens.

ContextForge is open source under Apache 2.0.

IBM / mcp-context-forge

An AI Gateway, registry, and proxy that sits in front of any MCP, A2A, or REST/gRPC APIs, exposing a unified endpoint with centralized discovery, guardrails and management. Optimizes Agent & Tool calling, and supports plugins.

ContextForge

An open source registry and proxy that federates MCP, A2A, and REST/gRPC APIs with centralized governance, discovery, and observability. Optimizes Agent & Tool calling, and supports plugins.

Tools Gateway — MCP, REST, gRPC-to-MCP translation, and TOON compression
Agent Gateway — A2A protocol, OpenAI-compatible and Anthropic agent routing
API Gateway — Rate limiting, auth, retries, and reverse proxy for REST services
Plugin Extensibility — 40+ plugins for additional transports, protocols, and integrations
Observability — OpenTelemetry tracing with Phoenix, Jaeger, Zipkin, and other OTLP backends

It runs as a fully compliant MCP server, deployable via PyPI or Docker, and scales to multi-cluster environments on Kubernetes with Redis-backed federation and caching.

Overview & Goals
Quick Start…

View on GitHub

If this resonated with you, follow this series — in Part 2, we go from zero to tool calls in 15 minutes.

DEV Community: optml

Securing AI Agents with 42 Built-in Plugins

How the Plugin Pipeline Works

Plugin Modes

The 42 Plugins at a Glance

Deep Dive: Key Plugins in Action

PII Filter — Mask Sensitive Data

DenyList — Block Prohibited Content

TOON Encoder — Save 30-70% on LLM Tokens

Rate Limiter — Per-Team, Per-User Throttling

URL Reputation — Block Malicious Endpoints

Cached Tool Results — Avoid Redundant Calls

Summarizer — LLM-Powered Response Compression

Unified PDP — Multi-Engine Policy Decisions

Running 28 Plugins Simultaneously

Observability: See Everything

Prometheus Metrics

Aggregated JSON Metrics

Tool Annotations

Enabling Plugins

Load Testing Results

Infrastructure We Verified

The Full Picture

Summary

IBM / mcp-context-forge

An AI Gateway, registry, and proxy that sits in front of any MCP, A2A, or REST/gRPC APIs, exposing a unified endpoint with centralized discovery, guardrails and management. Optimizes Agent & Tool calling, and supports plugins.

ContextForge

Table of Contents

Getting Started with ContextForge: From Zero to Tool Calls in 15 Minutes

Prerequisites

Step 1: Clone and Configure

Step 2: Install Dependencies

Step 3: Run the Tests (Optional but Recommended)

Step 4: Start the Dev Server

Step 5: Log Into the Admin UI

Step 6: Generate a JWT Token

Step 7: Register an MCP Server

Step 8: Discover Tools

Step 9: Execute a Tool Call

Step 10: Explore the Admin Dashboard

Step 11: Check the API Docs

What We Just Did

Bonus: HTTPS in 30 Seconds

Bonus: PostgreSQL Backend

What's Next

IBM / mcp-context-forge

An AI Gateway, registry, and proxy that sits in front of any MCP, A2A, or REST/gRPC APIs, exposing a unified endpoint with centralized discovery, guardrails and management. Optimizes Agent & Tool calling, and supports plugins.

ContextForge

Table of Contents

Why You Need an MCP Gateway for Enterprise AI Agents

The Problem: AI Agents Without Guard Rails

The Solution: Put a Gateway in the Middle

What ContextForge Actually Does

1. Turns Your Existing APIs into AI Tools — Automatically

2. Prevents Data Leaks at the Gateway Level

3. Isolates Teams with Multi-Tenancy

4. Tracks Costs and Usage

5. Deploys Like Enterprise Software

By the Numbers

A Real-World Scenario

Without vs. With

What's Next

IBM / mcp-context-forge

An AI Gateway, registry, and proxy that sits in front of any MCP, A2A, or REST/gRPC APIs, exposing a unified endpoint with centralized discovery, guardrails and management. Optimizes Agent & Tool calling, and supports plugins.

ContextForge

Table of Contents