What is an MCP server? A guide for product and engineering teams

An AI assistant can explain a rollout plan from memory. An MCP-connected assistant can inspect the real flag, check its current rules, and propose the next safe action.

That difference is the reason Model Context Protocol (MCP) matters to product and engineering teams. A language model knows patterns from training and whatever you paste into a conversation. It does not automatically know which experiments are running, which feature flags are enabled in production, or which metrics your company trusts. An MCP server gives an AI application a standardized way to discover approved capabilities and reach live systems when the task requires it.

The word server can make MCP sound like another infrastructure project. Often it is much smaller. A local MCP server may be a process that an editor starts on your laptop and communicates with over standard input and output. A remote server may expose an authenticated HTTP endpoint. In both cases, its job is the same: translate between an AI client and a system such as GitHub, Slack, a database, or an experimentation platform.

This guide explains the architecture without treating MCP as magic. You will learn what an MCP server exposes, how a request moves from a prompt to an action, why MCP is different from an ordinary API integration, and which security and governance questions teams should answer before connecting production systems.

An MCP server is an adapter for AI applications

The official MCP documentation defines servers as programs that expose specific capabilities to AI applications through standardized protocol interfaces. That definition contains 3 important ideas.

First, the server is not the model. It does not generate the answer by itself. The model runs inside a host application such as an IDE, desktop assistant, or internal agent. The host maintains an MCP client connection to the server.

Second, the server is not necessarily the underlying system of record. A GrowthBook MCP server does not replace GrowthBook. It authenticates to GrowthBook, discovers relevant workflows, and calls the platform's APIs. A database MCP server similarly sits in front of the database rather than becoming the database.

Third, the interface is standardized. A compatible client can ask a server which capabilities it offers, inspect their schemas, and invoke them without a bespoke integration for every client-server pairing. That is why MCP is often compared with USB-C: the standard defines the connection, while each attached system still decides what it can do.

Hosts, clients, and servers have different jobs

Teams often use the terms host, client, and server interchangeably. Keeping them separate makes troubleshooting and security reviews easier.

A single host can run multiple clients, each connected to a different server. That composability is useful, but it also creates cross-server risk. An agent that can read an untrusted document and write to a production service needs tighter controls than an agent with read-only access to public documentation.

Tools, resources, prompts, and skills are related but distinct

The MCP specification describes 3 core server primitives: tools, resources, and prompts. Tools are schema-defined operations the model can request, such as listing experiments or creating a feature. Resources provide passive context, such as a schema or document. Prompts are reusable templates that guide a user through a task.

Modern agent workflows add another layer: skills. A skill is procedural knowledge that tells the agent how to combine reads, writes, checks, and approval gates into a reliable workflow. A raw API tool might technically allow an agent to update a feature flag. A cleanup skill can require the agent to inspect code references, archive first, verify behavior, and only then consider deletion.

GrowthBook's current open-source MCP package illustrates this separation. Version 2 exposes a small capability surface: list bundled skills, read a selected skill, and call the authenticated REST API. The server source describes this thin design: competence lives in the skills, while the generic API bridge supplies capability. That is a more maintainable model than shipping dozens of hard-coded MCP tools whose workflow logic drifts from the product.

Plan feature flags at scale

Learn the architecture and governance practices that keep feature flags useful as your codebase, environments, and teams grow.

Read the Feature Flag Guide

A prompt becomes an action through a controlled chain

Suppose a product manager asks, "Which checkout experiments are running, and are any guardrails moving in the wrong direction?" The model cannot answer accurately from general knowledge. It needs live context.

An MCP-enabled flow usually looks like this:

1. The host sends the conversation and available capability descriptions to the model.
2. The model decides that a GrowthBook workflow fits the request.
3. The client asks the GrowthBook server to list or read the relevant experiment-analysis skill.
4. The model follows that skill and requests read operations through the server.
5. The server adds authentication and sends approved API calls to GrowthBook.
6. GrowthBook applies the credential's permissions and returns current experiment data.
7. The model interprets the response, cites uncertainty, and presents a human-readable summary.

