MCP Host, Client & Server Deep Dive: How MCP Architecture Works for Playwright and Enterprise Testing

In the previous tutorial, MCP Fundamentals for SDETs, we introduced MCP — Model Context Protocol — and learned why AI applications need a standardized way to interact with external tools and systems. Now we go one level deeper into the three most important architectural concepts in MCP: the MCP Host, the MCP Client, and the MCP Server. If you clearly understand these three components, technologies such as Playwright MCP, GitHub Copilot agents, database MCP servers, GitHub integrations and Agentic AI testing become much easier to understand.

In this tutorial we cover what each component is, Host vs Client vs Server, how they communicate, who starts the connection, how capability discovery works, what happens when an AI invokes a tool, one Host connecting to multiple MCP servers, local vs remote MCP servers, Playwright MCP architecture, enterprise SDET examples, security boundaries, common misconceptions and the complete request/response lifecycle.

1. Start With the Big Picture

The easiest architecture to remember is a straight vertical chain. Each layer hands work to the layer below it, and results travel back up.

For Playwright-based browser interaction, the chain becomes concrete.

The important question to keep in mind throughout this tutorial is: what responsibility belongs to each layer?

2. What Is an MCP Host?

The MCP Host is the application or AI environment that coordinates the overall MCP experience. The user interacts with the host.

The host can manage things such as user interaction, AI/model interaction, MCP server connections, permissions, available capabilities, context, tool execution workflows and security boundaries.

3. MCP Host Example

Imagine an SDET working inside an AI-enabled development environment. The SDET asks:

The host receives that request.

The host itself does not necessarily know how to operate a browser. Instead, it can have a connection to an MCP server that exposes browser capabilities.

4. What Is an MCP Client?

This is where many beginners get confused. The MCP Client is not normally another application that the SDET manually opens. It is a protocol component used by the host to communicate with an MCP server.

The client's job is communication. It participates in establishing MCP communication, negotiating protocol capabilities, discovering server capabilities, sending requests, receiving responses and passing results back into the host environment.

5. Where Does the MCP Client Live?

Conceptually, the MCP client exists on the host side.

This distinction matters. Do not think "Host = Computer, Client = AI, Server = Internet". That is not the MCP architecture. Instead, think in terms of responsibilities.

6. What Is an MCP Server?

An MCP Server is a program or service that exposes capabilities through MCP. Those capabilities can include Tools, Resources and Prompts. For testing, an MCP server might provide access to browser operations, database queries, repository information, files, issue tracking and internal engineering systems.

7. The Server Is an Adapter Layer

A useful way for SDETs to understand an MCP server is to think of it as an adapter. Suppose you have PostgreSQL. The AI model does not directly communicate with PostgreSQL.

The MCP server understands how to interact with the underlying system and exposes appropriate capabilities through MCP. The same idea applies to a browser.

8. Host vs Client vs Server

• MCP Host — coordinates the AI application and MCP environment.
• MCP Client — communicates with a specific MCP server.
• MCP Server — exposes capabilities through MCP.
• External System — performs or stores the actual underlying work/data.

9. One Host Can Connect to Multiple Servers

This is extremely important for enterprise Agentic AI architectures. Imagine your AI testing environment needs browser access, GitHub, a database, Jira and file access. You do not necessarily build one giant MCP server.

This creates a tool-connected AI environment.

10. Why Multiple Clients?

A useful conceptual model is that the host maintains client connections to servers.

This helps maintain separation between different server connections. For enterprise environments, this separation can also support better security, permission control, isolation, configuration, auditing and lifecycle management.

11. How Does an MCP Connection Start?

Before an AI can use server capabilities, the client and server need to establish communication. A simplified lifecycle:

The client and server exchange information about what they support. This is important because different implementations may expose different capabilities.

12. Initialization

When an MCP connection begins, initialization allows both sides to understand important protocol information.

Now the host can work with the capabilities exposed through that connection.

13. Capability Discovery

Suppose a Playwright MCP server exposes browser-related tools. The AI should not have to blindly guess what operations exist. The MCP client can discover capabilities exposed by the server.

The exact names and capabilities depend on the server implementation.

14. Why Tool Discovery Matters

Without discovery, an AI application would need hard-coded knowledge of every possible integration: browser integration, database integration, GitHub integration, Jira integration, cloud integration — each could expose different operations. With MCP, the server can describe the capabilities it provides.

This is one of the important architectural benefits of MCP.

15. What Happens When the AI Uses a Tool?

Now we get to the most interesting part. Suppose the user says "Open the login page." The AI determines that browser navigation is required.

The result then travels back.

The AI can now reason about what happened.

16. Complete Request/Response Loop

This is one of the most important diagrams in this tutorial.

This can become a loop.

17. Playwright MCP Example

Suppose the SDET provides this goal: "Verify that a user can log in and reach the dashboard." The agent might reason:

18. Traditional Playwright Comparison

Here, the engineer has explicitly defined Navigate, Fill, Fill, Click, Assert — the sequence is predetermined. With an AI + MCP workflow, the user may instead provide the goal: "Verify that a valid user can log in." The AI reasons about which available capabilities should be used. That is a major architectural difference.

19. Local MCP Server

An MCP server can run locally.

This can be useful for developer workflows involving local tools and resources.

20. Remote MCP Server

