Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/math-inc/OpenGauss/llms.txt

Use this file to discover all available pages before exploring further.

The Model Context Protocol (MCP) is an open standard for connecting AI agents to external tools, data sources, and services. An MCP server exposes a set of tools, resources, and prompts over a well-defined wire protocol; an MCP client like OpenGauss connects to those servers and makes their capabilities available to the agent. OpenGauss ships a native MCP client with support for both stdio and HTTP transports, automatic reconnection, resource and prompt discovery, and server-initiated LLM sampling.

What OpenGauss’s MCP client supports

  • stdio and HTTP transports — connect to local processes via standard I/O or to remote servers over HTTP/SSE.
  • Automatic reconnection — if an MCP server process exits or the connection drops, Gauss retries automatically.
  • Resource and prompt discovery — agents can browse resources and prompt templates exposed by MCP servers without extra configuration.
  • Sampling (server-initiated LLM requests) — MCP servers can request LLM completions from Gauss; these requests are routed through the auxiliary model configuration.
  • Security hardening — connection and tool-call boundaries are enforced; MCP servers cannot access resources outside what their manifest declares.
  • gauss tools integration — MCP servers appear as toggleable items alongside built-in tools.
  • /reload-mcp command — reload MCP server configuration at runtime without restarting Gauss.

Configuring MCP servers

MCP servers are declared in ~/.gauss/config.yaml under the mcp_servers key. The value is a mapping where each key is the server name and the value is the server configuration. Each entry needs either a command (for stdio) or a url (for HTTP).

stdio transport

For servers that run as local processes, provide command and optionally args:
mcp_servers:
  my-server:
    command: uvx
    args:
      - my-mcp-server

  filesystem-server:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-filesystem"
      - "/home/user/projects"
The command is resolved against your PATH. Gauss spawns the process and communicates over stdin/stdout using the MCP wire protocol.

HTTP transport

For servers accessible over a network (local or remote), provide a url:
mcp_servers:
  remote-server:
    url: https://my-server.example.com/mcp
    headers:
      Authorization: "Bearer sk-..."

  local-http-server:
    url: http://localhost:3000/mcp
HTTP transport uses Server-Sent Events (SSE) for streaming responses.

Multiple servers

You can configure as many servers as you need. All configured servers are connected at startup and their tools are merged into the agent’s available tool set:
mcp_servers:
  lean-lsp:
    command: uvx
    args:
      - lean-lsp-mcp

  filesystem:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-filesystem"
      - "."

  remote-knowledge:
    url: https://knowledge.example.com/mcp

Reloading MCP config at runtime

After adding or changing an MCP server entry in config.yaml, you don’t need to restart Gauss. Run /reload-mcp from the interactive CLI to reconnect to all configured servers with the updated configuration:
/reload-mcp
Add a new MCP server to config.yaml, save the file, then run /reload-mcp in your open Gauss session. The new server’s tools appear immediately without interrupting any in-progress work.

Managing MCP servers with gauss tools

The gauss tools interactive UI shows MCP servers alongside built-in tool categories. You can toggle individual MCP servers on or off per platform from this interface:
gauss tools
This is especially useful in gateway mode, where you may want certain MCP servers available in the CLI but not exposed to messaging-platform users.

Resource and prompt discovery

MCP servers can expose resources (files, documents, database records) and prompt templates alongside tools. OpenGauss agents can browse these through the MCP protocol:
  • Resources are listed and can be read by the agent during a task, similar to how the file-reading tool works.
  • Prompt templates surface as ready-made conversation starters or structured workflows that the agent can invoke by name.
No extra configuration is needed — if a connected MCP server exposes resources or prompts, they are automatically available to the agent.

Sampling: server-initiated LLM requests

Some MCP servers request LLM completions from the client as part of their operation. For example, an MCP server might ask the agent to summarize a resource or classify a result. OpenGauss routes these sampling requests through the auxiliary.mcp model configuration:
auxiliary:
  mcp:
    provider: auto           # auto | openrouter | custom
    model: ""                # leave empty to use provider default
    base_url: ""             # point at a local endpoint for on-premise sampling
    api_key: ""              # API key if base_url requires one
Setting auxiliary.mcp.base_url to a local vLLM endpoint keeps all MCP sampling on-premise, independent of your primary model provider.

The lean-lsp-mcp server

When you run any managed Lean workflow command (/prove, /formalize, /autoprove, etc.), OpenGauss automatically stages and starts a lean-lsp-mcp server scoped to your active Lean project. This server provides the backend agent with Lean LSP tools — go-to-definition, hover, diagnostics, completion — without requiring you to configure it manually.
The Lean LSP MCP server is started automatically by managed workflow commands and should not be added to mcp_servers in your config for normal use. If you need to override the server spec (for example, to pin a specific version), set the GAUSS_AUTOFORMALIZE_LEAN_LSP_MCP_SPEC environment variable:
# ~/.gauss/.env
GAUSS_AUTOFORMALIZE_LEAN_LSP_MCP_SPEC=lean-lsp-mcp==0.3.1

Gateway and MCP

In gateway mode, Gauss shuts down all MCP server connections cleanly when the gateway process exits. If the gateway is restarted (for example by systemd), MCP servers are reconnected on startup. The /reload-mcp command is also available inside gateway sessions.

Build docs developers (and LLMs) love