Course overview/Foundations4 of 4

Using agents and Bruin MCP safely

Back to course

Foundations - Step 4 of 14

Using agents and Bruin MCP safely

Use agents with a clear scope and a verification step.

What MCP changes

Bruin MCP lets a compatible coding assistant use configured Bruin tools and project context. It can help an agent inspect a project, explain a model, draft a change, or show what a command would do.

It does not remove the need to decide what the agent may access or change. A useful default is to let the agent read, explain, and draft first. Run write operations only after a person reviews the proposed change.

Glossary

  • MCP server is a service that gives an assistant access to defined tools and context. The available tools depend on the MCP server and its configuration.
  • Tool call is an action the assistant asks a connected tool to perform, such as reading a file, rendering an asset, or running a command. Treat a tool call with write access like any other automated change.
  • Context is the information an agent receives about the task, project, model, and environment. Better context makes the answer more specific, but it should not include secrets or unnecessary production data.
  • Scope is the boundary of the task. A good scope names the target model, environment, files, and the work the agent is allowed to perform.
  • Read access lets an agent inspect code, configuration, or metadata. It is usually a safer starting point than permission to change data or files.
  • Write access lets an agent create or modify files, tables, or other state. Give it only when the target and expected result are clear.
  • Verification is the evidence required before accepting the change. For a model, that usually includes rendered SQL, a focused run, and checks at the intended grain.

Give the agent a bounded task

Avoid requests such as "fix revenue". They leave the grain, target table, allowed environment, and review step unspecified.

Use a request that states the expected output and the boundary:

Goal: add a daily customer revenue model
Grain: one row per customer per calendar day
Scope: development environment and files under assets/
Before running: render the SQL and explain the join keys
Verification: validate, run one date, inspect duplicate customer-day rows

Review generated work before you run it

  • Check that joins preserve the stated grain.
  • Check that date filters cover the intended interval.
  • Check that the materialization matches how source records change.
  • Read the rendered SQL or Python output.
  • Run checks and inspect a small result set before relying on the output.

Sign up to our newsletter

Practical updates on open-source data pipelines, AI analysts, governance, and what we are shipping at Bruin.