Merge branch 'main' into patch-1

Author: xyc

.github/workflows/main.yml

@@ -18,8 +18,8 @@ jobs:
 
       - run: npm ci
 
-      - run: npm run validate:schema
+      - name: Check TypeScript definitions
+        run: npm run check:schema:ts
 
-      - run: npm run generate:json
       - name: Verify that `npm run generate:json` did not change outputs (if it did, please re-run it and re-commit!)
-        run: git diff --exit-code
+        run: npm run check:schema:json

.github/workflows/markdown-format.yml

@@ -25,4 +25,7 @@ jobs:
         run: npm ci
 
       - name: Check markdown formatting
-        run: npm run format:check
+        run: npm run check:docs:format
+
+      - name: Check markdown links
+        run: npm run check:docs:links

CONTRIBUTING.md

@@ -33,39 +33,34 @@ npm install  # install dependencies
 ## Making Changes
 
 Note that schema changes are made to `schema.ts`, and `schema.json` is generated from
-`schema.ts`. You should validate your `schema.ts` changes first and then generate the
-`schema.json`.
+`schema.ts`.
 
 1. Create a new branch:
 
 ```bash
 git checkout -b feature/your-feature-name
 ```
 
-2. Make your changes
-3. Validate your changes:
+2. Make your changes.
 
-```bash
-npm run validate:schema    # validate schema
-```
-
-4. Generate the `schema.json`:
+3. Validate schema changes and generate `schema.json`:
 
 ```bash
-npm run generate:json      # generate JSON schema
+npm run check:schema:ts
+npm run generate:json
 ```
 
-5. Run docs locally (optional):
+4. Validate documentation changes and apply formatting:
 
 ```bash
-npm run serve:docs
+npm run check:docs
+npm run format
 ```
 
-6. Format/lint your changes:
+5. Preview documentation locally (optional):
 
 ```bash
-npm run format:check   # check formatting
-npm run format         # apply formatting
+npm run serve:docs
 ```
 
 ### Documentation Guidelines
@@ -77,7 +72,7 @@ When contributing to the documentation:
 - Include code examples where appropriate
 - Use proper MDX formatting and components
 - Test all links and code samples
-  - You may run `npm run check-links` to look for broken internal links.
+  - You may run `npm run check:docs:links` to look for broken internal links.
 - Use appropriate headings: "When to use", "Steps", and "Tips" for tutorials
 - Place new pages in appropriate sections (concepts, tutorials, etc.)
 - Update `docs.json` when adding new pages

docs/clients.mdx

@@ -120,7 +120,7 @@ This page provides an overview of applications that support the Model Context Pr
 [WhatsMPC]: https://wassist.app/mcp/
 [Witsy]: https://github.com/nbonamy/witsy
 [Zed]: https://zed.dev
-[Zencoder]: https://zecoder.ai
+[Zencoder]: https://zencoder.ai
 [Resources]: https://modelcontextprotocol.io/docs/concepts/resources
 [Prompts]: https://modelcontextprotocol.io/docs/concepts/prompts
 [Tools]: https://modelcontextprotocol.io/docs/concepts/tools

docs/docs/concepts/architecture.mdx

@@ -108,8 +108,8 @@ The transport layer handles the actual communication between clients and servers
    - Uses standard input/output for communication
    - Ideal for local processes
 
-2. **HTTP with SSE transport**
-   - Uses Server-Sent Events for server-to-client messages
+2. **Streamable HTTP transport**
+   - Uses HTTP with optional Server-Sent Events for streaming
    - HTTP POST for client-to-server messages
 
 All transports use [JSON-RPC](https://www.jsonrpc.org/) 2.0 to exchange messages. See the [specification](/specification/) for detailed information about the Model Context Protocol message format.
@@ -295,7 +295,7 @@ Here's a basic example of implementing an MCP server:
    - Simple process management
 
 2. **Remote communication**
-   - Use SSE for scenarios requiring HTTP compatibility
+   - Use Streamable HTTP for scenarios requiring HTTP compatibility
    - Consider security implications including authentication and authorization
 
 ### Message handling