Yesterday drew the line between what a model can and cannot see; today you move that line, deliberately, by connecting the agent to the sources a good teammate would already have.
You would not ask a new tester to find bugs without showing them the app, the spec, and the place where the team made its decisions. An AI agent is no different. The plumbing for this is MCP, the Model Context Protocol, an open standard that lets an agent read and act on real sources with your own permissions. Setting it up is smaller than it sounds: one file and a few commands.
The six sources, in the order to connect them
- Your repo, first. Filesystem and Git access means the agent tests what is implemented, not what it assumes.
- Playwright MCP, a close second. It gives the agent a real browser, driven through the accessibility tree, so it exercises the UI the way a user and a screen reader would.
- GitHub. Code search, issues, and pull requests. This is the find it, fix it, open a PR loop.
- Atlassian, meaning Jira and Confluence. The spec and the acceptance criteria, so tests get grounded in intended behaviour, not a guess.
- Slack. The threads where the real decisions and edge cases were worked out, the context that never reaches the ticket.
- Google Drive and Docs. Meeting notes that want to become structured tickets.
Start with the first two and add the rest as the work needs them.
One file to start
Drop this at your repo root as .mcp.json. 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"]
}
}
}
Copy it and commit it. The hosted tools, GitHub, Atlassian, and Slack, are one command each; the exact commands live on my Give Your AI Real Context page, and you sign in as yourself, so the agent only ever sees what you can see. Then, in Claude Code, run /mcp and confirm every server says connected (other agents have their own connections view; the check is the same). A server that is missing is not a small gap. It is a source the agent will guess about instead of read.
Prove the wiring is real
Do not take connected on faith. Ask one question that only works if the access is real, and make it cite sources:
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.
Copy it, run it, and read the answer with a tester’s eye. Real file paths and ticket numbers mean you are wired. Vague generalities mean something is not connected yet, and now you know before it matters.
Workflow
- Connect the repo
- Add hosted tools
- Run /mcp
- Prove it with one question
Three safety rules, non-negotiable
- 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.
In the Day 0 triangle, this is the access side: MCP is what the agent can see and touch. The full playbook, with every server and the worked example we pick up tomorrow, is here: give your AI real context.
Try this today
If you have an agent at work, drop the .mcp.json into a repo you test and run the verify prompt. If you do not, do the paper version: list the six sources for your product by name, your actual repo, your actual tracker, your actual channels, and note which ones your current AI tooling can see. That list is the distance between the answers you get now and the answers you could be getting.
Tomorrow: what this access turns into on a real bug, from a messy Slack thread all the way to a pull request.