MCPico

MCP proxy that bundles flat tool lists into hierarchical groups with separate discovery and execution.

MCPico (MCP + "ico" = tiny) wraps upstream MCP servers, grouping their tools into discoverable groups. Each group gets a help_<group> discovery tool (auto-generated docs from upstream schemas) and a <group> execution tool. LLM benchmarks show 43–60% fewer conversation tokens while matching flat tool success rates.

The Problem

MCP servers expose tools as a flat list. Every tool costs context tokens. A filesystem server exposes 14+ separate tools — the model sees all of them, all the time, even when it only needs one.

Some clients add "tool search" as a workaround. But searching requires the model to proactively look for tools it doesn't know exist. No structural signal about which tools relate to each other.

Related MCP server: MCP Gateway

MCPico's Solution

Group related tools under a single entry point. The model sees groups instead of raw tools. Discovery is separated from execution:

Model calls: help_postgres → sees available tools
Model calls: postgres_query {"sql":"SELECT ..."} → executes

Quantified: 43–60% fewer conversation tokens

See BENCHMARK.md for a full LLM evaluation comparing flat tools (45 tools, 5 servers), MCPico merged mode, and MCPico split mode across Qwen3.5-9B and Qwen3.6-35B.

Key results:

• MCPico split matches flat tool success rates on both models (2/3 tasks)

• 60% token reduction on 9B model (14,027 vs 34,760 tokens across all tasks)

• 43% token reduction on single-tool tasks with the 35B model

Features

• Tool bundling — Groups tools by prefix (configurable separator), collapsing flat tool lists into 10 tools instead of 45+

• Split discovery/execution — Separate help_<group> tools for discovery, <group> tools for execution. LLM-optimized design

• Auto-generated help — help_<group> tools dynamically generate rich documentation from upstream schemas

• Multi-server aggregation — Proxy multiple upstream MCP servers through one interface

• Dual upstream transport — Supports both stdio and Streamable HTTP (SSE) upstream servers

• Dual listen transport — MCPico itself listens via stdio or HTTP/SSE (configurable port)

• Configurable timeouts — Per-server connection timeout with sensible default (30s)

• Resource & prompt passthrough — Namespaced to avoid collisions across servers

• Authentication — Bearer, custom header, and OAuth2 client_credentials with automatic token refresh

• Listen endpoint auth — Protect the SSE endpoint with bearer token validation

Usage

Install

npm install -g mcpico

Configure

Create mcpico.json:

{
  "servers": [
    {
      "name": "filesystem",
      "transport": {
        "type": "stdio",
        "command": "npx",
        "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"]
      }
    }
  ]
}

Run

mcpico

Connect your MCP client

Add MCPico as a server in your MCP client config:

{
  "mcpServers": {
    "mcpico": {
      "command": "mcpico",
      "args": ["--config", "/path/to/mcpico.json"]
    }
  }
}

How it works

1. Connect to upstream MCP servers

2. Discover their tools (tools/list)

3. Group tools by prefix (configurable separator, default _)

   • filesystem_read_file, filesystem_write_file → group filesystem

4. Register two tools per group:

   • help_<group> — discovery: lists all subcommands with their parameters

   • <group> — execution: takes subcommand + params, forwards to upstream

5. Forward tool calls directly to the matching upstream server

6. Generate help dynamically from original tool schemas

Tool interface

help_postgres          ← call with no arguments to discover
postgres               ← call with subcommand: "postgres_query", params: {sql: "..."}

Multi-server aggregation

MCPico can proxy multiple upstream servers simultaneously:

{
  "servers": [
    {
      "name": "filesystem",
      "transport": {
        "type": "stdio",
        "command": "npx",
        "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"]
      }
    },
    {
      "name": "github",
      "transport": {
        "type": "sse",
        "url": "https://mcp-github.example.com/mcp"
      }
    }
  ]
}

Groups from different servers are merged if they share a prefix. Otherwise each server's tools appear as separate groups.

Configuration

ListenConfig

// SSE listen mode — MCPico as an HTTP endpoint
{
  "servers": [...],
  "listen": {
    "type": "sse",
    "port": 3000
  }
}

ServerConfig

TransportConfig (stdio)

TransportConfig (SSE / Streamable HTTP)

Authentication

MCPico supports two layers of authentication:

Layer 1: Protecting the listen endpoint

When MCPico exposes an SSE endpoint, you can require a bearer token from clients:

{
  "servers": [...],
  "listen": {
    "type": "sse",
    "port": 3000,
    "auth": {
      "type": "bearer",
      "token": "${MCPICO_API_KEY}"
    }
  }
}

Clients must include Authorization: Bearer <token> in requests. Invalid or missing tokens receive a 401 response.

Layer 2: Authenticating to upstream servers

Upstream servers can require authentication. MCPico supports three methods:

Bearer token — standard Authorization: Bearer <token> header:

{
  "servers": [
    {
      "name": "internal-api",
      "transport": {
        "type": "sse",
        "url": "https://api.internal/mcp"
      },
      "auth": {
        "type": "bearer",
        "token": "${INTERNAL_KEY}"
      }
    }
  ]
}

Custom header — arbitrary headers (e.g. X-API-Key):

{
  "auth": {
    "type": "header",
    "name": "X-API-Key",
    "value": "${WIDGET_KEY}"
  }
}

OAuth 2.0 client credentials — machine-to-machine authentication with automatic token refresh:

{
  "auth": {
    "type": "oauth",
    "grant_type": "client_credentials",
    "client_id": "${PROVIDER_CLIENT_ID}",
    "client_secret": "${PROVIDER_CLIENT_SECRET}",
    "token_url": "https://auth.example.com/oauth/token",
    "scopes": ["read", "write"]
  }
}

MCPico handles the full OAuth flow:

• Fetches initial access token on startup

• Caches tokens in ~/.mcplico/credentials.json

• Automatically refreshes before expiry

• Retries on 401 with fresh tokens

All auth fields support ${ENV_VAR} interpolation — never hardcode secrets.

Auth config reference

Development

Development

npm install
npm run build    # TypeScript compilation
npm test         # Run tests (138 tests, vitest)
npm run dev      # Run directly with tsx

License

MIT