prettier fix

Author: KKonstantinov

README.md

@@ -1,7 +1,6 @@
 ## Client overview
 
-The SDK provides a high-level `Client` class that connects to MCP servers over
-different transports:
+The SDK provides a high-level `Client` class that connects to MCP servers over different transports:
 
 - `StdioClientTransport` – for local processes you spawn.
 - `StreamableHTTPClientTransport` – for remote HTTP servers.
@@ -22,18 +21,15 @@ A typical flow:
 1. Construct a `Client` with name, version and capabilities.
 2. Create a transport and call `client.connect(transport)`.
 3. Use high-level helpers:
-   - `listTools`, `callTool`
-   - `listPrompts`, `getPrompt`
-   - `listResources`, `readResource`
+    - `listTools`, `callTool`
+    - `listPrompts`, `getPrompt`
+    - `listResources`, `readResource`
 
-See `src/examples/client/simpleStreamableHttp.ts` for an interactive CLI client
-that exercises these methods and shows how to handle notifications, elicitation
-and tasks.
+See `src/examples/client/simpleStreamableHttp.ts` for an interactive CLI client that exercises these methods and shows how to handle notifications, elicitation and tasks.
 
 ## Transports and backwards compatibility
 
-To support both modern Streamable HTTP and legacy SSE servers, use a client
-that:
+To support both modern Streamable HTTP and legacy SSE servers, use a client that:
 
 1. Tries `StreamableHTTPClientTransport`.
 2. Falls back to `SSEClientTransport` on a 4xx response.
@@ -62,6 +58,3 @@ These examples show how to:
 - Perform dynamic client registration if needed.
 - Acquire access tokens.
 - Attach OAuth credentials to Streamable HTTP requests.
-
-
-

docs/client.md

@@ -15,25 +15,27 @@
 
 This TypeScript error can appear when upgrading to newer SDK versions that support Zod v4 (for example, from `@modelcontextprotocol/sdk` `1.22.0` to `1.23.0`) **and** your project ends up with multiple `zod` versions in the dependency tree.
 
