Skip to main content
Glama
feiskyer

MCP AI Hub

by feiskyer
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

MCP AI Hub

Python License Code style: black Ruff PyPI Downloads

A Model Context Protocol (MCP) server that provides unified access to various AI providers through LiteLM. Chat with OpenAI, Anthropic, and 100+ other AI models using a single, consistent interface.

🌟 Overview

MCP AI Hub acts as a bridge between MCP clients (like Claude Desktop/Code) and multiple AI providers. It leverages LiteLM's unified API to provide seamless access to 100+ AI models without requiring separate integrations for each provider.

Key Benefits:

  • Unified Interface: Single API for all AI providers

  • 100+ Providers: OpenAI, Anthropic, Google, Azure, AWS Bedrock, and more

  • MCP Protocol: Native integration with Claude Desktop and Claude Code

  • Flexible Configuration: YAML-based configuration with Pydantic validation

  • Multiple Transports: stdio, SSE, and HTTP transport options

  • Custom Endpoints: Support for proxy servers and local deployments

Related MCP server: MCP AI Gateway

Quick Start

1. Install

Choose your preferred installation method:

# Option A: Install from PyPI
pip install mcp-ai-hub

# Option B: Install with uv (recommended)
uv tool install mcp-ai-hub

# Option C: Install from source
pip install git+https://github.com/your-username/mcp-ai-hub.git

Installation Notes:

  • uv is a fast Python package installer and resolver

  • The package requires Python 3.10 or higher

  • All dependencies are automatically resolved and installed

2. Configure

Create a configuration file at ~/.ai_hub.yaml with your API keys and model configurations:

model_list:
  - model_name: gpt-4  # Friendly name you'll use in MCP tools
    litellm_params:
      model: openai/gpt-4  # LiteLM provider/model identifier
      api_key: "sk-your-openai-api-key-here"  # Your actual OpenAI API key
      max_tokens: 2048  # Maximum response tokens
      temperature: 0.7  # Response creativity (0.0-1.0)

  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20241022
      api_key: "sk-ant-your-anthropic-api-key-here"
      max_tokens: 4096
      temperature: 0.7

Configuration Guidelines:

  • API Keys: Replace placeholder keys with your actual API keys

  • Model Names: Use descriptive names you'll remember (e.g., gpt-4, claude-sonnet)

  • LiteLM Models: Use LiteLM's provider/model format (e.g., openai/gpt-4, anthropic/claude-3-5-sonnet-20241022)

  • Parameters: Configure max_tokens, temperature, and other LiteLM-supported parameters

  • Security: Keep your config file secure with appropriate file permissions (chmod 600)

3. Connect to Claude Desktop

Configure Claude Desktop to use MCP AI Hub by editing your configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "ai-hub": {
      "command": "mcp-ai-hub"
    }
  }
}

4. Connect to Claude Code

claude mcp add -s user ai-hub mcp-ai-hub

Advanced Usage

CLI Options and Transport Types

MCP AI Hub supports multiple transport mechanisms for different use cases:

Command Line Options:

# Default stdio transport (for MCP clients like Claude Desktop)
mcp-ai-hub

# Server-Sent Events transport (for web applications)
mcp-ai-hub --transport sse --host 0.0.0.0 --port 3001

# Streamable HTTP transport (for direct API calls)
mcp-ai-hub --transport http --port 8080

# Custom config file and debug logging
mcp-ai-hub --config /path/to/config.yaml --log-level DEBUG

Transport Type Details:

Transport

Use Case

Default Host:Port

Description

stdio

MCP clients (Claude Desktop/Code)

N/A

Standard input/output, default for MCP

sse

Web applications

localhost:3001

Server-Sent Events for real-time web apps

http

Direct API calls

localhost:3001 (override with --port)

HTTP transport with streaming support

CLI Arguments:

  • --transport {stdio,sse,http}: Transport protocol (default: stdio)

  • --host HOST: Host address for SSE/HTTP (default: localhost)

  • --port PORT: Port number for SSE/HTTP (default: 3001; override if you need a different port)

  • --config CONFIG: Custom config file path (default: ~/.ai_hub.yaml)

  • --log-level {DEBUG,INFO,WARNING,ERROR}: Logging verbosity (default: INFO)

Usage

Once MCP AI Hub is connected to your MCP client, you can interact with AI models using these tools:

MCP Tool Reference

Primary Chat Tool:

chat(model_name: str, message: str | list[dict]) -> str

  • model_name: Name of the configured model (e.g., "gpt-4", "claude-sonnet")

  • message: String message or OpenAI-style message list

  • Returns: AI model response as string

Model Discovery Tools:

list_models() -> list[str]

  • Returns: List of all configured model names

get_model_info(model_name: str) -> dict

  • model_name: Name of the configured model

  • Returns: Model configuration details including provider, parameters, etc.

