Sweep 22 Sep 2026 · 17:19Z Build v2.1.280 501 read Stable v2.1.267 Latest v2.1.280 Next v2.1.280 Feeds RSS JSON llms.txt Unofficial
One capture · mcp

One read of Model Context Protocol

2 pages moved out of 344 read.

mcp-20260830T223705Z

Pages moved 2 significant first
Pages read 344 in this capture
Captured 22:37 UTC
Corpus hash c1af3234cb29 corpus-hash

What this read moved

1–2 of 2

community/interest-groups/enterprise New page · 108 lines, new page

# Enterprise Interest Group Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups #### Working Groups #### Interest Groups ## Leadership ## Membership ## Operations ### Decision Process for Recommendations ## Deliverables (Optional) ## Changelog

A whole new page. There's nothing to diff it against, so here is what it says.

# Enterprise Interest Group Charter

> Charter for the MCP Enterprise Interest Group.

## Group Type

**Interest Group**

## Mission Statement

The Enterprise IG identifies and documents the requirements gaps that enterprises encounter when deploying MCP in production. As MCP adoption scales across regulated industries and large organizations, enterprise teams face recurring gaps in areas such as authentication integration, identity propagation, audit and compliance, gateway behavior, scalability and resilience, and configuration management that are not yet addressed at the protocol level. The group brings together enterprise practitioners to capture these gaps as problem statements and structured recommendations, and to channel them to the relevant Working Groups for specification work. Governance and best-practice patterns may emerge from these discussions, but the group’s core mandate is surfacing protocol-level requirements, not maintaining a general best-practices catalog.

All discussions and sessions are protocol-focused and vendor-neutral. The Enterprise IG is not a venue for product pitches or vendor-specific marketing. Participants contribute as practitioners sharing deployment experience and requirements, not as representatives promoting commercial solutions.

## Scope

### In Scope

* **Enterprise Requirements Gaps (overarching focus)**: The group’s primary mandate is identifying enterprise deployment requirements that are not addressed at the MCP protocol level today and turning them into problem statements and recommendations for the relevant Working Groups. Each requirement is captured with the enterprise opportunity it represents, not only the pain point, since closing these gaps is what unlocks broader enterprise adoption and value. The specific domains below are explored through that lens; governance and best-practice patterns are documented only where they surface a protocol-level gap:
* **Enterprise Authentication and Identity**: Discussion of enterprise-managed auth patterns including IdP integration (SSO, SAML, OIDC), token lifecycle management, On-Behalf-Of (OBO) token exchange flows, and fine-grained authorization (Rich Authorization Requests). Gathering requirements to inform the Auth WG and related SEPs.
* **Identity Propagation and Session Context**: Defines how verified identity is surfaced and conveyed across MCP clients, servers, and downstream services for policy enforcement and audit. This includes spawned-agent and delegated-agent use cases: identity lineage, least-privilege for child agents, descendant revocation, and auditability across multi-agent chains, which is adjacent to authentication but distinct in focus.
* **Audit, Observability, and Compliance**: Exploration of standardized audit trail formats for MCP tool invocations, integration with enterprise SIEM and observability platforms, and evidence generation for compliance frameworks (SOC 2, HIPAA, GDPR, EU AI Act). Includes sector-specific compliance patterns such as PHI handling and BAA-scoped data flows in healthcare environments.
* **Gateway and Proxy Behavior**: Documentation of enterprise deployment patterns where MCP traffic routes through API gateways, load balancers, reverse proxies, and security proxies. With the move to a stateless protocol core in the 2026-07-28 release, the focus shifts from session affinity to gaps that persist in a stateless model: header and context propagation, authorization handoff across proxies, and policy enforcement at the gateway.
* **Scalability and Resilience**: Running MCP at enterprise scale across regions and availability zones. With the stateless core enabling horizontal scaling without sticky sessions, the focus is on failover, load distribution, and reliability for mission-critical deployments.
* **MCP in Enterprise Architecture**: Definition of how MCP fits into broader enterprise architecture, including integration with existing middleware, data platforms, and agent orchestration layers.
* **Configuration Portability and Deployment**: Discussion of challenges in deploying MCP servers across heterogeneous client environments, multi-tenant configuration patterns, and enterprise-scale rollout practices.
* **Interceptors and Middleware**: Exploration of use cases for request/response interception in MCP pipelines, including PII redaction, compliance validation, content filtering, and hallucination detection. Gathering requirements that may inform future specification work on middleware patterns.
* **Problem Statements and Use Cases**: Documentation of enterprise pain points and production failure scenarios (anonymized) to build an evidence base for prioritizing specification work.
* **Recommendations to Working Groups**: Providing structured input from enterprise practitioners to the Auth WG, Security IG, Gateways IG, and other groups on enterprise-specific requirements.

