Skip to content

Model Context Protocol (MCP): Connect AI to Your Tools and Data · MCP in production · lesson 15 of 18 · 14 min

Rolling out MCP across an organization

From experiments to a program

Most organizations start with individuals connecting servers they found online. That is how shadow IT begins: unknown code running with employees' privileges and unreviewed third parties receiving business data. An MCP program turns this into a governed capability without killing momentum.

The operating model

  1. Owner: a platform or AI enablement team owns standards, the catalog and security reviews; domain teams own their servers.
  2. Catalog: an approved list of servers (internal and third-party) with owners, data classification, scopes, supported hosts and review dates.
  3. Intake and review: a lightweight process for requesting a new server: purpose, data touched, tools and scopes, publisher trust, security checklist (module 5), and a decision within days, not months.
  4. Standards: naming, description quality, auth, logging, versioning, testing and eval requirements (modules 3 and 6).
  5. Enablement: templates, internal SDK wrappers, example servers and office hours.
  6. Monitoring: centralized logs and metrics; periodic re-review.

Controls that scale

  • Identity: use the company identity provider for OAuth; consider the Enterprise-Managed Authorization extension where supported so the IdP centrally governs which servers and scopes users get.
  • Host administration: many enterprise AI hosts let admins manage allowed connectors and disable user-added servers; use it.
  • Gateways: an MCP-aware gateway can enforce authentication, rate limits, allowlists of servers and tools, data loss prevention checks and logging across all servers, routing on Mcp-Method / Mcp-Name headers.
  • Data classification: map each server to the highest data class it touches; restrict which hosts and models may use servers with confidential data.
  • Change management: tool-definition pinning and changelogs; re-review on major changes.

Vendor evaluation questions for third-party servers

  • Who publishes and maintains it? Is it official from the product vendor?
  • Local or remote? If remote, where is data processed and stored, and for how long?
  • What scopes does it request? Can we restrict to read-only?
  • Does it support OAuth with our IdP, audience-bound tokens, and no passthrough?
  • Are tool definitions versioned with a changelog?
  • What logging and audit export exist?
  • Security contact, vulnerability disclosure policy, compliance attestations?
  • Which protocol versions does it support?

Regulatory and privacy context

MCP servers move personal and confidential data into AI workflows. Apply your existing privacy obligations: GDPR and UK GDPR (lawful basis, data minimization, processor agreements, international transfers), Saudi Arabia's PDPL, the UAE's federal PDPL and free-zone regimes (such as DIFC and ADGM data protection laws), and sector rules in finance and health. Pakistan has been developing personal data protection legislation; check the current status for your context. Under the EU AI Act's phased obligations, organizations deploying AI systems in certain uses also carry transparency and oversight duties. Involve your privacy and legal teams early; this course is not legal advice.

A 90-day rollout plan

| Phase | Weeks | Activities | |---|---|---| | Discover | 1–3 | Inventory current MCP usage (surveys, endpoint scans, host admin reports); pick 3 high-value use cases | | Foundation | 3–6 | Catalog, intake process, standards v1, IdP integration, gateway or host admin controls, logging | | Pilot | 6–10 | 2–3 internal servers built to standard; 2 vetted third-party servers; 30–50 pilot users; evals and security tests | | Scale | 10–13 | Open catalog to more teams; templates and training; metrics review; decommission unmanaged servers |

Worked example: a multi-country retail group (UK, UAE, KSA)

The group found 40+ MCP servers in use across teams, including community servers with broad file and web access. In 90 days they: published a catalog of 12 approved servers; built internal product-catalog, store-ops and marketing-analytics servers to standard; routed all remote servers through a gateway with Entra-based OAuth; restricted servers touching customer data to hosts with enterprise data-protection terms; and gave teams a two-day intake SLA. Unmanaged server usage fell sharply, and time to add a new integration dropped because teams reused templates.

Hands-on: a server catalog entry template

server: marketing-analytics
owner: data-platform@company.example
publisher: internal
transport: streamable-http
url: https://mcp.company.example/marketing-analytics/mcp
protocol_versions: ["2025-11-25", "2026-07-28"]
auth: oauth (Entra ID), audience=https://mcp.company.example/marketing-analytics/mcp
scopes:
  analytics.read: [find_campaigns, get_performance, pipeline_summary]