Configuration

MCP AI Hub supports 100+ AI providers through LiteLM. Configure your models in ~/.ai_hub.yaml with API keys and custom parameters.

System Prompts

You can define system prompts at two levels:

  • global_system_prompt: Applied to all models by default

  • Per-model system_prompt: Overrides the global prompt for that model

Precedence: model-specific prompt > global prompt. If a model's system_prompt is set to an empty string, it disables the global prompt for that model.

global_system_prompt: "You are a helpful AI assistant. Be concise."

model_list:
  - model_name: gpt-4
    system_prompt: "You are a precise coding assistant."
    litellm_params:
      model: openai/gpt-4
      api_key: "sk-your-openai-api-key"

  - model_name: claude-sonnet
    # Empty string disables the global prompt for this model
    system_prompt: ""
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20241022
      api_key: "sk-ant-your-anthropic-api-key"

Notes:

  • The server prepends the configured system prompt to the message list it sends to providers.

  • If you pass an explicit message list that already contains a system message, both system messages will be included in order (configured prompt first).

Supported Providers

Major AI Providers:

  • OpenAI: GPT-4, GPT-3.5-turbo, GPT-4-turbo, etc.

  • Anthropic: Claude 3.5 Sonnet, Claude 3 Haiku, Claude 3 Opus

  • Google: Gemini Pro, Gemini Pro Vision, Gemini Ultra

  • Azure OpenAI: Azure-hosted OpenAI models

  • AWS Bedrock: Claude, Llama, Jurassic, and more

  • Together AI: Llama, Mistral, Falcon, and open-source models

  • Hugging Face: Various open-source models

  • Local Models: Ollama, LM Studio, and other local deployments

Configuration Parameters:

  • api_key: Your provider API key (required)

  • max_tokens: Maximum response tokens (optional)

  • temperature: Response creativity 0.0-1.0 (optional)

  • api_base: Custom endpoint URL (for proxies/local servers)

  • Additional: All LiteLM-supported parameters

Configuration Examples

Basic Configuration:

global_system_prompt: "You are a helpful AI assistant. Be concise."

model_list:
  - model_name: gpt-4
    system_prompt: "You are a precise coding assistant."  # overrides global
    litellm_params:
      model: openai/gpt-4
      api_key: "sk-your-actual-openai-api-key"
      max_tokens: 2048
      temperature: 0.7

  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20241022
      api_key: "sk-ant-your-actual-anthropic-api-key"
      max_tokens: 4096
      temperature: 0.7

Custom Parameters:

model_list:
  - model_name: gpt-4-creative
    litellm_params:
      model: openai/gpt-4
      api_key: "sk-your-openai-key"
      max_tokens: 4096
      temperature: 0.9  # Higher creativity
      top_p: 0.95
      frequency_penalty: 0.1
      presence_penalty: 0.1

  - model_name: claude-analytical
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20241022
      api_key: "sk-ant-your-anthropic-key"
      max_tokens: 8192
      temperature: 0.3  # Lower creativity for analytical tasks
      stop_sequences: ["\n\n", "Human:"]

Local LLM Server Configuration:

model_list:
  - model_name: local-llama
    litellm_params:
      model: openai/llama-2-7b-chat
      api_key: "dummy-key"  # Local servers often accept any API key
      api_base: "http://localhost:8080/v1"  # Local OpenAI-compatible server
      max_tokens: 2048
      temperature: 0.7

For more providers, please refer to the LiteLLM docs: https://docs.litellm.ai/docs/providers.

Development

Setup:

# Install all dependencies including dev dependencies
uv sync

# Install package in development mode
uv pip install -e ".[dev]"

# Add new runtime dependencies
uv add package_name

# Add new development dependencies
uv add --dev package_name

# Update dependencies
uv sync --upgrade

Running and Testing:

# Run the MCP server
uv run mcp-ai-hub

# Run with custom configuration
uv run mcp-ai-hub --config ./custom_config.yaml --log-level DEBUG

# Run with different transport
uv run mcp-ai-hub --transport sse --port 3001

# Run tests (when test suite is added)
uv run pytest

# Run tests with coverage
uv run pytest --cov=src/mcp_ai_hub --cov-report=html

Code Quality:

# Format code with ruff
uv run ruff format .

# Lint code
uv run ruff check .

# Type checking with mypy
uv run mypy src/

# Run all quality checks
uv run ruff format . && uv run ruff check . && uv run mypy src/

Troubleshooting

Configuration Issues

Configuration File Problems:

  • File Location: Ensure ~/.ai_hub.yaml exists in your home directory

  • YAML Validity: Validate YAML syntax using online validators or python -c "import yaml; yaml.safe_load(open('~/.ai_hub.yaml'))"

  • File Permissions: Set secure permissions with chmod 600 ~/.ai_hub.yaml

  • Path Resolution: Use absolute paths in custom config locations