### Out of Scope

* Writing or owning SEPs. The Enterprise IG produces problem statements, use cases, and recommendations. Concrete specification changes are driven through the appropriate Working Groups.
* Discussion of product-specific or vendor-specific solutions. Discussions must remain vendor-neutral and focused on protocol-level patterns.
* General MCP support or onboarding. The group focuses on enterprise deployment challenges, not introductory MCP topics.
* Overlapping directly with the Auth WG's specification work. The Enterprise IG gathers enterprise auth requirements and feeds them to the Auth WG rather than proposing auth protocol changes.

### Related Groups

#### Working Groups

* **Auth WG** — Enterprise auth requirements (IdP integration, OBO flows, RAR) are gathered and provided as input to the Auth WG's specification work.
* **Transport WG** — Transport-level needs for enterprise support (non-functional requirements such as latency and horizontal scaling) are bundled and provided as input to the Transport WG.
* **Extensions WG** — Requirements for extensions other than authorization are bundled and provided as input to the Extensions WG.

#### Interest Groups

* **Security IG** — Overlapping interest in runtime security, tool poisoning, and credential management. The Enterprise IG focuses on the organizational and governance dimensions; the Security IG focuses on threat models and protocol-level mitigations.
* **Gateways IG** — Direct overlap on gateway/proxy behavior patterns. The Enterprise IG provides enterprise deployment context; the Gateways IG focuses on technical gateway specifications.
* **Financial Services IG** — Several enterprise concerns (compliance, audit, regulated environments) overlap with the FS-IG. Cross-posting and joint sessions will be coordinated where appropriate.

## Leadership