data_classification: internal-confidential
personal_data: none (aggregated only)
approved_hosts: [claude-enterprise, vscode-copilot, internal-agents]
tool_definitions_hash: 3f9c...e1a        # updated on each approved release
last_security_review: 2026-09-10
next_review_due: 2027-03-10
evals: nightly, tool-selection accuracy threshold agreed with owners
runbook: https://wiki.company.example/mcp/marketing-analytics

Pitfalls

  • Blocking everything, which drives usage underground.
  • Approving servers once and never re-reviewing.
  • Letting servers touching personal data be used from consumer-grade accounts.
  • No owner for a server, so no one fixes it when the API changes.

Measuring success

Share of MCP traffic through cataloged servers, intake turnaround time, number of unmanaged servers, incidents, and reuse (clients per server).

Video lecture: Rolling out MCP across an organization

Lecture coming soon · 15 chapters · about 9 minutes. Read the full transcript below.

  1. Enterprise MCP rollout
  2. Why an org program?
  3. Operating model
  4. Controls that scale
  5. Vendor evaluation
  6. Simple example: a two-day intake
  7. Privacy and regulation
  8. 90-day plan
  9. Example: multi-country retail group
  10. Hands-on: catalog entry
  11. Program metrics
  12. Deeper: the retail group program (illustrative)
  13. Watch me do it: a catalog entry
  14. Try this now
  15. Recap

Lecture transcript

Enterprise MCP rollout

Most organizations meet MCP the same way: individuals connecting servers they found online. That's how shadow IT starts, with unknown code running on laptops and unreviewed third parties receiving business data. In this lesson you'll learn how to turn that into a governed program, without killing the momentum.

Why an org program?

Why think about the whole organization? Because MCP adoption usually starts bottom up, with enthusiastic individuals, and that's good. But without a program, you end up with forty servers nobody owns, some with broad access to files and the web, and no way to answer the question, what can our AI tools touch? Think of how companies handled cloud storage a decade ago. First, everyone used personal accounts. Then came approved services, single sign on and admin controls. MCP is on the same path, only faster.

Operating model

Start with an operating model. A platform or AI enablement team owns standards, the catalog and security reviews, while domain teams own their servers. The catalog lists approved servers with owners, data classification, scopes, supported hosts and review dates. Intake is a lightweight request and review, decided in days, not months. Standards cover naming, descriptions, auth, logging, versioning, testing and evals. Enablement means templates, examples and office hours. And monitoring means central logs and regular re review.

Controls that scale

Now controls that scale. Use the company identity provider for OAuth, and where supported, the enterprise managed authorization extension, so the IdP centrally decides which servers and scopes people get. Use host admin settings to manage allowed connectors and block user added servers. Put an MCP aware gateway in front of remote servers for authentication, rate limits, allowlists, data loss checks and logging. Classify data per server and restrict which hosts can use confidential servers. And manage change with definition pinning and changelogs.

Vendor evaluation

Third party servers deserve careful questions. Who publishes and maintains it, and is it the official one from the product vendor? Local or remote? Where is data processed and stored, and for how long? What scopes does it need, and can you restrict it to read only? Does it support OAuth with your identity provider, audience bound tokens and no passthrough? Are tool definitions versioned? What audit logs exist? Is there a security contact and disclosure policy? And which protocol versions does it support?

Simple example: a two-day intake

A simple example of fast intake. A marketing analyst wants to connect a third party SEO tool's MCP server. She fills in a short form: what it's for, which data it touches, which tools and scopes it needs, and who publishes it. The platform team checks the vendor questions, sees it's the official server from the SEO vendor, restricts it to read only tools, and adds it to the catalog within two days. She gets what she needed, and the organization knows exactly what was connected and why.

Privacy and regulation

MCP servers move personal and confidential data into AI workflows, so your existing privacy obligations apply. That includes GDPR and UK GDPR, Saudi Arabia's personal data protection law, the UAE's federal data protection law and free zone regimes like DIFC and ADGM, and sector rules in finance and health. Pakistan has been developing data protection legislation, so check the current status. The EU AI Act's phased obligations add transparency and oversight duties for some uses. Involve privacy and legal early. This course isn't legal advice.

90-day plan

