Give your AI real context.

An agent working blind is just guessing

You would not ask a new tester to find bugs without showing them the app, the spec, and where the team made its decisions. An AI agent is no different. Most disappointing AI output is not the model being weak. It is the model working blind, asked to reason about a product it has never been allowed to see. Give it what a good teammate would already have, and the quality of what comes back changes completely.

Real access does not move the judgment. It moves the grunt work. The agent reads, analyses, and drafts against your actual system. You keep the risk call, the visual sense, and the decision to ship.

What to connect, and what each one gives QA

These are real MCP servers: the sources a good teammate already has. Switch on the ones that fit your stack, starting with your code.

The repo is the one to connect first. Playwright for the running app comes a close second, because it lets the agent exercise the real UI instead of reasoning about screenshots. The rest you add as the work needs them.

Your first ten minutes

Connecting a server is a small file you commit or a single command. Here is the whole path, and what each step actually looks like on your screen.

1. 1
   Give it your code. Drop a .mcp.json file at your repo root. That one file points the agent at your real frontend and backend, and gives it a browser to drive.
2. 2
   Add your hosted tools. Connect GitHub, Jira, Confluence, and Slack with one command each. You sign in as yourself, so the agent only ever sees what you can see.
3. 3
   Check it connected. Run /mcp and confirm every server says connected. A server that is missing is a source the agent is still guessing about.
4. 4
   Prove it has your context. Ask one question that only works if the wiring is real, and tell it to cite its sources. Real file paths and ticket numbers mean you are good to go.

Step 1. Drop this one file at your repo root. It hands the agent your real code and a browser to drive:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
    },
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

# Give your AI real context for QA: starter kit
# From https://juliapottinger.com/resources/give-ai-real-context/

## 1. Drop this .mcp.json at your repo root

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
    },
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

## 2. Verify the wiring is real

Show me what you can see for this project. List the repo, the issue tracker, the chat workspace, and the running app, and for each one name one specific real thing: a file path, an open ticket, a channel. If you cannot reach one, tell me.

## 3. Turn a conversation into a filed bug

Read the cart-bug discussion in the #support channel, then turn it into a single filed bug in our issue tracker. Pull the reproduction details, the affected browsers, and the free-plan account type out of the conversation, and confirm the likely cause by checking the cart retention and cleanup code in the repo, especially anything that changed in the 1.42 release. Write clear numbered steps, a specific expected versus actual, and list the concrete evidence to attach, including the failing cart request and the relevant server log line. Set severity to High and assign it to the cart team.

## 4. Take the same bug to a pull request

The saved-cart bug is confirmed: the cleanup job is keying off the free-plan retention timestamp instead of the cart timestamp. Find the exact code in the repo, make the smallest fix that keeps saved carts independent of the account retention window, and add a test that fails on the old behaviour and passes on the new one. Open a pull request with a clear description and the test output. Change nothing else.

Steps 2 and 3. Add each hosted server with one command, then run /mcp to watch them connect. Check each provider's MCP docs for the current URL:

Every server you care about should say connected. A missing one is a blind spot: a source the agent will guess about instead of read.

Step 4. Prove it. Ask one thing that only works if the wiring is real, and tell it to cite sources:

If it answers with specifics, you are connected. If it stays vague, something is not wired up yet. Pair all of this with a CLAUDE.md at the repo root for your conventions, and the agent has both your standards and your live systems.

The workflows it unlocks

Here is what this looks like once it is really set up, and it is the part I did not expect to love. With my repo open in the editor, the front end and the back end both in view, plus Slack, Confluence, and the tracker connected, the agent can reach everything I can. So the tedious automation work mostly disappears. I do not go hunting for a locator; it reads the frontend and finds a stable one. It finds the API calls. It finds bugs. It goes past what I asked and does the deep research in seconds, and because it is reading my actual application and everything I have built, what it gives back is connected and specific to my system, not a generic answer. That is the whole reason to give it real access.

Within reason: scope access to the task, prefer read access and test data, and keep a human reviewing every change. Real access speeds the work up. It does not move the release decision.

One workflow, worked through: conversation to a filed bug

Here is the most common one in practice. A bug surfaces in a chat channel, gets half-reproduced and guessed at, then lost because everyone is busy. Give an agent access to that channel, the repo, and the issue tracker, and one instruction turns the mess into a filed bug you can act on:

The agent did not invent any of this. It read the conversation, confirmed the cause against the code, and wrote it up in your format. You review the filed bug, not the messy thread. The structure it follows is the one in the bug report template.

The same bug, taken to a pull request

Filing it is half the loop. Because the agent already has the repo, you can hand the confirmed bug straight back and ask it to fix it, prove the fix, and open a pull request you review. One instruction:

This is the part to hold onto. The agent did the finding, the fixing, and the proving, and it brought evidence: a test that fails on the old code and passes on the new one. The merge decision is still yours. That is what real access looks like in practice. It speeds the work up and leaves the judgment where it belongs.

Where AI stops and you start

AI is not one thing. Hand it what it is good at, and keep what needs a human, especially anything visual. I am building a game right now, and this is exactly where it bites: the agent cannot see when something is visually off, a button too big, an element a few pixels out of line, a screen that falls apart on a real device. Across real screen sizes and on mobile, that judgment is still my eyes, not the model's.

Keep it safe

Real access is powerful, so scope it the way you would for any new teammate. Three rules cover almost everything.

• Scope access to the task. An agent does not need blanket write access to production to read a flow and reason about it.
• Prefer read access and test data. Be deliberate about credentials and customer records, the same way you would for a new hire.
• A human reviews every change before it merges or ships. Real access speeds the work up. It does not move the release decision.