An MCP server can also be available remotely when supported by the deployment and transport architecture.

Remote access makes authentication, authorization, network security and governance especially important.

21. Local vs Remote

• Local MCP Server — runs near/on the client machine; useful for local tools; local process communication may be used; smaller network attack surface; often developer-focused.
• Remote MCP Server — runs in another environment; useful for centralized services; network transport may be used; requires stronger network controls; can support shared enterprise capabilities.

Neither approach is automatically better. The right architecture depends on the use case.

22. Example: Database MCP Server

Imagine the AI needs to validate whether a product was actually stored in PostgreSQL.

The agent might want to perform a validation conceptually equivalent to:

The database server could expose a controlled query capability. The AI does not need direct unrestricted database administration access.

23. Example: GitHub MCP Server

Suppose a test fails and the agent needs repository context.

The AI might retrieve information such as test files, application source, configuration, recent code changes and pull request information. The capabilities depend on the server and the permissions granted.

24. Example: Jira MCP Server

Now imagine the agent discovers a defect.

Depending on available capabilities and authorization, the workflow might support operations such as: Read Story, Read Acceptance Criteria, Search Existing Bugs, Create Defect, Update Issue. This starts to demonstrate why MCP can be powerful for enterprise Quality Engineering.

25. Multiple Servers in One Testing Workflow

Now combine the systems. Suppose the goal is: "Validate PRODUCT-101 end to end." The AI may need Jira (read requirement), GitHub (understand implementation), Browser (test UI), Database (validate data), and Jira again (report defect).

26. The Host Coordinates — Servers Specialize

This principle is worth remembering.

Each server can expose a focused set of capabilities.

27. Security Boundary Between Host and Server

This is extremely important in enterprise environments. Just because a server exposes a capability does not mean every agent should automatically receive unrestricted access.

If the server allows unrestricted destructive queries, the risk is significant. Instead:

28. Server Permissions Matter

Imagine two database servers. Server A exposes only SELECT. Server B exposes SELECT, INSERT, UPDATE, DELETE and DROP. These are not equivalent from a security perspective. The AI may be identical — the difference is the capabilities and permissions exposed to it.

29. Authentication vs Authorization

These concepts are especially important for remote or enterprise MCP deployments. Authentication asks "Who are you?" Authorization asks "What are you allowed to do?"

30. Human Approval Can Sit Above Tool Execution

For sensitive operations, the host or surrounding agent platform can enforce approval policies.

31. Common Misconception: MCP Server Is the AI

The MCP server exposes capabilities. The AI performs the reasoning.

32. Common Misconception: MCP Server Replaces the API

MCP does not replace REST APIs. An MCP server may actually use an existing API underneath.

MCP provides the AI-facing integration layer. The underlying application architecture can remain unchanged.

33. Common Misconception: MCP Client Performs the Real Work

Usually, the client is primarily responsible for MCP communication. The actual capability is provided on the server side or by the external system behind it.

34. Common Misconception: One MCP Server Does Everything

Technically, a server can expose multiple capabilities. But enterprise architecture often benefits from separation.

This can improve security, ownership, maintainability, permission boundaries, auditability and scalability.

35. What Happens When a Tool Fails?

Suppose the AI asks the browser server to click Login, but the button is not available.

Now the AI can reason about the observation.

This observation loop is what makes tool-enabled agents interesting for testing.

36. Host, Client and Server in an Agentic Loop

Putting everything together:

That is one of the core architectures behind tool-enabled agentic workflows.

37. Enterprise Playwright Testing Architecture

For a professional Quality Engineering environment:

Then your deterministic automation can continue existing separately.

The two approaches can complement each other.

38. A Real SDET Workflow

Suppose a new Jira story says: "As an administrator, I should be able to create a product." The AI-assisted testing workflow could be:

1. Read Jira story
2. Understand acceptance criteria
3. Inspect relevant application code
4. Determine test scenarios
5. Open application
6. Login as admin
7. Navigate to Products
8. Create product
9. Validate UI result
10. Validate API behavior
11. Validate database record
12. Investigate failures
13. Collect evidence
14. Create defect if authorized
15. Produce testing summary

Different MCP servers can provide different pieces of this workflow.

39. Host, Client and Server Interview Explanation

If an interviewer asks: "Explain MCP Host, Client, and Server" — a strong short answer is: An MCP Host is the AI application or environment coordinating the user experience and MCP connections. An MCP Client is the protocol component on the host side that communicates with an MCP Server. The MCP Server exposes capabilities such as tools, resources and prompts. The server may then interact with an external system such as Playwright, GitHub, Jira or a database.

Then draw the chain above — that demonstrates the architecture clearly.

40. Easy Way to Remember It

Use this analogy. Imagine a restaurant.

The customer requests something. The waiter communicates the request. The kitchen provides the capability to fulfill it. The result returns to the customer. It is not a perfect technical analogy, but it helps beginners remember the responsibilities.

41. MCP Architecture Cheat Sheet

42. The Architecture You Should Memorize

For MCP fundamentals:

For Playwright:

For enterprise Agentic Quality Engineering:

43. Final Takeaway

The most important thing is to separate the responsibilities.

When an SDET says "Test the checkout functionality", a tool-enabled architecture can conceptually become:

Once you understand this flow, Playwright MCP and Agentic AI testing stop looking mysterious. They become an architecture made of understandable components.