Consider this hypothetical QA example. You ask an AI assistant to create tests for a Jira story. It gives you a reasonable-looking list.

Then you notice something important: the assistant has not read the actual story or the product owner’s comment:

“Guest checkout is excluded.”

The assistant has suggested guest checkout tests. They look sensible—but they are wrong for this release.

What if the assistant could retrieve the Jira issue and its comments before creating the tests? What if it could then open the checkout page in a browser and inspect the screen?

That is the kind of connection MCP helps make possible.

MCP stands for Model Context Protocol. The official specification describes it as an open protocol that provides a standard way for applications using language models to integrate with external data sources and tools.

The word protocol is important. MCP defines message structures and operations through which clients and servers negotiate capabilities and exchange requests and results. How a host presents or approves those capabilities is partly an implementation choice.

MCP does not:

  • provide the AI model;
  • decide which tests are important; or
  • turn an AI assistant into an agent by itself.

It provides a standard connection. What the assistant does with that connection is a separate question.

How does an MCP connection work?

For a given task, an AI assistant can use only the context and capabilities its host application makes available. MCP is one way for a compatible host to add external context and tools; it is not the only possible integration method.

MCP allows a compatible AI application to discover and use capabilities exposed by a connected program. For example, one connection may offer access to Jira issues, while another may offer browser interaction.

You may see three terms used to describe this setup:

Term Meaning
Host The language-model application that initiates connections.
Client A connector inside the host application.
MCP server A service that provides context or capabilities. Depending on its transport and deployment, it may run locally or remotely.

An MCP server can expose:

  • tools that models can invoke to interact with external systems;
  • resources that provide contextual data; and
  • prompts that provide reusable message or instruction templates.

For a QA team, a server could expose a tool that retrieves a Jira issue, a resource containing a project testing guide or a prompt containing a test-review template. These are possible uses of the protocol primitives, not capabilities guaranteed by MCP itself.

One possible tool-use interaction is:

  1. You give the assistant a task.
  2. The model or host selects an available tool, depending on the application’s interaction design.
  3. The server returns information or performs the requested operation.
  4. The assistant uses the result in its response or next step.

The MCP tools specification recommends keeping a human able to deny tool invocations and showing clearly when tools are exposed or invoked. The protocol does not require every host to use the same approval interface.

A server advertises the capabilities it supports. Connecting to it does not automatically grant access to every project, document or operation behind that server. Effective access also depends on the server, authentication method, authorization rules and permissions of the connected service.

Follow one QA task

Let us return to the checkout story.

You ask the assistant:

“Read this issue and its comments, propose negative tests, and then check the checkout screen.”

A possible workflow could look like this:

  1. Retrieve the Jira story. A configured Atlassian MCP server uses its Jira read tools to fetch the work item and comments. Atlassian currently documents separate tools for getting a Jira work item and listing its comments.
  2. Interpret the scope. The assistant should use the comment about guest checkout while preparing the test suggestions.
  3. Draft relevant tests. It should exclude guest checkout from the proposed set and flag any uncertainty about the comment’s scope.
  4. Inspect the application. The Playwright MCP server provides browser-automation tools that can navigate to the checkout page and perform supported interactions.

This is a possible workflow, not something MCP guarantees.

The necessary servers, tools, environment and permissions must all be configured. The assistant may still:

  • open the wrong Jira issue;
  • overlook the product owner’s comment;
  • use the wrong environment; or
  • test the wrong application build.

Every step therefore needs evidence. A successful connection does not prove that the assistant selected the right issue, understood the comment or inspected the intended build.

There is also an important testing distinction:

Browser interactions performed through Playwright MCP are not automatically a saved and repeatable Playwright Test suite.

Playwright MCP documentation describes browser interaction through structured accessibility snapshots and tool calls. Playwright separately documents facilities for generating and running test code. Therefore, observing MCP-driven browser interaction is not evidence that maintainable test code, assertions, reporting and repeatable execution were created.

Why is MCP useful for QA?

MCP can be useful when an AI-assisted QA task depends on information or actions outside the conversation and compatible servers are available.

In the hypothetical checkout example, the assistant needs the Jira story, its comments and information from the application. Configured MCP servers can provide a standard route to those capabilities, subject to their tools and permissions, instead of requiring the user to paste every item into the conversation.