If the request changes from reading to writing, the chain should become more deliberate. Starting an experiment, publishing a flag revision, or disabling a production feature changes shared state. A good skill makes that boundary explicit and asks for confirmation at the point where the intended change is concrete.

The model proposes; the system still enforces

MCP does not give a model supernatural access. The server can only expose what its implementation supports. The underlying platform can only return or mutate what the credential allows. The host can also require approval before invoking a tool.

This layered control matters. Model behavior is probabilistic, but authorization should not be. Use a personal access token or service credential with the smallest useful scope, keep environment boundaries clear, and depend on the system of record to enforce permissions. The GrowthBook MCP setup accepts a personal access token or secret key; when a PAT is used, accessible operations follow that user's permissions.

The same principle applies to the current GrowthBook skills. Discovery workflows such as flag search and metric search are read-only. Mutating workflows add explicit review points, and revision-based flag changes preserve a draft-review-publish path rather than treating a natural-language request as an automatic production change.

The response is only as trustworthy as the workflow

An MCP call can return current data and still produce a weak answer. The model may select the wrong project, confuse a draft with a live revision, summarize stale experiment results, or omit a guardrail. Reliability comes from the workflow around the call.

For high-value tasks, the skill should specify:

• which identifiers to resolve before acting
• which state to read back after a write
• which warnings block progress
• when user confirmation is required
• how to handle ambiguous project, environment, metric, or owner names
• what evidence to include in the final response

This is why product teams should evaluate MCP servers on more than their tool count. A server with 100 loosely described actions can be less useful than a thin server backed by well-tested skills and precise guardrails.

MCP and APIs solve different layers of the integration problem

MCP does not replace APIs. Most production MCP servers call APIs, query databases, or read files behind the scenes. The difference is who discovers and orchestrates those capabilities.

In a conventional integration, a developer chooses an endpoint, writes code for its request and response, handles authentication, and builds a fixed user interface. In an MCP workflow, the server describes capabilities to the AI client. The model can select an appropriate operation at runtime based on the user's request, then combine multiple operations under the host's supervision.

The distinction suggests a practical architecture rule: keep business authority in the API and system of record, while using MCP for discovery and orchestration. GrowthBook follows that pattern. Its REST API remains the source of capability, while the MCP server and official skills make those operations usable from agent environments.

Local and remote transports change the trust boundary

Many developer-focused MCP servers use stdio. The host starts a local process, sends messages through its input stream, and receives responses from its output stream. There is no separately exposed network port. This can simplify installation and reduce remote attack surface, although the process still inherits whatever local and API access you give it.

Remote MCP uses HTTP and requires a stronger authentication and deployment story. The current MCP transport specification defines stdio and Streamable HTTP patterns. GrowthBook's version 2 server supports both. Its HTTP mode can expose a full skills-plus-API endpoint or a capability-only endpoint behind an OAuth protected-resource surface.

Remote deployment is not simply "local MCP, but hosted." You must define the public server URL, validate bearer tokens, restrict network exposure, and decide whether a single server can safely serve multiple tenants. The GrowthBook repository recommends loopback or a trusted network by default and a separate gateway or authentication layer for public or multi-tenant deployments.

Product and engineering teams need a shared operating model

The fastest path to MCP value is not connecting every system. It is choosing one bounded workflow where live context removes repeated friction.

For engineering, that might be searching flags, generating a proposed flag configuration, or reading experiment results next to the code that produced them. For product, it might be reviewing a launchable experiment spec, checking guardrails, or exploring a trusted metric without waiting for a dashboard walkthrough. GrowthBook's MCP platform page shows examples across flag creation, experiment setup, results analysis, stale-flag review, and program-level learning.

Start with read-only workflows

Read-only access gives a team room to evaluate answer quality without creating production risk. Useful first tasks include:

• list feature flags for one project and environment
• summarize the metadata for a named experiment
• search fact metrics and explain which are chartable
• inspect open flag revisions and approval state
• trace a flag's prerequisites and linked experiments