| Role        | Name          | Organization     | GitHub                                                     | Term     |
| ----------- | ------------- | ---------------- | ---------------------------------------------------------- | -------- |
| Facilitator | Raghu Chandra | Independent      | [@raghu-chandra-mcp](https://github.com/raghu-chandra-mcp) | 6 months |
| Facilitator | Yannj\_Fr     | MCPApps Builders | [@yannj-fr](https://github.com/yannj-fr)                   | 6 months |

## Membership

| Name           | Organization                                      | GitHub                                                     | Discord       | Level       |
| -------------- | ------------------------------------------------- | ---------------------------------------------------------- | ------------- | ----------- |
| Raghu Chandra  | Independent                                       | [@raghu-chandra-mcp](https://github.com/raghu-chandra-mcp) | raghu.chandra | Facilitator |
| Yannj\_Fr      | MCPApps Builders                                  | [@yannj-fr](https://github.com/yannj-fr)                   | yannj\_fr     | Facilitator |
| Peder H P      | Saxo Bank                                         | [@pederhp](https://github.com/pederhp)                     |               | Participant |
| Derek Lewis    | Silex Data Solutions                              | [@derekelewis](https://github.com/derekelewis)             | dlewis.io     | Participant |
| Aman s         | Independent Researcher; Blue Shield of California | [@aman210122](https://github.com/aman210122)               |               | Participant |
| Ola            | Nordstrom / MCP Maintainer                        | [@olaservo](https://github.com/olaservo)                   |               | Participant |
| Varun          | TraceForce                                        | [@vawadhwa88](https://github.com/vawadhwa88)               |               | Participant |
| Markus Mueller | Boomi                                             | [@mquadrat](https://github.com/mquadrat)                   |               | Participant |
| Aaron Parecki  | Okta                                              | [@aaronpk](https://github.com/aaronpk)                     |               | Participant |
| cayerbe        | GNS-Foundation                                    | [@GNS-Foundation](https://github.com/GNS-Foundation)       | cayerbe       | Participant |
| Anishma        | EmpowerID                                         | [@anishma](https://github.com/anishma)                     |               | Participant |
| Lin Sun        | Solo.io                                           | [@linsun](https://github.com/linsun)                       |               | Participant |
| Joey Orlando   | Archestra                                         | [@joeyorlando](https://github.com/joeyorlando)             |               | Participant |

## Operations

| Meeting         | Frequency | Duration | Purpose                                                              |
| --------------- | --------- | -------- | -------------------------------------------------------------------- |
| Working Session | Monthly   | 60 min   | Use case discussion, pain point cataloging, cross-group coordination |

Discord: #enterprise-ig

### Decision Process for Recommendations

The Enterprise IG produces non-binding use cases, problem statements, and functional and non-functional requirements. To ensure clarity and avoid downstream process debates, the following applies:

* **Problem statements and use cases** are contributed asynchronously via GitHub Discussions or Discord threads and reviewed during monthly meetings.
* **Recommendations to Working Groups** are finalized through lazy consensus among participants, with a 7-day review period posted on GitHub. If no objections are raised, the recommendation is considered approved.
* **Facilitators** are responsible for packaging approved recommendations and delivering them to the relevant Working Group or Interest Group.

## Deliverables (Optional)

As an Interest Group, the Enterprise IG does not produce binding deliverables. The following are planned discussion outputs:

| Item                                            | Status  | Target Date | Champion      |
| ----------------------------------------------- | ------- | ----------- | ------------- |
| Enterprise Pain Points Catalog                  | Planned | Q2 2026     | Raghu Chandra |
| Healthcare & Compliance Use Cases (PHI, BAA)    | Planned | Q3 2026     | Aman s        |
| Enterprise Auth Requirements (input to Auth WG) | Planned | Q3 2026     | TBD           |
| Gateway Deployment Patterns Document            | Planned | Q3 2026     | TBD           |

## Changelog

| Date       | Change                |
| ---------- | --------------------- |
| 2026-04-13 | Initial charter filed |

registry/package-types Changed · +51 / -0 lines

## Cargo (Rust) Packages ### Runtime Model

from line 122
122122<!-- mcp-name: io.github.username/azure-devops-mcp -->
123123```
124124 
125## Cargo (Rust) Packages
126 
127For Cargo packages, the MCP Registry currently supports the official crates.io registry (`https://crates.io`) only.
128 
129Cargo packages use `"registryType": "cargo"` in `server.json`. For example:
130 
131```json server.json highlight={9} theme={null}
132{
133 "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
134 "name": "io.github.username/widget-mcp",
135 "title": "Widget",
136 "description": "Rust-native MCP server",
137 "version": "0.3.0",
138 "packages": [
139 {
140 "registryType": "cargo",
141 "identifier": "widget-mcp",
142 "version": "0.3.0",
143 "transport": {
144 "type": "stdio"
145 }
146 }
147 ]
148}
149```
150 
151### Runtime Model
152 
153Cargo's runtime model differs from npm/PyPI/NuGet. `cargo install <crate>` places the compiled binary on PATH at `~/.cargo/bin`, after which MCP clients invoke it directly by name. There is no per-invocation runner equivalent to `npx` (npm), `uvx` (PyPI), or `dnx` (NuGet, .NET 10 SDK Preview 6+) — install is one-time, execution is by binary name. The Cargo example above intentionally omits `runtimeHint` for this reason.
154 
155Rust MCP authors have two first-class distribution paths:
156 
157* **Cargo (`registryType: cargo`)** — source-distributed via crates.io. End users need the Rust toolchain (`rustup`) to run `cargo install`. Idiomatic for the Rust ecosystem and consistent with how Rust CLIs are typically published.
158* **MCPB (`registryType: mcpb`)** — prebuilt binary distributed via GitHub or GitLab Releases. End users need no toolchain. Right choice if the priority is "no Rust toolchain required."
159 
160Both paths are supported; the choice is the author's. Cargo native support exists so Rust authors who prefer source distribution are not forced into the MCPB binary-packaging workaround.
161 
162### Ownership Verification
163 
164The MCP Registry verifies ownership of Cargo packages by checking for the existence of an `mcp-name: $SERVER_NAME` string in the package README (which is rendered to HTML and served by crates.io's static CDN). The `$SERVER_NAME` portion **MUST** match the server name from `server.json`. For example:
165 
166```markdown README.md highlight={5} theme={null}
167# Widget MCP Server
168 
169A Rust-native MCP server for widget operations.
170 
171- MCP Registry name: `mcp-name: io.github.username/widget-mcp`
172```
173 
174**Cargo-specific gotcha:** Unlike PyPI and NuGet (which preserve HTML comments in their README rendering), **crates.io strips HTML comments during markdown→HTML conversion**. The `<!-- mcp-name: ... -->` hidden-comment form that works for PyPI/NuGet **does not work for cargo** — the token will not appear in the rendered HTML the validator inspects. Cargo authors must include the `mcp-name:` token as visible markdown text. A simple bullet in the Links section is the recommended pattern.
175 
125176## Docker/OCI Images
126177 
127178For Docker/OCI images, the MCP Registry currently supports: