docs: Fix typos

Author: nbarbettini

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

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