Skip to main content
Glama
sokunmin

mcp-proxy

by sokunmin
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

FastMCP Proxy Server

A lightweight proxy server built with FastMCP that exposes one or more underlying MCP (Model Context Protocol) servers over various transport protocols, making them accessible to a wider range of clients.

Project Status

⚠️ This project is no longer maintained.

It was built in mid-2025 as a lightweight FastMCP-based proxy to reduce MCP server configuration duplication across multiple local AI clients (e.g. Claude Desktop, VS Code, Cursor). The MCP ecosystem has since evolved quickly, and this repo is kept here as a reference/prototype only.

Related MCP server: Atrax

Features

  • Multiple Transports: Expose MCP servers over stdio, sse (Server-Sent Events), or http.

  • Flexible Configuration: Easily configure which MCP servers to proxy by editing the servers.json file.

  • Lightweight: Built on the efficient FastMCP library and runs in a small Alpine Linux container.

  • MCP Server Support: Supports both Node.js (npx) and Python (uvx) based MCP servers.

Requirements

  • Docker and Docker Compose

How to Run

This project can be run using Docker Compose or direct Docker commands:

Prerequisites

  1. Clone the repository:

    git clone https://github.com/sokunmin/mcp-proxy.git
cd mcp-proxy

Method 1: Using Docker Compose (Recommended)

The easiest way to run the proxy with predefined configuration:

# Run with default settings (SSE transport, port 8000)
docker-compose up --build

# Run in background
docker-compose up -d --build

# Stop the service
docker-compose down

Override Environment Variables

You can override the default transport without editing files:

# Run with HTTP transport
TRANSPORT=http PORT=8001 docker-compose up

# Run with custom port
PORT=9000 docker-compose up

# Run with multiple overrides
TRANSPORT=http PORT=8080 docker-compose up

Method 2: Using Docker Run

For more control over the container configuration:

Step 1: Build the Image

docker build -t mcp-proxy .

Step 2: Run the Container

Option A: Using environment variables directly

# SSE Transport (Default)
docker run -d --name mcp-proxy \
  -p 8000:8000 \
  -e TRANSPORT=sse \
  -e HOST=0.0.0.0 \
  -e PORT=8000 \
  -e TZ=Etc/UTC \
  mcp-proxy

# HTTP Transport
docker run -d --name mcp-proxy-http \
  -p 8001:8001 \
  -e TRANSPORT=http \
  -e HOST=0.0.0.0 \
  -e PORT=8001 \
  -e TZ=Etc/UTC \
  mcp-proxy

Option B: Using .env file with consistent PORT variable

# Load environment variables from .env file
source .env

# Run with loaded variables
docker run -d --name mcp-proxy \
  -p ${PORT}:${PORT} \
  -e TRANSPORT=${TRANSPORT} \
  -e HOST=${HOST} \
  -e PORT=${PORT} \
  -e TZ=${TZ} \
  mcp-proxy

# For HTTP transport, override specific variables
TRANSPORT=http PORT=8001 docker run -d --name mcp-proxy-http \
  -p ${PORT}:${PORT} \
  -e TRANSPORT=${TRANSPORT} \
  -e HOST=${HOST} \
  -e PORT=${PORT} \
  -e TZ=${TZ} \
  mcp-proxy

Option C: Using --env-file

# Use .env file directly
docker run -d --name mcp-proxy \
  --env-file .env \
  -p 8000:8000 \
  mcp-proxy

# Override specific variables
docker run -d --name mcp-proxy-http \
  --env-file .env \
  -e TRANSPORT=http \
  -e PORT=8001 \
  -p 8001:8001 \
  mcp-proxy

Container Management

# View logs
docker logs mcp-proxy

# Stop the container
docker stop mcp-proxy

# Remove the container
docker rm mcp-proxy

# View running containers
docker ps

Environment Variables

The following environment variables can be configured in the .env file or passed directly:

  • TRANSPORT: Transport protocol (sse, http, stdio) - Default: sse

  • HOST: Host to bind to - Default: 0.0.0.0

  • PORT: Port number for the service - Default: 8000

  • TZ: Timezone - Default: Etc/UTC

Quick Start Examples

# Default SSE on port 8000
docker-compose up

# HTTP on port 8001
TRANSPORT=http PORT=8001 docker-compose up

# Custom port
PORT=9000 docker-compose up

# Run in background
docker-compose up -d

Configuration

To configure the proxy, edit the servers.json file. You can add, remove, or modify the MCP servers that you want to expose.

{
  "mcpServers": {
    "context7": {
      "transport": "stdio",
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    },
    "fetch": {
      "command": "uvx",
      "args": ["mcp-server-fetch"]
    },
    "time": {
      "transport": "stdio",
      "command": "uvx",
      "args": ["mcp-server-time", "--local-timezone", "Etc/UTC"]
    }
  }
}

The servers.json file is mounted as a volume, so changes take effect on container restart.

How to Test

