MDS environments

The Meshly Data Stack (MDS) is the data platform that ships alongside Meshly Build. When a project is connected to an MDS environment, its agents can interact with that environment's services — query databases, run jobs, inspect deploys, read logs — all through the agent's existing MCP connection.

What an MDS environment is

A named connection to a deployed MDS stack — typically one per environment per customer:

• dev — development MDS, lots of churn, low-stakes data.
• prod — production MDS, real customer data, tight access controls.

Each environment has a unique URL and credentials managed centrally on the backend.

How environments get added to a project

This is done on the Meshly Build dashboard side, not in Build Station:

1. Workspace admin connects MDS environments

On the workspace settings page, admins register one or more MDS connections — each with a name, URL, and API credentials.

2. Project owner attaches an environment

Open the project on the dashboard → settings → MDS environments. Pick one or more environments from the connected list.

3. Build Station picks it up on next resync

Either auto on launch or via the project's Resync button. The environment's tools become available to agents working in that project.

How Build Station handles MDS environments

The backend proxies all MDS tool traffic through the meshly-build MCP server. Build Station's job is small:

• Fetch the project's environment list from the backend during resync.
• Record them (purely informational — the actual routing happens server-side).
• Do not write per-environment MCP entries into the project's .mcp.json. Agents reach MDS through the existing meshly-build MCP server, not through direct connections.

Note: Proxy-first architecture

Earlier versions of Build Station wrote direct-connect MCP entries (one per environment) into the project's .mcp.json. That was deprecated when the backend grew its own MCP proxy: now agents authenticate once to meshly-build and that server fans out to MDS environments using server-stored credentials. Your local .mcp.json stays clean.

Which environment an agent operates on

When an agent calls an MDS tool, it specifies the environment as a tool argument. The backend routes the call to the right MDS stack. Tools are namespaced by the underlying service (mds__pg_query, mds__trino_query, mds__kafka_list_topics, etc.) but the same tool can target any of the project's connected environments.

The agent's prompt and project context typically tell it which environment to use for each task — e.g., "run this against dev, not prod".

Verifying which environments a project has connected

Two places to look:

• The dashboard is the source of truth. Project settings → MDS environments.
• Build Station displays the connected environments in the project detail panel under MDS environments. If the list looks stale, click Resync.

Removing an MDS environment

Remove it on the dashboard. The next resync drops it from the local view too. In-flight agents on that environment keep working until their task completes; new tasks won't see the removed environment in their available tools.

What if you're not using MDS?

You can ignore everything in this section. Build Station works perfectly well without any MDS environments configured — agents just don't get the mds__* tool set, which is fine if your work doesn't touch the data platform.

Next

• MDS tools available to agents: The full catalog of services and operations agents can perform via the MDS proxy.