Merge branch 'main' into feat/task-jumpscares

Author: LucaButBoring

.github/workflows/slash-commands.yml

@@ -0,0 +1,47 @@
+name: Slash Commands
+
+on:
+  issue_comment:
+    types: [created]
+  pull_request_target:
+    types: [synchronize, opened, reopened, labeled, unlabeled]
+
+permissions:
+  pull-requests: write
+  issues: write
+  contents: read
+
+jobs:
+  # Parse and execute /lgtm, /hold, /unhold comment commands; invalidate
+  # approval when new commits are pushed.
+  handle:
+    if: >-
+      (github.event_name == 'issue_comment' && github.event.issue.pull_request) ||
+      (github.event_name == 'pull_request_target' && github.event.action == 'synchronize')
+    runs-on: ubuntu-latest
+    steps:
+      - uses: modelcontextprotocol/actions/slash-commands@main
+        with:
+          github-token: ${{ secrets.SLASH_COMMANDS_TOKEN }}
+          always-allow-teams: core-maintainers,lead-maintainers
+
+  # Merge-gate status check — make "Slash Commands / status" a required
+  # check in branch protection so the labels become enforceable.
+  status:
+    if: github.event_name == 'pull_request_target'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Require approval, block on hold
+        env:
+          LABELS: ${{ toJson(github.event.pull_request.labels.*.name) }}
+        run: |
+          echo "Labels: $LABELS"
+          if ! jq -e 'contains(["approved"])' <<<"$LABELS" > /dev/null; then
+            echo "::error::Missing 'approved' label — have a maintainer or CODEOWNER comment /lgtm"
+            exit 1
+          fi
+          if jq -e 'contains(["do-not-merge/hold"])' <<<"$LABELS" > /dev/null; then
+            echo "::error::'do-not-merge/hold' present — resolve concerns, then comment /unhold"
+            exit 1
+          fi
+          echo "✅ approved and not held"

blog/content/posts/2026-03-11-understanding-mcp-extensions.md

