Model Context Protocol (MCP)¶

The Model Context Protocol enables LLMs to interact with external tools, data sources, and services through a standardized interface. SMG acts as an MCP client, connecting models to MCP servers on their behalf.

Overview¶

How It Works¶

SMG's MCP Orchestrator manages all interactions between LLM workers and external MCP servers.

Request Flow¶

1. LLM Worker generates a tool call (e.g., web_search)
2. Tool Inventory resolves the qualified name (brave:web_search)
3. Policy Engine evaluates trust level and approval rules
4. Connection Pool provides an authenticated connection
5. MCP Server executes the tool and returns results
6. Transformer converts the response to OpenAI format

Approval System¶

SMG's approval system provides fine-grained control over tool execution—critical for enterprise deployments.

Trust Levels¶

Each MCP server can be assigned a trust level that determines default behavior:

Policy Evaluation¶

Policies are evaluated in order of specificity:

1. Explicit tool policy — brave:delete_data → deny
2. Server policy + trust level — brave → trusted
3. Default policy — allow

Example Policy Configuration¶

policy:
  default: allow

  servers:
    brave:
      trust_level: trusted
    internal-tools:
      trust_level: standard
      default: allow
    external-api:
      trust_level: untrusted
      default: deny

  tools:
    "internal-tools:delete_all": deny
    "external-api:execute_code":
      deny_with_reason: "Code execution not allowed"

Transport Types¶

MCP supports multiple transport protocols:

Response Transformation¶

SMG transforms MCP responses to OpenAI-compatible formats:

Tool Configuration¶

Configure response formats and argument mappings per tool:

servers:
  - name: brave
    protocol: sse
    url: "https://mcp.brave.com/sse"
    token: "${BRAVE_API_KEY}"

    tools:
      brave_web_search:
        alias: web_search              # LLM sees "web_search"
        response_format: web_search_call
        arg_mapping:
          renames:
            q: query                   # Rename arguments
          defaults:
            count: 10                  # Default values

Configuration¶

CLI Option¶

smg --worker-urls http://localhost:8000 --mcp-config-path /etc/smg/mcp.yaml

Configuration File¶

# Static MCP servers (connected at startup)
servers:
  - name: brave
    protocol: sse
    url: "https://mcp.brave.com/sse"
    token: "${BRAVE_API_KEY}"
    required: true

  - name: filesystem
    protocol: stdio
    command: "npx"
    args: ["-y", "@anthropic/mcp-server-filesystem", "/workspace"]

# Connection pool for dynamic servers
pool:
  max_connections: 100
  idle_timeout: 300

# Tool inventory settings
inventory:
  enable_refresh: true
  tool_ttl: 300
  refresh_interval: 60

# Approval policy
policy:
  default: allow
  servers:
    brave:
      trust_level: trusted

Environment Variable Expansion¶

Tokens support ${VAR_NAME} syntax to keep credentials out of config files:

token: "${BRAVE_API_KEY}"

Static vs Dynamic Servers¶

SMG supports two connection models:

Connection Pool Performance¶

Multi-Tenant Patterns¶

SMG supports sophisticated multi-tenant deployments with tenant-isolated connections:

Security Model¶

Key principle: Models and clients never have direct access to internal systems. All access is mediated through SMG and MCP servers.

Qualified Tool Names¶

Multiple MCP servers can expose tools with the same name. SMG uses qualified names to prevent collisions:

server-a:run_query    # Different from
server-b:run_query    # Same tool name, different servers

Tool aliases can provide simpler names to the LLM while maintaining qualified routing internally.

Troubleshooting¶

What's Next?¶