Remove .mdx suffixes from internal doc links for Mintlify (#1052)

These docs are synced to modelcontextprotocol.io which uses Mintlify for
rendering. Mintlify routes are extension-less, so links like
`./package-types.mdx` produce 404s on the live site. Dropping the `.mdx`
suffix fixes those broken links. The trade-off is that the links no
longer resolve when browsing the raw files on GitHub.

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

docs/modelcontextprotocol-io/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/modelcontextprotocol-io/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/modelcontextprotocol-io/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/modelcontextprotocol-io/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