(chore): Documentation updates (modelcontextprotocol#2097)

localden · web-flow · commit cbad1d24c8f8 · 2026-01-16T01:18:46.000Z
* Updates.

* Fix typos and improve clarity in documentation

Corrected various typographical errors, improved grammar, and clarified language across multiple documentation files. These changes enhance readability and ensure consistency in the project's documentation.

* Fix typos and improve clarity in Java SDK docs

Corrected several typos and improved phrasing in the MCP Java SDK documentation files for client, server, and overview. Changes include fixing grammar, clarifying descriptions, and ensuring consistency in terminology.
diff --git a/docs/clients.mdx b/docs/clients.mdx
@@ -252,7 +252,7 @@ This page provides an overview of applications that support the Model Context Pr
 
 <Note>
 
-This list is maintained by the community. If you notice any inaccuracies or would like to update information about MCP support in your application, please submit a pull request or [open an issue in our documentation repository](https://github.com/modelcontextprotocol/modelcontextprotocol/issues).
+This list is maintained by the community. If you notice any inaccuracies or would like to add or update information about MCP support in your application, please [submit a pull request](https://github.com/modelcontextprotocol/modelcontextprotocol/pulls).
 
 </Note>
 
@@ -1362,7 +1362,7 @@ MCPHub is a powerful Neovim plugin that integrates MCP (Model Context Protocol)
 - Install, configure and manage MCP servers with an intuitive UI.
 - Built-in Neovim MCP server with support for file operations (read, write, search, replace), command execution, terminal integration, LSP integration, buffers, and diagnostics.
 - Create Lua-based MCP servers directly in Neovim.
-- Inegrates with popular Neovim chat plugins Avante.nvim and CodeCompanion.nvim
+- Integrates with popular Neovim chat plugins Avante.nvim and CodeCompanion.nvim
 
 </McpClient>
 
diff --git a/docs/community/communication.mdx b/docs/community/communication.mdx
@@ -38,13 +38,13 @@ The Discord server will have both public and private channels.
   - MCP user support: participants are expected to read official documentation and start new GitHub Discussions for questions or support.
   - Service or product marketing: interactions on this Discord are expected to be vendor-neutral and not used for brand-building or sales. Mentions of brands or products are discouraged outside of being used as examples or responses to conversations that start off focused on the specification.
 
-#### Private channels (Exceptions)
+#### Private Channels (Exceptions)
 
 - **Purpose**: Confidential coordination and sensitive matters that cannot be discussed publicly. Access will be restricted to designated maintainers.
 - **Strict criteria for private use**:
   - **Security incidents** (CVEs, protocol vulnerabilities).
   - **People matters** (maintainer-related discussions, code of conduct policies).
-  - Select channels will be configured to be **read-only**. This can be good for example for maintainer decision making.
+  - Select channels will be configured to be **read-only**. This can be useful for maintainer decision-making, for example.
   - Coordination requiring **immediate** or otherwise **focused response** with a limited audience.
 - **Transparency**:
   - **All technical and governance decisions** affecting the community **must be documented** in GitHub Discussions and/or Issues, and will be labeled with `notes`.
diff --git a/docs/community/governance.mdx b/docs/community/governance.mdx
@@ -7,7 +7,7 @@ The Model Context Protocol (MCP) follows a formal governance model to ensure tra
 
 ## General Project Policies
 
-Model Context Protocol has been established as Model Context Protocol a Series of LF Projects, LLC. Policies applicable to Model Context Protocol and participants in Model Context Protocol, including guidelines on the usage of trademarks, are located at [https://www.lfprojects.org/policies/](https://www.lfprojects.org/policies/). Governance changes approved as per the provisions of this governance document must also be approved by LF Projects, LLC.
+Model Context Protocol has been established as **Model Context Protocol a Series of LF Projects, LLC**. Policies applicable to Model Context Protocol and participants in Model Context Protocol, including guidelines on the usage of trademarks, are located at [https://www.lfprojects.org/policies/](https://www.lfprojects.org/policies/). Governance changes approved as per the provisions of this governance document must also be approved by LF Projects, LLC.
 
 Model Context Protocol participants acknowledge that the copyright in all new contributions will be retained by the copyright holder as independent works of authorship and that no contributor or copyright holder will be required to assign copyrights to the project.
 
@@ -42,7 +42,7 @@ Maintainers are responsible for the:
 - Thoughtful and productive engagement with community contributors,
 - Maintaining and improving their respective area of the MCP project,
 - Supporting documentation, roadmaps and other adjacent parts of the MCP project,
-- Present ideas from community to core.
+- Presenting ideas from community to core.
 
 Maintainers are encouraged to propose additional maintainers when needed. Maintainers can only be appointed and removed by core maintainers or lead core maintainers at any time and without reason.
 
@@ -55,7 +55,7 @@ The core maintainers are expected to have a deep understanding of the Model Cont
 - Designing, reviewing and steering the evolution of the MCP specification, as well as all other parts of the MCP project, such as documentation,
 - Articulating a cohesive long-term vision for the project,
 - Mediating and resolving contentious issues with fairness and transparency, seeking consensus where possible while making decisive choices when necessary,
-- Appoint or remove maintainers,
+- Appointing or removing maintainers,
 - Stewardship of the MCP project in the best interest of MCP.
 
 The core maintainers as a group have the power to veto any decisions made by maintainers by majority vote. The core maintainers have power to resolve disputes as they see fit. The core maintainers should publicly articulate their decision-making. The core group is responsible for adopting their own procedures for making decisions.
@@ -157,7 +157,7 @@ If a Maintainer (or Core / Lead Maintainer) wishes to propose a nomination for t
 3. DM a Community Moderator or Core Maintainer to create a private channel in Discord, in the format `nomination-{name}-{group}`. Add all core maintainers, lead maintainers, and co-maintainers on the relevant group.
 4. Provide context for the individual under nomination. See below for suggestions on what to include here.
 5. Create a Discord Poll and ask Core / Lead Maintainers to vote Yes / No on the nomination. Reaching consensus is encouraged though not required.
-6. After Core / Lead Maintainers discuss and/or vote, if the nomination is favorable, relevant members with permissions to update GitHub an Discord roles will add the nominee to the appropriate groups. The nominator should announce the new maintainership in the relevant Discord channel.
+6. After Core / Lead Maintainers discuss and/or vote, if the nomination is favorable, relevant members with permissions to update GitHub and Discord roles will add the nominee to the appropriate groups. The nominator should announce the new maintainership in the relevant Discord channel.
 7. The temporary Discord channel will be deleted a week later.
 
 Suggestions for the kind of information to share with core maintainers when nominating someone:
diff --git a/docs/community/sep-guidelines.mdx b/docs/community/sep-guidelines.mdx
@@ -23,16 +23,16 @@ Consider proposing a SEP if your change involves any of the following:
   - Introducing a new standard for interoperability between different MCP-compatible tools.
   - Significant changes to how the specification itself is defined, presented, or validated.
 - **A Breaking Change**: Any change that is not backwards-compatible.
-- **A Change to Governance or Process**: Any proposal that alters the project's decision-making, contribution guidelines (like this document itself).
+- **A Change to Governance or Process**: Any proposal that alters the project's decision-making or contribution guidelines (like this document itself).
 - **A Complex or Controversial Topic**: If a change is likely to have multiple valid solutions or generate significant debate, the SEP process provides the necessary framework to explore alternatives, document the rationale, and build community consensus before implementation begins.
 
 ## SEP Types
 
 There are three kinds of SEP:
 
-1. **Standards Track** SEP describes a new feature or implementation for the Model Context Protocol. It may also describe an interoperability standard that will be supported outside the core protocol specification.
-2. **Informational** SEP describes a Model Context Protocol design issue, or provides general guidelines or information to the MCP community, but does not propose a new feature. Informational SEPs do not necessarily represent an MCP community consensus or recommendation.
-3. **Process** SEP describes a process surrounding MCP, or proposes a change to (or an event in) a process. Process SEPs are like Standards Track SEPs but apply to areas other than the MCP protocol itself.
+1. A **Standards Track** SEP describes a new feature or implementation for the Model Context Protocol. It may also describe an interoperability standard that will be supported outside the core protocol specification.
+2. An **Informational** SEP describes a Model Context Protocol design issue, or provides general guidelines or information to the MCP community, but does not propose a new feature. Informational SEPs do not necessarily represent an MCP community consensus or recommendation.
+3. A **Process** SEP describes a process surrounding MCP, or proposes a change to (or an event in) a process. Process SEPs are like Standards Track SEPs but apply to areas other than the MCP protocol itself.
 
 ## Submitting a SEP
 
diff --git a/docs/docs/develop/build-client.mdx b/docs/docs/develop/build-client.mdx
@@ -1144,7 +1144,7 @@ export ANTHROPIC_API_KEY='your-anthropic-api-key-here'
 
 <Warning>
 
-Make sure your keep your `ANTHROPIC_API_KEY` secure!
+Make sure you keep your `ANTHROPIC_API_KEY` secure!
 
 </Warning>
 
@@ -1652,7 +1652,7 @@ The client will:
    - Get responses from Claude
 4. Exit the session when done
 
-Here's an example of what it should look like it connected to a weather server quickstart:
+Here's an example of what it should look like if connected to the weather server quickstart:
 
 <Frame>
   <img src="/images/quickstart-dotnet-client.png" />
diff --git a/docs/docs/develop/build-server.mdx b/docs/docs/develop/build-server.mdx
@@ -383,7 +383,7 @@ Writing to stdout will corrupt the JSON-RPC messages and break your server.
 ### Best Practices
 
 1. Use a logging library that writes to stderr or files, such as `logging` in Python.
-2. For JavaScript, be especially careful - `console.log()` writes to stdout by default
+2. For JavaScript, be especially careful - `console.log()` writes to stdout by default.
 
 ### Quick Examples
 
@@ -965,8 +965,8 @@ public class WeatherService {
 }
 ```
 
-The `@Service` annotation with auto-register the service in your application context.
-The Spring AI `@Tool` annotation, making it easy to create and maintain MCP tools.
+The `@Service` annotation will auto-register the service in your application context.
+The Spring AI `@Tool` annotation makes it easy to create and maintain MCP tools.
 
 The auto-configuration will automatically register these tools with the MCP server.
 
@@ -1129,7 +1129,7 @@ You can reuse the existing Anthropic Desktop configuration:
 spring.ai.mcp.client.stdio.servers-configuration=file:PATH/TO/claude_desktop_config.json
 ```
 
-When you start your client application, the auto-configuration will create, automatically MCP clients from the claude_desktop_config.json.
+When you start your client application, the auto-configuration will automatically create MCP clients from the claude_desktop_config.json.
 
 For more information, see the [MCP Client Boot Starters](https://docs.spring.io/spring-ai/reference/api/mcp/mcp-server-boot-client-docs.html) reference documentation.
 
@@ -2246,7 +2246,7 @@ Let's make sure Claude for Desktop is picking up the two tools we've exposed in
   <img src="/images/visual-indicator-mcp-tools.png" />
 </Frame>
 
-After clicking on the plus icon, hover over the "Connectors" menu, you should see the `weather`servers listed:
+After clicking on the plus icon, hover over the "Connectors" menu. You should see the `weather` servers listed:
 
 <Frame>
   <img src="/images/available-mcp-tools.png" />
diff --git a/docs/docs/develop/connect-remote-servers.mdx b/docs/docs/develop/connect-remote-servers.mdx
@@ -11,7 +11,7 @@ Many clients now support remote MCP servers, enabling a wide range of integratio
 
 Remote MCP servers function similarly to local MCP servers but are hosted on the internet rather than your local machine. They expose tools, prompts, and resources that Claude can use to perform tasks on your behalf. These servers can integrate with various services such as project management tools, documentation systems, code repositories, and any other API-enabled service.
 
-The key advantage of remote MCP servers is their accessibility. Unlike local servers that require installation and configuration on each device, remote servers are available from any MCP client with an internet connection. This makes them ideal for web-based AI applications, integrations that emphasize ease-of-use and services that require server-side processing or authentication.
+The key advantage of remote MCP servers is their accessibility. Unlike local servers that require installation and configuration on each device, remote servers are available from any MCP client with an internet connection. This makes them ideal for web-based AI applications, integrations that emphasize ease of use, and services that require server-side processing or authentication.
 
 ## What are Custom Connectors?
 
diff --git a/docs/docs/learn/architecture.mdx b/docs/docs/learn/architecture.mdx
@@ -129,8 +129,8 @@ For more details about server primitives see [server concepts](./server-concepts
 
 MCP also defines primitives that _clients_ can expose. These primitives allow MCP server authors to build richer interactions.
 
-- **Sampling**: Allows servers to request language model completions from the client's AI application. This is useful when servers' authors want access to a language model, but want to stay model independent and not include a language model SDK in their MCP server. They can use the `sampling/complete` method to request a language model completion from the client's AI application.
-- **Elicitation**: Allows servers to request additional information from users. This is useful when servers' authors want to get more information from the user, or ask for confirmation of an action. They can use the `elicitation/request` method to request additional information from the user.
+- **Sampling**: Allows servers to request language model completions from the client's AI application. This is useful when server authors want access to a language model, but want to stay model-independent and not include a language model SDK in their MCP server. They can use the `sampling/complete` method to request a language model completion from the client's AI application.
+- **Elicitation**: Allows servers to request additional information from users. This is useful when server authors want to get more information from the user, or ask for confirmation of an action. They can use the `elicitation/request` method to request additional information from the user.
 - **Logging**: Enables servers to send log messages to clients for debugging and monitoring purposes.
 
 For more details about client primitives see [client concepts](./client-concepts).
diff --git a/docs/docs/learn/server-concepts.mdx b/docs/docs/learn/server-concepts.mdx
@@ -277,4 +277,4 @@ Consider a personalized AI travel planner application, with three connected serv
    - `createCalendarEvent()` - Adds the trip to the user's calendar
    - `sendEmail()` - Sends confirmation with trip details
 
-**The result:** Through multiple MCP servers, the user researched and booked a Barcelona trip tailored to their schedule. The "Plan a Vacation" prompt guided the AI to combine Resources (calendar availability and travel history) with Tools (searching flights, booking hotels, updating calendars) across different servers—gathering context and executing the booking. A task that could've taken hours was completed in minutes using MCP.
+**The result:** Through multiple MCP servers, the user researched and booked a Barcelona trip tailored to their schedule. The "Plan a Vacation" prompt guided the AI to combine Resources (calendar availability and travel history) with Tools (searching flights, booking hotels, updating calendars) across different servers—gathering context and executing the booking. A task that could have taken hours was completed in minutes using MCP.
diff --git a/docs/docs/tutorials/security/authorization.mdx b/docs/docs/tutorials/security/authorization.mdx
@@ -618,7 +618,7 @@ For more details about implementing MCP servers in TypeScript, refer to the [Typ
 
 You can see the complete Python project in the [sample repository](https://github.com/localden/min-py-mcp-auth).
 
-To simplify our authorization interaction, in Python scenarios we rely on [FastMCP](https://gofastmcp.com/getting-started/welcome). A lot of the conventions around authorization, like the endpoints and token validation logic, are consistent across languages, but some offer simpler ways in integrating them in production scenarios.
+To simplify our authorization interaction, in Python scenarios we rely on [FastMCP](https://gofastmcp.com/getting-started/welcome). Many of the conventions around authorization, like the endpoints and token validation logic, are consistent across languages, but some offer simpler ways of integrating them in production scenarios.
 
 Prior to writing the actual server, we need to set up our configuration in `config.py` - the contents are entirely based on your local server setup:
 
diff --git a/docs/sdk/java/mcp-client.mdx b/docs/sdk/java/mcp-client.mdx
@@ -207,7 +207,7 @@ The transport layer handles the communication between MCP clients and servers, p
             .build();
         ```
 
-        To dynamically modify HTTP request before they are issued, implement either `McpSyncHttpClientRequestCustomizer` or `McpAsyncHttpClientRequestCustomizer`.
+        To dynamically modify HTTP requests before they are issued, implement either `McpSyncHttpClientRequestCustomizer` or `McpAsyncHttpClientRequestCustomizer`.
         Choose the request customizer matching the MCP Client type, sync or async.
         Note that thread-locals may not be available in the customizers, context-related information
         must be accessed through `McpTransportContext` (see [adding context information](#adding-context-information)).
@@ -296,7 +296,7 @@ The transport layer handles the communication between MCP clients and servers, p
                                     .build();
         ```
 
-        To dynamically modify HTTP request, the builder has a dedicated API, `ExchangeFilterFunction`.
+        To dynamically modify HTTP requests, the builder has a dedicated API, `ExchangeFilterFunction`.
         In that function, the new request can be computed at run time, and additional information can
         be obtained from the [Reactor context](https://projectreactor.io/docs/core/release/reference/advancedFeatures/context.html).
         It is common to store context information in an `McpTransportContext` within the Reactor context,
@@ -421,7 +421,7 @@ mcpClient.initialize();
 
 mcpClient.setLoggingLevel(McpSchema.LoggingLevel.INFO);
 
-// Call the tool that can sends logging notifications
+// Call the tool that can send logging notifications
 CallToolResult result = mcpClient.callTool(new McpSchema.CallToolRequest("logging-test", Map.of()));
 ```
 
@@ -441,7 +441,7 @@ var mcpClient = McpClient.sync(transport)
 
 mcpClient.initialize();
 
-// Call the tool that can sends progress notifications
+// Call the tool that can send progress notifications
 CallToolResult result = mcpClient.callTool(new McpSchema.CallToolRequest("progress-test", Map.of()));
 ```
 
diff --git a/docs/sdk/java/mcp-overview.mdx b/docs/sdk/java/mcp-overview.mdx
diff --git a/docs/sdk/java/mcp-server.mdx b/docs/sdk/java/mcp-server.mdx