Here's a ninety day plan. Weeks one to three, discover: inventory current usage with surveys, endpoint scans and host admin reports, and pick three high value use cases. Weeks three to six, foundation: catalog, intake, standards, identity integration, gateway or admin controls, and logging. Weeks six to ten, pilot: two or three internal servers built to standard, two vetted third party servers, thirty to fifty pilot users, with evals and security tests. Weeks ten to thirteen, scale: open the catalog, train teams, review metrics, and retire unmanaged servers.

Example: multi-country retail group

A worked example. A retail group operating in the UK, UAE and Saudi Arabia discovered more than forty MCP servers in use, some with broad file and web access. In ninety days they published a catalog of twelve approved servers, built three internal servers to standard, routed remote servers through a gateway with company sign in, limited customer data servers to hosts with enterprise data terms, and promised a two day intake turnaround. Unmanaged usage fell sharply, and new integrations got faster because teams reused templates.

Hands-on: catalog entry

The hands on template is a catalog entry. It records the server name, owner, publisher, transport and URL, supported protocol versions, auth and audience, scopes mapped to tools, data classification and personal data, approved hosts, a hash of approved tool definitions, review dates, eval expectations and a runbook link. Avoid blocking everything, which drives usage underground, never re reviewing, allowing personal data servers from consumer accounts, and servers with no owner.

Program metrics

How do you measure whether the program is working? Track four numbers. The share of MCP traffic flowing through cataloged servers, which should rise. The number of unmanaged servers, which should fall. Intake turnaround time, which should stay short so people don't route around you. And reuse, meaning how many clients each server serves. Review them monthly with stakeholders, and celebrate teams whose servers are widely reused.

Deeper: the retail group program (illustrative)

Let's deepen the multi country retail group. The discovery survey found forty plus servers, and about a third had broad file or web access, illustrative numbers. Nobody was punished; instead the platform team offered approved alternatives for the most popular ones and a two day intake. Within the ninety days, most unmanaged usage moved to cataloged servers, three internal servers were built from templates, and the remaining unmanaged servers were retired. The UAE and Saudi teams got servers restricted to hosts with enterprise data terms for anything touching customer data. The metric the executive sponsor cared about most: time to add a new AI integration, which fell from weeks to days.

Watch me do it: a catalog entry

Watch me do it. Let's fill in a catalog entry together for the marketing analytics server. Server name, owner email, publisher internal. Transport streamable HTTP, and the URL behind our gateway. Protocol versions: both twenty twenty five eleven twenty five and twenty twenty six seven twenty eight, since we're mid transition. Auth: OAuth through Entra, with the audience set to the server's URL. Scopes: analytics read maps to find campaigns, get performance and pipeline summary. Data classification: internal confidential; personal data: none, because results are aggregated. Approved hosts: Claude Enterprise, VS Code with Copilot, and internal agents. The tool definitions hash is recorded from the approved release. Last review date and next review due in six months. Evals: nightly, with a threshold agreed with the owners. And a runbook link. That single entry answers most questions an auditor, a security reviewer or a new team member would ask.

Try this now

Try this now. Draft catalog entries for two MCP servers your organization uses or needs, using the template from the lesson: owner, transport, versions, auth, scopes mapped to tools, data classification, approved hosts, definition fingerprint and review dates. Then write a one page ninety day plan with a named owner for each phase and one metric per phase, like number of unmanaged servers, intake turnaround time, or share of traffic through cataloged servers.

Recap

To recap: run MCP as a program with an owner, a catalog, fast intake, standards, enablement and monitoring. Scale controls through identity, host admin, gateways, classification and change management. Evaluate vendors carefully, respect privacy law, and roll out in phases. Your next step: draft catalog entries for two servers and a one page ninety day plan with owners and metrics.

Key takeaways

  • Turn ad hoc MCP use into a program with an owner, catalog, intake review, standards, enablement and monitoring.
  • Scale controls through the company IdP, host admin settings, gateways, data classification and change management.
  • Evaluate third-party servers on publisher, data handling, scopes, auth, versioning, logging and security posture.
  • Apply existing privacy obligations such as GDPR, UK GDPR, KSA PDPL and UAE PDPL, with legal involvement.
  • Roll out in phases: discover, foundation, pilot, scale.

Try it

Draft catalog entries for two servers your organization uses or needs, and a one-page 90-day rollout plan with owners and metrics.