Connecting a client

Every MCP client launches the server the same way — as a subprocess, given a command and an env block — so the setup has the same shape everywhere; only the config file's location and format differ per client.

You'll need two things from Installation & configuration:

• the full path to ydata-mcp-server in the environment you installed into;
• the path to your connections file (and, if you use the LLM-backed tools, your LLM provider file).

Claude DesktopClaude CodeCursor & other clients

Edit the config file — macOS: ~/Library/Application Support/Claude/claude_desktop_config.json, Windows: %APPDATA%\Claude\claude_desktop_config.json — adding a ydata entry under mcpServers (alongside any servers already there):

{
  "mcpServers": {
    "ydata": {
      "command": "/path/to/env/bin/ydata-mcp-server",
      "env": {
        "YDATA_MCP_CONNECTIONS": "/path/to/connections.json",
        "YDATA_MCP_LLM_CONFIG": "/path/to/llm_config.json"
      }
    }
  }
}

YDATA_MCP_LLM_CONFIG is only needed for the LLM-backed tools — omit it otherwise.

Fully quit Claude Desktop (Cmd+Q on macOS — closing the window is not enough) and reopen it.

Register the server with claude mcp add (note the -- — everything after it is the server's own command line):

claude mcp add --transport stdio ydata \
  --env YDATA_MCP_CONNECTIONS=/path/to/connections.json \
  --env YDATA_MCP_LLM_CONFIG=/path/to/llm_config.json \
  -- /path/to/env/bin/ydata-mcp-server

This defaults to --scope local (private to you, current project only). Add --scope user to make it available across all your projects, or --scope project to save it to a version-controlled .mcp.json for your team — .mcp.json uses the same command/env shape as Claude Desktop's config, so hand-editing it works too.

Look for an MCP Servers section in the client's settings — it takes the same command/args/env shape. Point command at the ydata-mcp-server path and set YDATA_MCP_CONNECTIONS (and optionally YDATA_MCP_LLM_CONFIG) in env, exactly as in the Claude Desktop example.

Restart after config changes

Every client needs a restart (or its MCP servers reloaded) after a config change to pick up a newly added server.

Verify the connection

Ask the client something like:

"What tools does the ydata MCP server give you?"

It should list tools such as list_connections, browse_rdbms, profile_dataset, and train_regular_synthesizer. Then try a real call:

"List the configured connections and test the warehouse one."

A typical session

Once connected, workflows chain naturally — the client picks the tools:

1. Explore — browse_rdbms / browse_object_storage to see what data exists; get_rdbms_table_schema for column detail.
2. Understand — profile_dataset (directly against a connection table, an uploaded file, or a local path) for a full HTML profiling report plus inline data-quality alerts.
3. Synthesize — train_regular_synthesizer on the same source, then sample_regular_synthesizer for as many synthetic rows as needed.
4. Validate — compare_profiles with the original table and the synthetic sample side by side.
5. Deliver — write_rdbms_table / write_object_storage_file to push the synthetic data where it needs to go, or download_file to pull a report or sample back through the conversation.

Heavy steps (reads, training, sampling, profiling) return a job_id immediately and the client polls get_job_status until they finish — see Tools & resources for the contract.