Ask reviewers to compare the answer with the GrowthBook UI. Track incorrect identifiers, missing caveats, and cases where the agent should have asked a question. These observations tell you whether the server descriptions and skills are strong enough before you enable writes.

Add writes as explicit, reviewable workflows

Once read behavior is trustworthy, add a small number of writes. A good first write is reversible and easy to verify, such as creating a disabled flag in a development project. Avoid making the first test a production kill switch or a bulk cleanup.

For every write workflow, define the receipt. A useful receipt names the project, environment, flag or experiment ID, requested action, API result, and final readback. If the platform uses draft revisions, the receipt should say whether the change is only in draft, awaiting approval, or live.

That distinction protects both roles. Product managers can describe intent in plain English, while engineering retains visibility into the exact artifact and lifecycle state. Natural language becomes an interface, not an excuse to erase change control.

Measure workflow quality, not novelty

An MCP pilot should answer operational questions:

• Did the agent resolve the right resource?
• Did it distinguish current, draft, and historical state?
• Did it stop before destructive or production-sensitive actions?
• Did it reduce handoffs or context switching?
• Could a reviewer reproduce the result from the receipt?

If the answer is no, adding more servers will compound the problem. Improve the skill, permissions, or data model first.

Security review starts with capabilities and data flow

MCP inherits ordinary software security concerns and adds agent-specific ones. A tool description or returned document may contain instructions that influence the model. Multiple connected servers can create an unintended path from sensitive data to an external write. A local package can also execute code on the user's machine.

The NSA's MCP security guidance recommends supported projects, explicit trust boundaries, least privilege, input validation, isolation, and strong control of outbound connections. Those are familiar security practices, but MCP makes it easy to overlook them because installation often looks like one command and a JSON block.

Review the server like production code

Before adoption, answer these questions:

1. Who publishes and maintains the server? Prefer an official repository or a project your team can audit.
2. What code runs locally? Pin or review versions when your risk model requires reproducible dependencies.
3. Which credentials does it receive? Avoid broad admin tokens for routine workflows.
4. Which tools and skills are exposed? Separate read-only discovery from mutations.
5. Where can data flow? Include the host, model provider, server process, API, logs, and any other connected server.
6. How are actions approved and audited? Make the final write and readback visible to the user.

GrowthBook's MCP server is open source and listed in the official MCP Registry. Those signals make inspection easier, but they do not replace your own credential, host, and data-handling review.

Treat retrieved content as untrusted input

Prompt injection is not limited to chat messages. A document, issue, experiment description, or tool result can contain text that tries to redirect the model. Hosts and server authors should clearly separate instructions from data, validate parameters, restrict dangerous combinations of tools, and keep humans in the loop for consequential actions.

Product teams have a role here too. Descriptions, hypotheses, and metric names should not quietly become executable policy. A natural-language request may propose a targeting condition, but a structured rule schema and review step should decide what reaches production.

Choose one closed-loop workflow to begin

MCP is most useful when it closes a loop. Reading a flag is helpful. Reading the flag, checking its code references, proposing a draft change, waiting for review, publishing the approved revision, and verifying the live state is an operational workflow.

GrowthBook's current skill library organizes work into these loops. Experiment-first work can move from design to launch, analysis, stop, and eventual flag cleanup. Flag-first work can move from creation to targeting, ramp, monitoring, and cleanup. Product analytics can move from metric discovery to a chart and then to an experiment idea. The AI-native development platform places these loops alongside feature flags and experimentation rather than treating the agent as a separate control plane.

Start with the loop your team already performs frequently and inconsistently. Document the desired states, required approvals, and verification evidence. Then connect the smallest capability set that can complete it.

An MCP server is not valuable because it lets a model call an API. It is valuable when it brings current context and safe actions into the place where a decision is being made. The protocol standardizes the connection. Your permissions, skills, and review process determine whether that connection is trustworthy.

Strengthen experiment design

Watch Ronny Kohavi and Luke Sonnet break down metric choices, trustworthy setup, and the mistakes that undermine online experiments.

Watch the Webinar