The value is access to task-relevant evidence and tools. MCP does not decide whether the evidence is correct or whether the resulting tests are good. QA must still verify that the assistant selected the right source, interpreted it correctly and examined the intended environment.

Why does having a standard matter?

Teams use many AI applications and engineering tools. Without a shared protocol, an integration needs an interface designed for the particular application-system pairing. MCP defines a common client-server protocol for compatible implementations; it does not eliminate all product-specific server code or configuration.

MCP gives developers a common protocol for exposing capabilities and gives compatible clients a common way to discover and invoke supported features.

This makes the connection pattern reusable, but it does not remove configuration or make different AI applications behave identically. The protocol standardises the connection—not the quality of the assistant’s decisions.

MCP, RAG and agents are not the same

These terms are related, but they describe different things.

Term Main purpose
RAG Uses retrieved information during generation to support a more grounded answer.
MCP Connects an AI application to external capabilities that may provide information or perform actions.
Agent A broader application design that may plan or carry out multiple steps toward a goal. MCP does not establish one universal definition of agent.

RAG and MCP can work together. An agent may also use tools provided through MCP.

But neither RAG nor MCP automatically turns an assistant into an agent.

What changes when the assistant can act?

Reading a Jira issue and changing one are very different levels of responsibility.

A tool that creates tickets, edits code or uses an administrative screen changes external state and can have real consequences. MCP provides a protocol for the connection, while the host, server and connected service determine:

  • which actions are available;
  • who can use them;
  • what authorisation is required; and
  • whether human review is needed.

Consider this instruction:

“Add these 20 generated tests to Jira.”

Before allowing that action, ask:

  • Is this the correct project and issue?
  • Are the expected results supported by current requirements?
  • Do any of the tests already exist?
  • Has someone reviewed the generated content?
  • Does this user have permission to make the change?

For a lower-risk first trial, a team can begin with read-only capabilities: retrieve information, draft tests and show the supporting evidence. This is a risk-management recommendation, not a requirement of MCP.

Enable write access only after the review process and permission rules are clear.

Security also matters

External systems may return issue descriptions, comments, web pages or other text that the assistant did not create.

That content may be inaccurate or misleading. External content can also contain malicious instructions intended to influence the assistant. This risk is commonly described as indirect prompt injection or untrusted tool output; it is not created uniquely by MCP.

Practical controls include:

  • keep a clear boundary between application instructions and data returned by external systems;
  • provide access only to the systems and actions needed for the task;
  • follow least-privilege access principles; and
  • review important or irreversible changes before they happen.

How should QA evaluate an MCP-based workflow?

Start with one narrow task, such as reading a Jira story and drafting tests.

Make the expected behaviour observable:

  • Which issue should be retrieved?
  • Which details should appear in the answer?
  • Which actions should be available?
  • Which actions must remain unavailable?

Then test realistic variations.

Wrong issue

Does the assistant retrieve the intended story? If the request is ambiguous, does it ask for clarification instead of quietly using an issue with a similar title?

Missing permission

Does it clearly report that it cannot access the issue, or does it invent the missing content?

Conflicting information

Does it notice when the original story and a later comment disagree? Does it ask which source is authoritative instead of silently choosing one?

Unexpected action

Can it draft tests without creating or changing tickets when the user asked only for a proposal?

Untrusted content

Does it avoid following unrelated instructions embedded inside a retrieved Jira issue or web page? Because model behaviour alone is not a hard security boundary, also check the deterministic controls around available tools, permissions and approvals.

Browser verification

If the workflow uses a browser, check:

  • the URL;
  • the environment;
  • the application build;
  • the page state; and
  • the specific behaviour that was observed.

A successful tool result shows that a tool invocation returned successfully according to that tool’s interface. It does not, by itself, establish that the assistant checked the intended behaviour, reached the right conclusion or saved a repeatable regression test.

The point to remember

MCP allows compatible AI applications and servers to exchange context and invoke exposed tools through a common protocol. With suitable servers and permissions, a QA workflow can use systems such as Jira or browser automation instead of relying only on text pasted into a conversation.

But the connection alone does not guarantee a correct or safe result.

MCP standardises the connection. QA judgement and system controls determine whether the resulting work is accurate, safe and worth keeping.

← Back to Blog