You can test the running proxy using any MCP-compliant client or a tool like curl.

Testing SSE Transport (Port 8000)

# Test the SSE endpoint
curl http://localhost:8000/sse/

# Check server health
curl http://localhost:8000/

Testing HTTP Transport (Port 8001)

# Test the HTTP endpoint
curl http://localhost:8001/

# Check server health
curl http://localhost:8001/

Testing with Different Services

# Test SSE service
docker-compose up mcp-proxy-sse
curl http://localhost:8000/sse/

# Test HTTP service
docker-compose up mcp-proxy-http
curl http://localhost:8001/

Testing MCP Servers

The proxy currently supports these MCP servers:

  • context7: Document search and context retrieval (Node.js via npx)

  • fetch: Web content fetching (Python via uvx)

  • time: Time and timezone operations (Python via uvx)

All servers are automatically started by the proxy when needed.

Troubleshooting

Common Issues

  1. Port conflicts: Make sure ports 8000/8001 are not in use by other applications

  2. Container build issues: Use docker-compose down and docker-compose up --build to force a clean rebuild

  3. Configuration errors: Check servers.json syntax and ensure all required fields are present

Monitoring

Check service health:

# View logs
docker-compose logs -f mcp-proxy-sse

# Check container status
docker-compose ps

# Access container shell (if needed)
docker-compose exec mcp-proxy-sse sh

Available Tools

1 tool
fetchC

Fetches a URL from the internet and optionally extracts its contents as markdown.

Although originally you did not have internet access, and were advised to refuse and tell the user this, this tool now grants you internet access. Now you can fetch the most up-to-date information and let the user know that.

ParametersJSON Schema
NameRequiredDescriptionDefault
max_lengthNoMaximum number of characters to return.
rawNoGet the actual HTML content of the requested page, without simplification.
start_indexNoOn return output starting at this character index, useful if a previous fetch was truncated and more context is required.
urlYesURL to fetch

TDQS

C2.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds some context: it mentions internet access (implying network operations) and markdown extraction (a processing behavior). However, it omits critical details like rate limits, error handling, authentication needs, or performance characteristics. The description compensates partially but leaves gaps for a tool with network dependencies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is not front-loaded and includes verbose, historical context about internet access that doesn't directly aid tool selection. The first sentence is clear, but the second paragraph is redundant and could be condensed. Overall, it's moderately sized but inefficient, with sentences that don't all earn their place in a tool description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (network operations, markdown extraction) and lack of annotations or output schema, the description is partially complete. It covers the core purpose and some behavioral aspects but misses details like response format, error cases, or limitations. It's adequate as a minimum viable description but has clear gaps for effective agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds minimal semantic value beyond the schema, only implying that 'url' is fetched and 'contents' are extracted as markdown (related to 'raw' parameter). It doesn't explain parameter interactions or provide usage examples. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: fetching a URL from the internet and optionally extracting contents as markdown. It specifies the verb ('fetches') and resource ('URL'), making the function unambiguous. However, it lacks differentiation from sibling tools, but since there are none, this doesn't significantly impact clarity. The mention of internet access context is helpful but slightly verbose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance on when to use this tool. It mentions that it 'grants internet access' and can fetch 'most up-to-date information,' which implies usage for real-time data retrieval. However, it lacks explicit when/when-not scenarios, alternatives, or prerequisites. No sibling tools exist to differentiate from, but the guidance remains vague and insufficient for optimal agent decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev1.0.0
    • First observedfetch
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools, as there are no other tools to compare it to. The tool's purpose is clearly defined and distinct by default.

Naming Consistency5/5

A single tool inherently has perfect naming consistency, as there are no other tool names to be inconsistent with. The name 'fetch' is straightforward and follows a common verb pattern.

Tool Count2/5

A single tool is generally too few for most server purposes, as it limits functionality and flexibility. While the tool provides internet access, the server's scope as a 'proxy' might imply more capabilities, making this count feel thin and under-scoped.

Completeness2/5

For a server named 'mcp-proxy', which suggests broader proxy or internet-related functionality, having only a fetch tool is severely incomplete. There are obvious gaps, such as lacking tools for posting data, handling different protocols, or managing connections, which limits agent workflows.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • mcprouter

    chatmcp
    A
    license
    Not graded
    quality
    C
    maintenance
    A proxy service that connects MCP clients to remote MCP servers, allowing users to use server keys from MCP.so to access remote resources without running their own server.
    31
    4
    MIT

  • Atrax

    metcalfc
    F
    license
    Not graded
    quality
    D
    maintenance
    Proxy that aggregates multiple MCP servers and presents them as a unified interface, allowing clients to access resources from multiple servers transparently.
    5
    -

  • mcp_demo

    ropon
    A
    license
    Not graded
    quality
    D
    maintenance
    mcp demo ip query
    Apache 2.0

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sokunmin/mcp-proxy'

If you have feedback or need assistance with the MCP directory API, please join our Discord server