MCP Marketplace: Scaling AI Agents with Organizational Context

intuit · Finance · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Enterprise AI-agent context infrastructure

Intuit needed a secure, discoverable, and standardized way for AI agents across the organization to access internal context services without every team rebuilding MCP setup, security, and auditing separately.

Constraints:

• Without a central registry, teams could not see existing MCP services and duplicated context-fetching work.
• Unstandardized MCP services could be unverified, buggy, or non-compliant while feeding critical context to LLMs.
• Sensitive credentials and personal access tokens needed central management and auditability.
• Manual local MCP setup and runtime configuration slowed developer adoption.
• The platform had to support both local containerized MCPs and remote cloud-deployed MCPs.

Architecture

Intuit built an internal MCP Marketplace: a centralized registry and package-manager-like platform for context services. Producers get generated repositories, standardized CI/CD, Docker builds, security scanning, release tags, and publication to an enterprise registry. Consumers browse verified services, run a CLI installer, store secrets in a native vault, and connect agents through gRPC middleware that injects authentication, validates requests through server interceptors, and publishes audit and quality telemetry.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  Agent["AI agent"] --> Config["MCP config file"]
  Agent --> Middleware["gRPC middleware"]
  Marketplace["MCP Marketplace registry"] --> Installer["CLI installer"]
  Installer --> Config
  Installer --> Vault["Keychain vault"]
  Pipeline["Producer CI/CD pipeline"] --> Registry["Docker registry"]
  Pipeline --> Marketplace
  Registry --> Installer
  Middleware --> Marketplace
  Middleware --> Vault
  Middleware --> Local["Local MCP service"]
  Middleware --> Remote["Remote MCP service"]
  Local --> ServerInterceptor["Server-side interceptor"]
  Remote --> ServerInterceptor
  ServerInterceptor --> Marketplace
  Middleware --> Analytics["Analytics collector"]
  Marketplace --> Analytics

Components

Data flow

MCP producers onboard a service into the marketplace, generate a repository and CI/CD pipeline, build a Docker image, pass security scanning, tag releases, and publish approved images. Consumers search the marketplace, run a CLI installer, and get either a local artifact or remote service URL written into an MCP config. At runtime, the agent reads the config, connects to gRPC middleware, retrieves tokens from keychain, starts local MCPs or connects to remote MCPs, injects authentication headers, and sends telemetry to analytics.

Why this architecture

Intuit used a marketplace and middleware architecture because enterprise MCP scaling is both a developer-experience and governance problem. A central registry fixes discoverability and standardization; CI/CD and security scanning shift quality checks into publishing; a CLI, keychain, and middleware remove local setup friction; and gRPC interceptors centralize authentication, authorization, auditing, and telemetry without every MCP implementing those concerns independently.

Models used: AI agents · LLMs using MCP services

Scale

• Intuit serves millions of consumers and small businesses globally.
  “We serve millions of consumers and small businesses globally helping them manage their finances and drive prosperity.”transcript, stated
• The platform targets organization-wide scaling of AI agents and MCP infrastructure across developers.
  “as organizations embrace AI agents, the challenge shifts from how to build an agent to how to scale the agent infrastructure across their developers.”transcript, stated
• The middleware monitors every gRPC request flowing to and from MCPs.
  “It continuously monitors every single gRPC request that flows to and from the MCPS allowing it to infer the tool usage and latency”transcript, stated
• The analytics layer tracks installations, invocation frequency, latency, error rates, adoption, and quality.
  “it tracks the service installation to identify which MCP services are gaining more traction in the organization. Next, it measures the tool invocation frequency”transcript, stated

  “monitors the realtime service latency and gRPC error rates so that it can ensure the consistent performance and reliability”transcript, stated

Alternatives considered (roads not taken)

Decentralized context-service discovery

Rejected because: Without a central registry, teams duplicated work and could not see existing MCP services.

Let each MCP service handle security and quality independently

Rejected because: A lack of standards and quality gates risks buggy, unverified, or non-compliant context reaching LLMs.

Store credentials in MCP configuration files

Rejected because: The installer stores secrets in a platform-native vault to avoid exposing tokens locally.

Support only local MCP services

Rejected because: The installer accounts for both local containerized MCPs and remote MCPs deployed in the cloud.

Patterns

context-engineering (context_management)

The platform makes organizational context discoverable, secure, and installable so agents can retrieve the exact codebase, API, database, policy, or workflow context they need.

tool-use-orchestration (tooling)

The marketplace packages MCP services as installable context tools and lets middleware route agent requests to local or remote MCP services.

safety-policy-enforcement (control)

Client and server interceptors enforce authentication and authorization before context requests are processed.

observability-tracing (operations)

The middleware collects request telemetry, tool usage, latency, error codes, installation, adoption, and quality metrics for auditability and platform improvement.

eval-driven-development (quality)

Producer publication includes automated quality gates, security scanning, release candidates, and pre-production validation before services are published.

Tradeoffs

Centralize MCP discovery and governance

Chose Internal marketplace with registry, standardized tooling, and quality gates over Decentralized team-by-team MCP discovery and setup.

Rationale: Centralization reduces duplicate work, improves security, and creates consistent distribution and lifecycle management.

Support both local and remote MCP deployment models

Chose Installer and middleware abstraction over local containerized MCPs and remote cloud MCPs over A single deployment model.

Rationale: Different MCP services need different deployment forms, but consumers still need one installation experience.

Use middleware for cross-cutting controls

Chose gRPC middleware and interceptors for auth, token injection, errors, and telemetry over Embedding those controls separately in every MCP service.

Rationale: The middleware centralizes security and auditability while keeping request handling consistent across local and remote services.

Gotchas (what bit them)

Context-service discoverability collapses as teams decentralize MCP development.

Root cause: Teams cannot see what services already exist, so they rebuild similar context-fetching logic independently.

Resolution: Intuit created a searchable central marketplace registry for discovering and installing MCP services.

Unverified context services can create governance and behavior risk.

Root cause: No standards or quality gates means non-compliant MCP services can feed critical context to LLMs.

Resolution: The marketplace adds standardized tooling, CI/CD, security scanning, and automated quality gates.

Manual MCP setup slows agent adoption.

Root cause: Developers face local runtime configuration and secret-management complexity.

Resolution: The CLI installer writes config, handles local or remote setup, and stores credentials in the native vault.

Centralizing MCP access creates platform-dependency risk.

Root cause: The marketplace and middleware become shared infrastructure for all agent context requests.

Resolution: The source describes telemetry and quality monitoring, but does not describe availability or disaster-recovery guarantees.

Evaluation

Intuit measures marketplace success by instrumenting installs, tool invocation frequency, service latency, gRPC error rates, adoption trends, quality metrics, and audit logs linking agents, users, and contextual data access.

Metrics: service installation counts · tool invocation frequency · real-time service latency · gRPC error rates · adoption trends · quality metrics · which agent and user accessed what contextual data

Outcomes

• The marketplace provides one-command installation for MCP consumers.
• MCP producers get standardized CI/CD, versioning, security scanning, and release publication.
• Sensitive tokens are kept out of config files and local host exposure.
• Every context access can be authenticated, authorized, logged, and measured.
• The platform turns internal MCP services into reusable organizational capabilities rather than siloed team implementations.

The platform is designed for Intuit's global fintech developer organization, supports both local and remote MCPs, and tracks every gRPC context request for usage, latency, errors, and auditability.