@@ -0,0 +1,65 @@
++++
+date = '2026-03-11T00:00:00Z'
+title = 'Understanding MCP Extensions'
+author = 'MCP Community Maintainers'
+tags = ['announcement', 'community']
++++
+
+You've built an MCP server that works quite well, but now you're wondering: _How do I add richer UI elements? Custom auth flows? What about domain-specific conventions, like those for finance or healthcare?_
+
+This is where _extensions_ come in. They let developers layer new capabilities on top of the baseline MCP implementation without touching the core protocol. This allows us to keep things stable while also opening up room to experiment, learn, and build with the community's needs in mind.
+
+In this post, we'll walk through how extensions fit into the MCP ecosystem and share some patterns the community is already exploring. Think of this less as a formal specification change and more as a short practical guide to extending MCP.
+
+## How MCP is structured
+
+It helps to think of MCP in three layers:
+
+- **MCP core specification:** [The protocol itself](https://modelcontextprotocol.io/specification/latest). This is how clients and servers talk to each other. It also represents the absolute minimum bar for client and server interoperability.
+- **MCP projects:** Supporting infrastructure like the [Registry](https://registry.modelcontextprotocol.io/), that helps developers discover MCP servers, or [Inspector](https://modelcontextprotocol.io/docs/tools/inspector), that makes MCP server testing and debugging easier.
+- **MCP extensions:** Optional patterns that developers can adopt for specialized use cases, built on top of the MCP core specification.
+
+Extensions let the ecosystem grow and give us an avenue to test changes and emerging spec components without destabilizing the core protocol that lots of production clients and servers already depend on.
+
+The [Extensions documentation](https://modelcontextprotocol.io/extensions/overview) covers the full details — including extension identifiers, capability negotiation during the initialization handshake, and the SEP (Specification Enhancement Proposal) process for proposing new ones.
+
+Here's where it gets interesting. Extensions are **patterns built on existing MCP mechanisms**, and they're strictly additive: a client or server that doesn't recognize an extension simply skips it during negotiation, and the baseline protocol keeps working. Nothing breaks when one side hasn't opted in.
+
+In practice, a few of these patterns have already emerged — some now formalized as official extensions, others still exploratory:
+
+- **UI extensions:** Imagine a server that returns not just data, but an interactive interface for working with it — a chart you can filter, a form you can submit, a dashboard you can drill into. That's what [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview) enables. It's the first official MCP extension and [went GA in January 2026](https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/), with support already live in ChatGPT, Claude, VS Code, Goose, and [more](https://modelcontextprotocol.io/extensions/client-matrix).
+- **Authorization extensions:** Need machine-to-machine auth without a user in the loop, or centralized enterprise IdP control? The [auth extensions](https://modelcontextprotocol.io/extensions/auth/overview) layer these on top of MCP's core OAuth framework — OAuth Client Credentials and Enterprise-Managed Authorization are both live today.
+- **Domain-specific extensions:** Community groups are already exploring conventions for verticals like financial services, where developers might want standardized ways to handle compliance metadata.
+
+Another important side-effect to this approach is that MCP client and server developers get richer functionality without having to wait for protocol changes, which might need more extensive validation before being merged into the core.
+
+Extensions are also _the way_ to validate future protocol changes - if a particular implementation gains traction, that signals that there is a growing community need in protocol functionality that could become a part of the specification.
+
+### How extensions are governed
+
+Extensions are community-driven, and **all of them are optional**. Developers adopt what makes sense for their use case.
+
+At the same time, we encourage implementing official and recommended extensions when possible. It helps the whole ecosystem work better together. Official extensions typically start as conversations between MCP contributors, both on the core team and in the broader community, before graduating to the [Model Context Protocol GitHub organization](https://github.com/modelcontextprotocol) where they're maintained collaboratively, following the [Extensions Track SEP process](https://modelcontextprotocol.io/seps/2133-extensions).
+
+Beyond officially-supported extensions, community members and working groups are also free to define their own extensions for any custom needs.
+
+### A note on proprietary integrations
+
+Some MCP clients ship their own proprietary features, like custom UI systems, that happen to use MCP under the hood. These are **not necessarily** considered MCP extensions. They integrate with MCP servers but they don't define how MCP itself behaves at the protocol level. We will work with client and server implementers to help them adopt extensions as the de-facto way to implement custom behaviors.
+
+## Get started
+
+If you're building on MCP and want to explore extensions:
+
+- **Read the docs:** The [Extensions overview](https://modelcontextprotocol.io/extensions/overview) covers identifiers, negotiation, governance, and the full list of official extensions.
+- **Build an MCP App:** Follow the [MCP Apps quickstart](https://modelcontextprotocol.io/extensions/apps/build) to ship an interactive UI that works across supporting clients today.
+- **Check client support:** See the [Extension Support Matrix](https://modelcontextprotocol.io/extensions/client-matrix) for which clients already implement which extensions.
+- **Propose your own:** If you have an idea for a new extension, the [SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines) walk you through opening an Extensions Track SEP.
+
+## Thank you
+
+This post wouldn't exist without the [MCP community](https://modelcontextprotocol.io/community/communication). The ideas here grew out of countless conversations - working group calls, GitHub threads, extension proposals, and plenty of back-and-forth in [Discord](https://modelcontextprotocol.io/community/communication#discord).
+
+To everyone who's contributed ideas, challenged our initial assumptions, and helped shape where this is all going: thank you.
+
+We'll keep sharing updates here on the blog and in the [public repos](https://github.com/modelcontextprotocol). See you there.

docs/extensions/apps/build.mdx

@@ -60,6 +60,7 @@ And then copying the skill to the appropriate location for your agent:
 | [Cline](https://cline.bot/blog/cline-3-48-0-skills-and-websearch-make-cline-smarter)                                                                                         | `~/.cline/skills/`             | `%USERPROFILE%\.cline\skills\`        |
 | [Goose](https://block.github.io/goose/docs/guides/context-engineering/using-skills/)                                                                                         | `~/.config/goose/skills/`      | `%USERPROFILE%\.config\goose\skills\` |
 | [Codex](https://developers.openai.com/codex/skills/)                                                                                                                         | `~/.codex/skills/`             | `%USERPROFILE%\.codex\skills\`        |
+| [Cursor](https://cursor.com/docs/context/skills)                                                                                                                             | `~/.cursor/skills/`            | `%USERPROFILE%\.cursor\skills\`       |
 
 <Note>
 

docs/registry/about.mdx

@@ -37,7 +37,7 @@ The MCP Registry hosts metadata that points to those packages.
 
 For example, a `weather-mcp` package could be hosted on npm, and metadata in the MCP Registry could map the "weather v1.2.0" server to `npm:weather-mcp`.
 
-The [Package Types guide](./package-types.mdx) lists the supported package types and registries. More package registries may be supported in the future based on community demand. If you are interested in building support for a package registry, please [open an issue](https://github.com/modelcontextprotocol/registry).
+The [Package Types guide](./package-types) lists the supported package types and registries. More package registries may be supported in the future based on community demand. If you are interested in building support for a package registry, please [open an issue](https://github.com/modelcontextprotocol/registry).
 
 ### Relationship with Server Developers
 
@@ -51,7 +51,7 @@ The MCP Registry is intended to be consumed primarily by downstream aggregators,
 
 The metadata hosted by the MCP Registry is deliberately unopinionated. Downstream aggregators can provide curation or additional metadata such as community ratings.
 
-We expect that downstream aggregators will use the MCP Registry API to pull new metadata on a regular but infrequent basis (for example, once per hour). See the [MCP Registry Aggregators guide](./registry-aggregators.mdx) for more information.
+We expect that downstream aggregators will use the MCP Registry API to pull new metadata on a regular but infrequent basis (for example, once per hour). See the [MCP Registry Aggregators guide](./registry-aggregators) for more information.
 
 ### Relationship with Other MCP Registries
 
@@ -71,7 +71,7 @@ The MCP Registry is not intended to be directly consumed by host applications. I
 
 The MCP Registry uses namespace authentication to ensure that servers come from their claimed sources. Server names follow a reverse DNS format (like `io.github.username/server` or `com.example/server`) that ties them to verified GitHub accounts or domains.
 
-This namespace system ensures that only the legitimate owner of a GitHub account or domain can publish servers under that namespace, providing trust and accountability in the ecosystem. For details on authentication methods, see the [Authentication guide](./authentication.mdx).
+This namespace system ensures that only the legitimate owner of a GitHub account or domain can publish servers under that namespace, providing trust and accountability in the ecosystem. For details on authentication methods, see the [Authentication guide](./authentication).
 
 ### Security Scanning
 
@@ -88,6 +88,6 @@ The MCP Registry uses multiple mechanisms to prevent spam:
 
 - **Namespace authentication requirements** — Publishers must verify ownership of their namespace through GitHub, DNS, or HTTP challenges, preventing arbitrary spam submissions.
 - **Character limits and validation** — Free-form fields have strict character limits and regex validation to prevent abuse.
-- **Manual takedown** — The registry maintainers can manually remove spam or malicious servers. See the [Moderation Policy](./moderation-policy.mdx) for details on what content is removed.
+- **Manual takedown** — The registry maintainers can manually remove spam or malicious servers. See the [Moderation Policy](./moderation-policy) for details on what content is removed.
 
 Future spam prevention measures under consideration include stricter rate limiting, AI-based spam detection, and community reporting capabilities.

docs/registry/github-actions.mdx

@@ -220,6 +220,6 @@ The workflow will run tests, build the package, publish the package to npm, and
 | Error Message | Action |
 | --- | --- |
 | "Authentication failed" | Ensure `id-token: write` permission is set for OIDC, or check secrets. |
-| "Package validation failed" | Verify your package successfully published to the package registry (e.g., npm, PyPI), and that your package has the [necessary verification information](./package-types.mdx). |
+| "Package validation failed" | Verify your package successfully published to the package registry (e.g., npm, PyPI), and that your package has the [necessary verification information](./package-types). |
 
 {/* prettier-ignore-end */}

docs/registry/quickstart.mdx

@@ -13,7 +13,7 @@ This tutorial will show you how to publish an MCP server written in TypeScript t
 
 - **Node.js** — This tutorial assumes the MCP server is written in TypeScript.
 - **npm account** — The MCP Registry only hosts metadata, not artifacts. Before publishing to the MCP Registry, we will publish the MCP server's package to npm, so you will need an [npm](https://www.npmjs.com) account.
-- **GitHub account** — The MCP Registry supports [multiple authentication methods](./authentication.mdx). For simplicity, this tutorial will use GitHub-based authentication, so you will need a [GitHub](https://github.com/) account.
+- **GitHub account** — The MCP Registry supports [multiple authentication methods](./authentication). For simplicity, this tutorial will use GitHub-based authentication, so you will need a [GitHub](https://github.com/) account.
 
 If you do not have an MCP server written in TypeScript, you can copy the `weather-server-typescript` server from the [`modelcontextprotocol/quickstart-resources` repository](https://github.com/modelcontextprotocol/quickstart-resources) to follow along with this tutorial:
 
@@ -287,7 +287,7 @@ You should see your server's metadata in the search results JSON:
 
 ## Next Steps
 
-- Learn about [support for other package types](./package-types.mdx).
-- Learn about [support for remote servers](./remote-servers.mdx).
-- Learn how to [use other authentication methods](./authentication.mdx), such as [DNS authentication](./authentication.mdx#dns-authentication) which enables custom domains for server name prefixes.
-- Learn how to [automate publishing with GitHub Actions](./github-actions.mdx).
+- Learn about [support for other package types](./package-types).
+- Learn about [support for remote servers](./remote-servers).
+- Learn how to [use other authentication methods](./authentication), such as [DNS authentication](./authentication#dns-authentication) which enables custom domains for server name prefixes.
+- Learn how to [automate publishing with GitHub Actions](./github-actions).

docs/registry/registry-aggregators.mdx

@@ -69,7 +69,7 @@ curl "https://registry.modelcontextprotocol.io/v0.1/servers?updated_since=2025-1
 
 Server metadata is generally immutable, except for the `status` field which may be updated to, e.g., `"deprecated"` or `"deleted"`. We recommend that aggregators keep their copy of each server's `status` up to date.
 
-The `"deleted"` status typically indicates that a server has violated our permissive [moderation policy](./moderation-policy.mdx), suggesting the server might be spam, malware, or illegal. Aggregators may prefer to remove these servers from their index.
+The `"deleted"` status typically indicates that a server has violated our permissive [moderation policy](./moderation-policy), suggesting the server might be spam, malware, or illegal. Aggregators may prefer to remove these servers from their index.
 
 ## Acting as a Subregistry