Configuration Validation:

  • Required Fields: Each model must have model_name and litellm_params

  • API Keys: Verify API keys are properly quoted and not expired

  • Model Formats: Use LiteLM-compatible model identifiers (e.g., openai/gpt-4, anthropic/claude-3-5-sonnet-20241022)

API and Authentication Errors

Authentication Issues:

  • Invalid API Keys: Check for typos, extra spaces, or expired keys

  • Insufficient Permissions: Verify API keys have necessary model access permissions

  • Rate Limiting: Monitor API usage and implement retry logic if needed

  • Regional Restrictions: Some models may not be available in all regions

API-Specific Troubleshooting:

  • OpenAI: Check organization settings and model availability

  • Anthropic: Verify Claude model access and usage limits

  • Azure OpenAI: Ensure proper resource deployment and endpoint configuration

  • Google Gemini: Check project setup and API enablement

MCP Connection Issues

Server Startup Problems:

  • Port Conflicts: Use different ports for SSE/HTTP transports if defaults are in use

  • Permission Errors: Ensure executable permissions for mcp-ai-hub command

  • Python Path: Verify Python environment and package installation

Client Configuration Issues:

  • Command Path: Ensure mcp-ai-hub is in PATH or use full absolute path

  • Working Directory: Some MCP clients require specific working directory settings

  • Transport Mismatch: Use stdio transport for Claude Desktop/Code

Performance and Reliability

Response Time Issues:

  • Network Latency: Use geographically closer API endpoints when possible

  • Model Selection: Some models are faster than others (e.g., GPT-3.5 vs GPT-4)

  • Token Limits: Large max_tokens values can increase response time

Reliability Improvements:

  • Retry Logic: Implement exponential backoff for transient failures

  • Timeout Configuration: Set appropriate timeouts for your use case

  • Health Checks: Monitor server status and restart if needed

  • Load Balancing: Use multiple model configurations for redundancy

License

MIT License - see LICENSE file for details.

Contributing

We welcome contributions! Please follow these guidelines:

Development Workflow

  1. Fork and Clone: Fork the repository and clone your fork

  2. Create Branch: Create a feature branch (git checkout -b feature/amazing-feature)

  3. Development Setup: Install dependencies with uv sync

  4. Make Changes: Implement your feature or fix

  5. Testing: Add tests and ensure all tests pass

  6. Code Quality: Run formatting, linting, and type checking

  7. Documentation: Update documentation if needed

  8. Submit PR: Create a pull request with detailed description

Code Standards

Python Style:

  • Follow PEP 8 style guidelines

  • Use type hints for all functions

  • Add docstrings for public functions and classes

  • Keep functions focused and small

Testing Requirements:

  • Write tests for new functionality

  • Ensure existing tests continue to pass

  • Aim for good test coverage

  • Test edge cases and error conditions

Documentation:

  • Update README.md for user-facing changes

  • Add inline comments for complex logic

  • Update configuration examples if needed

  • Document breaking changes clearly

Quality Checks

Before submitting a PR, ensure:

# All tests pass
uv run pytest

# Code formatting
uv run ruff format .

# Linting passes
uv run ruff check .

# Type checking passes
uv run mypy src/

# Documentation is up to date
# Configuration examples are valid

Issues and Feature Requests

  • Use GitHub Issues for bug reports and feature requests

  • Provide detailed reproduction steps for bugs

  • Include configuration examples when relevant

  • Check existing issues before creating new ones

  • Label issues appropriately

Available Tools

3 tools
chatB

Chat with specified AI model.

    Args:
        model: Model name from configuration (e.g., 'gpt-4', 'claude-sonnet-4')
        inputs: Chat input (string or OpenAI-format messages)

    Returns:
        AI model response as string
ParametersJSON Schema
NameRequiredDescriptionDefault
inputsYes
modelYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the tool chats with AI models, it doesn't describe important behavioral aspects like rate limits, authentication requirements, cost implications, error handling, or whether this is a read-only vs. state-changing operation.

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

Conciseness5/5

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

The description is perfectly structured and concise - a clear purpose statement followed by well-organized parameter explanations and return value description. Every sentence earns its place with no wasted words.

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 (interactive AI chat) and the presence of an output schema (which handles return values), the description is adequate but incomplete. It covers parameters well but lacks behavioral context that would be crucial for an AI agent to use this tool appropriately.

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

Parameters4/5

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

The description adds significant value beyond the 0% schema description coverage by explaining both parameters: 'model' is described as 'Model name from configuration' with examples, and 'inputs' is clarified as 'Chat input (string or OpenAI-format messages)'. This compensates well for the schema's lack of descriptions.

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 as 'Chat with specified AI model', which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_model_info' or 'list_models', which appear to be informational rather than interactive.

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 no guidance on when to use this tool versus alternatives. There's no mention of when to choose 'chat' over the sibling tools 'get_model_info' or 'list_models', nor any context about appropriate use cases or limitations.

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