-When there are multiple copies or versions of `zod`, TypeScript may try to instantiate very complex, cross-version types and hit its recursion limits, resulting in `TS2589`. This scenario is discussed in GitHub issue [#1180](https://github.com/modelcontextprotocol/typescript-sdk/issues/1180#event-21236550401).
+When there are multiple copies or versions of `zod`, TypeScript may try to instantiate very complex, cross-version types and hit its recursion limits, resulting in `TS2589`. This scenario is discussed in GitHub issue
+[#1180](https://github.com/modelcontextprotocol/typescript-sdk/issues/1180#event-21236550401).
 
 To diagnose and fix this:
 
 - **Inspect your installed `zod` versions**:
-  - Run `npm ls zod` or `npm explain zod`, `pnpm list zod` or `pnpm why zod`, or `yarn why zod` and check whether more than one version is installed.
+    - Run `npm ls zod` or `npm explain zod`, `pnpm list zod` or `pnpm why zod`, or `yarn why zod` and check whether more than one version is installed.
 - **Align on a single `zod` version**:
-  - Make sure all packages that depend on `zod` use a compatible version range so that your package manager can hoist a single copy.
-  - In monorepos, consider declaring `zod` at the workspace root and using compatible ranges in individual packages.
+    - Make sure all packages that depend on `zod` use a compatible version range so that your package manager can hoist a single copy.
+    - In monorepos, consider declaring `zod` at the workspace root and using compatible ranges in individual packages.
 - **Use overrides/resolutions if necessary**:
-  - With npm, Yarn, or pnpm, you can use `overrides` / `resolutions` to force a single `zod` version if some transitive dependencies pull in a different one.
+    - With npm, Yarn, or pnpm, you can use `overrides` / `resolutions` to force a single `zod` version if some transitive dependencies pull in a different one.
 
 Once your project is using a single, compatible `zod` version, the `TS2589` error should no longer occur.
 
 ## Clients
 
 ### How do I enable Web Crypto (`globalThis.crypto`) for client authentication in older Node.js versions?
 
-The SDK’s OAuth client authentication helpers (for example, those in `src/client/auth-extensions.ts` that use `jose`) rely on the Web Crypto API exposed as `globalThis.crypto`. This is especially important for **client credentials** and **JWT-based** authentication flows used by MCP clients.
+The SDK’s OAuth client authentication helpers (for example, those in `src/client/auth-extensions.ts` that use `jose`) rely on the Web Crypto API exposed as `globalThis.crypto`. This is especially important for **client credentials** and **JWT-based** authentication flows used by
+MCP clients.
 
 - **Node.js v19.0.0 and later**: `globalThis.crypto` is available by default.
 - **Node.js v18.x**: `globalThis.crypto` may not be defined by default. In this repository we polyfill it for tests (see `vitest.setup.ts`), and you should do the same in your app if it is missing – or alternatively, run Node with `--experimental-global-webcrypto` as per your
@@ -59,6 +61,5 @@ For production use, you can either:
 
 ### Where can I find runnable server examples?
 
-The SDK ships several runnable server examples under `src/examples/server`. The root `README.md` contains a curated **Server examples** table that links to each scenario (stateful/stateless Streamable HTTP, JSON-only mode, SSE/backwards compatibility, elicitation, sampling, tasks, and OAuth demos), and `src/examples/README.md` includes commands and deployment diagrams for running them.
-
-
+The SDK ships several runnable server examples under `src/examples/server`. The root `README.md` contains a curated **Server examples** table that links to each scenario (stateful/stateless Streamable HTTP, JSON-only mode, SSE/backwards compatibility, elicitation, sampling,
+tasks, and OAuth demos), and `src/examples/README.md` includes commands and deployment diagrams for running them.

docs/faq.md

@@ -1,8 +1,6 @@
 ## Sampling
 
-MCP servers can request LLM completions from connected clients that support the
-sampling capability. This lets your tools offload summarisation or generation
-to the client’s model.
+MCP servers can request LLM completions from connected clients that support the sampling capability. This lets your tools offload summarisation or generation to the client’s model.
 
 For a runnable server that combines tools, logging and tasks, see:
 
@@ -18,24 +16,18 @@ Refer to the MCP spec’s sampling section for full request/response details.
 
 ## Form elicitation
 
-Form elicitation lets a tool ask the user for additional, **non‑sensitive**
-information via a schema‑driven form. The server sends a schema and message,
-and the client is responsible for collecting and returning the data.
+Form elicitation lets a tool ask the user for additional, **non‑sensitive** information via a schema‑driven form. The server sends a schema and message, and the client is responsible for collecting and returning the data.
 
 Runnable example:
 
 - Server: `src/examples/server/elicitationFormExample.ts`
 - Client‑side handling: `src/examples/client/simpleStreamableHttp.ts`
 
-The `simpleStreamableHttp` server also includes a `collect-user-info` tool that
-demonstrates how to drive elicitation from a tool and handle the response.
+The `simpleStreamableHttp` server also includes a `collect-user-info` tool that demonstrates how to drive elicitation from a tool and handle the response.
 
 ## URL elicitation
 
-URL elicitation is designed for sensitive data and secure web‑based flows
-(e.g., collecting an API key, confirming a payment, or doing third‑party OAuth).
-Instead of returning form data, the server asks the client to open a URL and
-the rest of the flow happens in the browser.
+URL elicitation is designed for sensitive data and secure web‑based flows (e.g., collecting an API key, confirming a payment, or doing third‑party OAuth). Instead of returning form data, the server asks the client to open a URL and the rest of the flow happens in the browser.
 
 Runnable example:
 
@@ -46,12 +38,8 @@ Key points:
 
 - Use `mode: 'url'` when calling `server.server.elicitInput(...)`.
 - Implement a client‑side handler for `ElicitRequestSchema` that:
-  - Shows the full URL and reason to the user.
-  - Asks for explicit consent.
-  - Opens the URL in the system browser.
-
-Sensitive information **must not** be collected via form elicitation; always
-use URL elicitation or out‑of‑band flows for secrets.
-
-
+    - Shows the full URL and reason to the user.
+    - Asks for explicit consent.
+    - Opens the URL in the system browser.
 
+Sensitive information **must not** be collected via form elicitation; always use URL elicitation or out‑of‑band flows for secrets.

docs/sampling-and-elicitation.md

@@ -1,8 +1,6 @@
 ## Server overview
 
-This SDK lets you build MCP servers in TypeScript and connect them to different transports.
-For most use cases you will use `McpServer` from `@modelcontextprotocol/sdk/server/mcp.js`
-and choose one of:
+This SDK lets you build MCP servers in TypeScript and connect them to different transports. For most use cases you will use `McpServer` from `@modelcontextprotocol/sdk/server/mcp.js` and choose one of:
 
 - **Streamable HTTP** (recommended for remote servers)
 - **HTTP + SSE** (deprecated, for backwards compatibility only)
@@ -50,8 +48,7 @@ Examples:
 
 ### Deprecated HTTP + SSE
 
-The older HTTP+SSE transport (protocol version 2024‑11‑05) is supported only for
-backwards compatibility. New implementations should prefer Streamable HTTP.
+The older HTTP+SSE transport (protocol version 2024‑11‑05) is supported only for backwards compatibility. New implementations should prefer Streamable HTTP.
 
 Examples:
 
@@ -67,31 +64,25 @@ For a minimal “getting started” experience:
 2. Remove features you do not need (tasks, advanced logging, OAuth, etc.).
 3. Register your own tools, resources and prompts.
 
-For more detailed patterns (stateless vs stateful, JSON response mode, CORS, DNS
-rebind protection), see the examples above and the MCP spec sections on transports.
+For more detailed patterns (stateless vs stateful, JSON response mode, CORS, DNS rebind protection), see the examples above and the MCP spec sections on transports.
 
 ## Multi‑node deployment patterns
 
-The SDK supports multi‑node deployments using Streamable HTTP. The high‑level
-patterns are documented in `src/examples/README.md`:
+The SDK supports multi‑node deployments using Streamable HTTP. The high‑level patterns are documented in `src/examples/README.md`:
 
 - Stateless mode (any node can handle any request)
 - Persistent storage mode (shared database for session state)
 - Local state with message routing (message queue + pub/sub)
 
-Those deployment diagrams are kept in `src/examples/README.md` so the examples
-and documentation stay aligned.
+Those deployment diagrams are kept in `src/examples/README.md` so the examples and documentation stay aligned.
 
 ## Backwards compatibility
 
 To handle both modern and legacy clients:
 
 - Run a backwards‑compatible server:
-  - `src/examples/server/sseAndStreamableHttpCompatibleServer.ts`
+    - `src/examples/server/sseAndStreamableHttpCompatibleServer.ts`
 - Use a client that falls back from Streamable HTTP to SSE:
-  - `src/examples/client/streamableHttpWithSseFallbackClient.ts`
+    - `src/examples/client/streamableHttpWithSseFallbackClient.ts`
 
 For the detailed protocol rules, see the “Backwards compatibility” section of the MCP spec.
-
-
-

docs/server.md

@@ -1,11 +1,8 @@
 ## Task-based execution (experimental)
 
-Task-based execution enables “call-now, fetch-later” patterns for long-running
-operations. Instead of returning a result immediately, a tool creates a task
-that can be polled or resumed later.
+Task-based execution enables “call-now, fetch-later” patterns for long-running operations. Instead of returning a result immediately, a tool creates a task that can be polled or resumed later.
 
-The APIs live under the experimental `.experimental.tasks` namespace and may
-change without notice.
+The APIs live under the experimental `.experimental.tasks` namespace and may change without notice.
 
 ### Server-side concepts
 
@@ -24,20 +21,13 @@ For a runnable example that uses the in-memory store shipped with the SDK, see:
 
 On the client, you use:
 
-- `client.experimental.tasks.callToolStream(...)` to start a tool call that may
-  create a task and emit status updates over time.
-- `client.getTask(...)` and `client.getTaskResult(...)` to check status and
-  fetch results after reconnecting.
+- `client.experimental.tasks.callToolStream(...)` to start a tool call that may create a task and emit status updates over time.
+- `client.getTask(...)` and `client.getTaskResult(...)` to check status and fetch results after reconnecting.
 
 The interactive client in:
 
 - `src/examples/client/simpleStreamableHttp.ts`
 
-includes commands to demonstrate calling tools that support tasks and handling
-their lifecycle.
-
-See the MCP spec’s tasks section and the example server/client above for a full
-walkthrough of the task status lifecycle and TTL handling.
-
-
+includes commands to demonstrate calling tools that support tasks and handling their lifecycle.
 
+See the MCP spec’s tasks section and the example server/client above for a full walkthrough of the task status lifecycle and TTL handling.

docs/tasks-and-long-running.md

@@ -1,7 +1,6 @@
 ## Tools
 
-Tools let MCP clients ask your server to take actions. They are usually the
-main way that LLMs call into your application.
+Tools let MCP clients ask your server to take actions. They are usually the main way that LLMs call into your application.
 
 A typical registration with `registerTool` looks like this:
 
@@ -34,17 +33,13 @@ This snippet is illustrative only; for runnable servers that expose tools, see:
 
 ### ResourceLink outputs
 
-Tools can return `resource_link` content items to reference large resources
-without embedding them directly, allowing clients to fetch only what they need.
+Tools can return `resource_link` content items to reference large resources without embedding them directly, allowing clients to fetch only what they need.
 
-The README’s `list-files` example shows the pattern conceptually; for concrete
-usage, see the Streamable HTTP examples in `src/examples/server`.
+The README’s `list-files` example shows the pattern conceptually; for concrete usage, see the Streamable HTTP examples in `src/examples/server`.
 
 ## Resources
 
-Resources expose data to clients, but should not perform heavy computation or
-side‑effects. They are ideal for configuration, documents, or other reference
-data.
+Resources expose data to clients, but should not perform heavy computation or side‑effects. They are ideal for configuration, documents, or other reference data.
 
 Conceptually, you might register resources like:
 
@@ -63,15 +58,13 @@ server.registerResource(
 );
 ```
 
-Dynamic resources use `ResourceTemplate` and can support completions on path
-parameters. For full runnable examples of resources:
+Dynamic resources use `ResourceTemplate` and can support completions on path parameters. For full runnable examples of resources:
 
 - `src/examples/server/simpleStreamableHttp.ts`
 
 ## Prompts
 
-Prompts are reusable templates that help humans (or client UIs) talk to models
-in a consistent way. They are declared on the server and listed through MCP.
+Prompts are reusable templates that help humans (or client UIs) talk to models in a consistent way. They are declared on the server and listed through MCP.
 
 A minimal prompt:
 
@@ -103,20 +96,12 @@ For prompts integrated into a full server, see:
 
 ## Completions
 
-Both prompts and resources can support argument completions. On the client
-side, you use `client.complete()` with a reference to the prompt or resource
-and the partially‑typed argument.
+Both prompts and resources can support argument completions. On the client side, you use `client.complete()` with a reference to the prompt or resource and the partially‑typed argument.
 
-See the MCP spec sections on prompts and resources for complete details, and
-`src/examples/client/simpleStreamableHttp.ts` for client‑side usage patterns.
+See the MCP spec sections on prompts and resources for complete details, and `src/examples/client/simpleStreamableHttp.ts` for client‑side usage patterns.
 
 ## Display names and metadata
 
-Tools, resources and prompts support a `title` field for human‑readable names.
-Older APIs can also attach `annotations.title`. To compute the correct display
-name on the client, use:
+Tools, resources and prompts support a `title` field for human‑readable names. Older APIs can also attach `annotations.title`. To compute the correct display name on the client, use:
 
 - `getDisplayName` from `@modelcontextprotocol/sdk/shared/metadataUtils.js`
-
-
-

docs/tools-resources-prompts.md

@@ -1,7 +1,6 @@
 # MCP TypeScript SDK Examples
 
-This directory contains example implementations of MCP clients and servers using the TypeScript SDK.
-For a high-level index of scenarios and where they live, see the **Examples** table in the root `README.md`.
+This directory contains example implementations of MCP clients and servers using the TypeScript SDK. For a high-level index of scenarios and where they live, see the **Examples** table in the root `README.md`.
 
 ## Table of Contents