When a project is connected to an MDS environment, agents working in that project automatically see a large catalog of mds__* tools through the meshly-build MCP server. They can call them like any other MCP tool — no extra setup on Build Station's side.
Tools group naturally by the service they target. You don't need to memorize them; the agent does, and you can browse the full list from the dashboard.
Service groups
-
Data lake & query: Trino, Postgres, Superset, Schema Registry — read and query structured data, manage schemas.
-
Streaming: Kafka, Kafka Connect, CDC, Faust — topics, consumers, connectors, replication slots.
-
Object & vector storage: MinIO buckets, Qdrant vector search, OpenSearch indices.
-
Workflows: Airflow DAGs, Langflow flows, LangGraph threads.
-
Observability: Grafana dashboards & alerts, Prometheus queries, container logs & resource usage.
-
Governance: Keycloak users & roles, OPA policies, OpenMetadata catalog, secrets management.
-
Versioning & catalog: Nessie branches & commits, OpenMetadata lineage, glossary, classifications.
-
Operations: Container lifecycle, dashboard health, stack status, networking & port checks.
A few representative examples
To give you a flavor — these are tools an agent might call autonomously while doing a data-related task:
| Tool | What it does |
|---|---|
mds__pg_query |
Run a SELECT against a Postgres database in the connected MDS env. |
mds__trino_query |
Federated SQL query across catalogs. |
mds__kafka_list_topics |
Enumerate Kafka topics. |
mds__kafka_produce_message |
Publish a test event to a topic. |
mds__airflow_trigger_dag |
Kick off an Airflow DAG run. |
mds__nessie_create_branch |
Create a data-lake branch (versioned tables). |
mds__openmetadata_get_lineage |
Pull lineage graph for a table. |
mds__container_logs |
Tail logs from a deployed container. |
mds__valkey_set |
Write a key/value pair to Valkey. |
There are roughly 200 tools total spanning ~25 services. The agent picks the right one for whatever you've asked it to do — you don't need to spell out which tool to use.
Targeting an environment
When the project has multiple MDS environments (e.g. dev and prod), the agent specifies which one to target as a tool argument. Your task prompt and the project context typically guide this — for example, "investigate the issue on dev" tells the agent to scope all its calls to the dev environment.
You can also configure agent role guidance on the dashboard to enforce environment safety: "this agent may only touch dev" gets honored by the agent without any code path needing to enforce it.
Authentication
All MDS calls authenticate as the running agent's identity through the meshly-build MCP server. The backend holds the actual MDS credentials and uses them when proxying; nothing sensitive transits through Build Station or appears in your local config.
Tool availability vs project's environments
A project might have 0, 1, or many environments connected. Tools always exist (the catalog is universal) — what changes is which environments they can be pointed at.
If an agent tries to call mds__pg_query for a project with no MDS environments connected, the backend returns an error telling the agent which environments are available (zero, in this case) and the agent reports back that the tool wasn't applicable.
Where to learn more
The full tool catalog with parameter signatures lives on the Meshly Build dashboard under workspace settings → MCP catalog. Build Station doesn't surface it directly — the dashboard is the right place to browse capabilities your agents have.