get_model_infoC

Get information about a specific model.

    Args:
        model: Model name to get info for

    Returns:
        Dictionary with model information
ParametersJSON Schema
NameRequiredDescriptionDefault
modelYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'Get information' but doesn't clarify if this is a read-only operation, what happens if the model doesn't exist (e.g., error handling), or any rate limits or permissions required. This leaves significant gaps in understanding the tool's behavior.

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

Conciseness4/5

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

The description is appropriately sized and front-loaded, starting with the main purpose. The Args and Returns sections are structured clearly, but the formatting with indentation might be slightly verbose. Overall, it's efficient with little waste.

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 low complexity (one parameter) and the presence of an output schema, the description is somewhat complete. However, it lacks behavioral context and usage guidelines, which are important for an AI agent to invoke it correctly. The output schema helps, but the description could do more to explain the tool's role relative to siblings.

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?

The description adds minimal semantics beyond the input schema, which has 0% description coverage. It specifies that the 'model' parameter is the 'Model name to get info for', but this is basic and doesn't provide details like format, examples, or constraints. With one parameter and low schema coverage, the description compensates slightly but not fully.

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 with a specific verb ('Get') and resource ('information about a specific model'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'list_models', which might list multiple models rather than get detailed info about one.

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?

No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as whether the model must exist or be accessible, and doesn't mention sibling tools like 'list_models' for comparison or 'chat' for different operations.

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

list_modelsB

List all available AI models.

    Returns:
        List of available model names
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/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. While it states the tool lists models and returns a list of names, it doesn't describe important behavioral aspects like whether this is a read-only operation, if there are rate limits, authentication requirements, or how the list is structured (e.g., pagination, sorting). The description is minimal and lacks behavioral context.

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

Conciseness4/5

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

The description is very concise with two sentences: one stating the purpose and one describing the return value. It's front-loaded with the main action. However, the formatting with indentation and a 'Returns:' section is slightly verbose for such a simple tool, but not wasteful.

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 has 0 parameters, 100% schema coverage, and an output schema exists, the description is adequate but minimal. It covers the basic purpose and return type, but lacks context on usage guidelines and behavioral traits. For a simple list tool, this might be sufficient, but it could benefit from more guidance on when to use it versus siblings.

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

Parameters4/5

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

The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain any parameters, which is appropriate. It focuses on the return value instead, which adds value beyond the input schema.

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 with a specific verb ('List') and resource ('all available AI models'). It distinguishes from 'get_model_info' by focusing on listing all models rather than getting detailed information about a specific one. However, it doesn't explicitly differentiate from 'chat' beyond the obvious functional difference.

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 no guidance on when to use this tool versus alternatives like 'get_model_info' or 'chat'. It doesn't mention any prerequisites, context, or exclusions for usage. The agent must infer usage from the tool name and description alone.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: chat for interacting with models, get_model_info for retrieving metadata about a specific model, and list_models for enumerating available models. There is no overlap or ambiguity between these functions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (chat, get_model_info, list_models) with clear, descriptive verbs that align with their actions. No deviations or mixed conventions are present.

Tool Count3/5

With only 3 tools, the set feels thin for an AI hub server, potentially lacking operations like model configuration, session management, or advanced interactions. However, it covers basic listing, info retrieval, and chat functionality.

Completeness3/5

The tools provide core chat and model listing capabilities but have notable gaps for a full AI hub domain, such as updating model settings, managing conversations, or handling multimodal inputs. Agents can work around this but may encounter limitations.

Maintenance

ActivityInactive
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

  • Outsource MCP

    gwbischof
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that enables AI applications to access 20+ model providers (including OpenAI, Anthropic, Google) through a unified interface for text and image generation.
    2
    30
    MIT

  • MCP AI Gateway

    kinhunt
    A
    license
    B
    quality
    F
    maintenance
    Enables AI assistants to intelligently select and switch between different AI models (OpenAI, Anthropic, etc.) within the same conversation based on task requirements. Provides a unified interface for accessing multiple AI providers through a single MCP tool.
    1
    26
    MIT

  • Models PLUS

    Vivek-k3
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides comprehensive AI model metadata through MCP, enabling search and filtering of 100+ AI models by capabilities, pricing, context length, and provider specifications.
    MIT

  • Model Runner

    josephtandle
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides a unified MCP interface for running completions, embeddings, image generation, and classification across OpenAI, Anthropic, Groq, and Mistral. Eliminates provider-specific boilerplate by standardizing API calls for text generation, vector embeddings, and classification tasks.

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/feiskyer/mcp-ai-hub'

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