Overview
Oxygen’s MCP server exposes your data resources as tools that can be called by AI assistants and other MCP clients. This enables seamless integration between your structured data operations and conversational AI interfaces.Starting the MCP Server
Oxygen supports two transport options for the MCP server:SSE (Server-Sent Events)
To run the MCP SSE server use theoxy mcp sse command:
Stdio
Start the server with stdio transport:Configuring Resource Exposure
By default, Oxygen exposes all automations in your project as MCP tools. You can customize which resources are exposed by adding anmcp section to your config.yml:
.automation.yml, .procedure.yml), semantic topics (.topic.yml), and SQL files (.sql). Other files matched by a pattern are skipped.
Supported patterns:
- Direct file paths:
automations/monthly-report.automation.yml - Glob patterns:
automations/*.automation.yml,semantics/**/*.topic.yml - Multiple resource types in a single configuration
- When
mcp.toolsis defined: Only specified resources are exposed - When
mcp.toolsis omitted: All automations are exposed by default - Empty
mcp.toolslist: No tools are exposed
Agents are not exposed over MCP. To make an agent’s work available to an MCP
client, wrap it in an automation with an
agent task.Resource Types
Automations
Automations are exposed as MCP tools that run the automation and return its results. Tool naming:workflow-{name}, where {name} is the automation’s file name up to the first dot (monthly-report.automation.yml becomes workflow-monthly-report)
Input schema:
SQL Files
SQL files (.sql) can be exposed as executable tools.
Tool naming: sql-{filename_without_extension}
Input schema:
Semantic Topics
Semantic topics from your semantic model can be exposed as structured query tools. Tool naming:semantic-{topic_name}
Input schema:
Advanced Features
Session Filters
Session filters enable row-level security and data filtering across all tool types. They are passed via the_meta parameter according to the MCP specification.
Example:
- Filters are validated against your project’s filter schema (defined in
config.yml) - Invalid filter keys or types return errors before execution
- Missing required filters cause validation errors
- Missing optional filters use schema defaults
- Filters apply to all data operations within the tool execution
Connection Overrides
Connection overrides allow runtime modification of database connection parameters for multi-tenant applications or dynamic routing. Example:Variables via Meta
Variables can be passed via_meta and are merged with tool arguments using a defined precedence order.
Merging order (later overrides earlier):
- Default values from tool definition
- Variables from tool arguments
- Variables from
_meta["variables"]