Merge pull request modelcontextprotocol#882 from ArcadeAI/nbarbettini/errata-1

docs: Fix typos, update links

Author: dsp-ant

README.md

@@ -2,8 +2,8 @@
 
 This repo contains the specification and protocol schema for the Model Context Protocol.
 
-The schema is [defined in TypeScript](schema/2025-03-26/schema.ts) first, but
-[made available as JSON Schema](schema/2025-03-26/schema.json) as well, for wider
+The schema is [defined in TypeScript](schema/2025-06-18/schema.ts) first, but
+[made available as JSON Schema](schema/2025-06-18/schema.json) as well, for wider
 compatibility.
 
 The official MCP documentation is built using Mintlify and available at

docs/specification/draft/basic/authorization.mdx

@@ -367,7 +367,7 @@ A MCP server **MUST** follow the guidelines in [OAuth 2.1 - Section 5.2](https:/
 
 MCP servers **MUST** only accept tokens specifically intended for themselves and **MUST** reject tokens that do not include them in the audience claim or otherwise verify that they are the intended recipient of the token. See the [Security Best Practices Token Passthrough section](/specification/draft/basic/security_best_practices#token-passthrough) for details.
 
-If the MCP server makes requests to upstream APIs, it may act as an OAuth client to them. The access token used at the upstream API is a seperate token, issued by the upstream authorization server. The MCP server **MUST NOT** pass through the token it received from the MCP client.
+If the MCP server makes requests to upstream APIs, it may act as an OAuth client to them. The access token used at the upstream API is a separate token, issued by the upstream authorization server. The MCP server **MUST NOT** pass through the token it received from the MCP client.
 
 MCP clients **MUST** implement and use the `resource` parameter as defined in [RFC 8707 - Resource Indicators for OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707.html)
 to explicitly specify the target resource for which the token is being requested. This requirement aligns with the recommendation in

docs/specification/draft/basic/security_best_practices.mdx

@@ -8,7 +8,7 @@ title: Security Best Practices
 
 ### Purpose and Scope
 
-This document provides security considerations for the Model Context Protocol (MCP), complementing the MCP Authorization specification. This document identifies security risks, attack vectors, and best practices specific to MCP implementations.
+This document provides security considerations for the Model Context Protocol (MCP), complementing the [MCP Authorization](../basic/authorization.mdx) specification. This document identifies security risks, attack vectors, and best practices specific to MCP implementations.
 
 The primary audience for this document includes developers implementing MCP authorization flows, MCP server operators, and security professionals evaluating MCP-based systems. This document should be read alongside the MCP Authorization specification and [OAuth 2.0 security best practices](https://datatracker.ietf.org/doc/html/rfc9700).
 
@@ -26,7 +26,7 @@ Attackers can exploit MCP servers proxying other resource servers, creating "[co
 : An MCP server that connects MCP clients to third-party APIs, offering MCP features while delegating operations and acting as a single OAuth client to the third-party API server.
 
 **Third-Party Authorization Server**
-: Authorization server that protects the third-party API. It may lack dynamic client registration support, requiring MCP proxy to use a static client ID for all requests.
+: Authorization server that protects the third-party API. It may lack dynamic client registration support, requiring the MCP proxy to use a static client ID for all requests.
 
 **Third-Party API**
 : The protected resource server that provides the actual API functionality. Access to this
@@ -108,9 +108,9 @@ attack becomes possible:
 3. An attacker later sends the user a malicious link containing a crafted authorization request which contains a malicious redirect URI along with a new dynamically registered client ID
 4. When the user clicks the link, their browser still has the consent cookie from the previous legitimate request
 5. The third-party authorization server detects the cookie and skips the consent screen
-6. The MCP authorization code is redirected to the attacker's server (specified in the crafted redirect_uri during dynamic client registration)
+6. The MCP authorization code is redirected to the attacker's server (specified in the malicious `redirect_uri` parameter during [dynamic client registration](/specification/draft/basic/authorization#dynamic-client-registration))
 7. The attacker exchanges the stolen authorization code for access tokens for the MCP server without the user's explicit approval
-8. Attacker now has access to the third-party API as the compromised user
+8. The attacker now has access to the third-party API as the compromised user
 
 #### Mitigation
 
@@ -119,7 +119,7 @@ registered client before forwarding to third-party authorization servers (which
 
 ### Token Passthrough
 
-"Token passthrough" is an anti-pattern where an MCP server accepts tokens from an MCP client without validating that the tokens were properly issued _to the MCP server_ and "passing them through" to the downstream API.
+"Token passthrough" is an anti-pattern where an MCP server accepts tokens from an MCP client without validating that the tokens were properly issued _to the MCP server_ and passes them through to the downstream API.
 
 #### Risks
 

docs/specification/draft/index.mdx

@@ -64,7 +64,7 @@ Servers offer any of the following features to clients:
 Clients may offer the following features to servers:
 
 - **Sampling**: Server-initiated agentic behaviors and recursive LLM interactions
-- **Roots**: Server-initiated inquiries into uri or filesystem boundaries to operate in
+- **Roots**: Server-initiated inquiries into URI or filesystem boundaries to operate in
 - **Elicitation**: Server-initiated requests for additional information from users
 
 ### Additional Utilities