Format with Prettier

Author: jonathanhefner

docs/clients.mdx

@@ -95,15 +95,16 @@ The protocol layer handles message framing, request/response linking, and high-l
 
 Key classes include:
 
-* `Protocol`
-* `Client`
-* `Server`
+- `Protocol`
+- `Client`
+- `Server`
 
 ### Transport layer
 
 The transport layer handles the actual communication between clients and servers. MCP supports multiple transport mechanisms:
 
 1. **Stdio transport**
+
    - Uses standard input/output for communication
    - Ideal for local processes
 
@@ -118,36 +119,39 @@ All transports use [JSON-RPC](https://www.jsonrpc.org/) 2.0 to exchange messages
 MCP has these main types of messages:
 
 1. **Requests** expect a response from the other side:
-    ```typescript
-    interface Request {
-      method: string;
-      params?: { ... };
-    }
-    ```
+
+   ```typescript
+   interface Request {
+     method: string;
+     params?: { ... };
+   }
+   ```
 
 2. **Results** are successful responses to requests:
-    ```typescript
-    interface Result {
-      [key: string]: unknown;
-    }
-    ```
+
+   ```typescript
+   interface Result {
+     [key: string]: unknown;
+   }
+   ```
 
 3. **Errors** indicate that a request failed:
-    ```typescript
-    interface Error {
-      code: number;
-      message: string;
-      data?: unknown;
-    }
-    ```
+
+   ```typescript
+   interface Error {
+     code: number;
+     message: string;
+     data?: unknown;
+   }
+   ```
 
 4. **Notifications** are one-way messages that don't expect a response:
-    ```typescript
-    interface Notification {
-      method: string;
-      params?: { ... };
-    }
-    ```
+   ```typescript
+   interface Notification {
+     method: string;
+     params?: { ... };
+   }
+   ```
 
 ## Connection lifecycle
 
@@ -180,6 +184,7 @@ After initialization, the following patterns are supported:
 ### 3. Termination
 
 Either party can terminate the connection:
+
 - Clean shutdown via `close()`
 - Transport disconnection
 - Error conditions
@@ -195,13 +200,14 @@ enum ErrorCode {
   InvalidRequest = -32600,
   MethodNotFound = -32601,
   InvalidParams = -32602,
-  InternalError = -32603
+  InternalError = -32603,
 }
 ```
 
 SDKs and applications can define their own error codes above -32000.
 
 Errors are propagated through:
+
 - Error responses to requests
 - Error events on transports
 - Protocol-level error handlers
@@ -283,6 +289,7 @@ Here's a basic example of implementing an MCP server:
 ### Transport selection
 
 1. **Local communication**
+
    - Use stdio transport for local processes
    - Efficient for same-machine communication
    - Simple process management
@@ -294,12 +301,14 @@ Here's a basic example of implementing an MCP server:
 ### Message handling
 
 1. **Request processing**
+
    - Validate inputs thoroughly
    - Use type-safe schemas
    - Handle errors gracefully
    - Implement timeouts
 
 2. **Progress reporting**
+
    - Use progress tokens for long operations
    - Report progress incrementally
    - Include total progress when known
@@ -312,17 +321,20 @@ Here's a basic example of implementing an MCP server:
 ## Security considerations
 
 1. **Transport security**
+
    - Use TLS for remote connections
    - Validate connection origins
    - Implement authentication when needed
 
 2. **Message validation**
+
    - Validate all incoming messages
    - Sanitize inputs
    - Check message size limits
    - Verify JSON-RPC format
 
 3. **Resource protection**
+
    - Implement access controls
    - Validate resource paths
    - Monitor resource usage
@@ -337,12 +349,14 @@ Here's a basic example of implementing an MCP server:
 ## Debugging and monitoring
 
 1. **Logging**
+
    - Log protocol events
    - Track message flow
    - Monitor performance
    - Record errors
 
 2. **Diagnostics**
+
    - Implement health checks
    - Monitor connection state
    - Track resource usage

docs/docs/concepts/architecture.mdx

@@ -7,13 +7,14 @@ Prompts enable servers to define reusable prompt templates and workflows that cl
 
 <Note>
 
-  Prompts are designed to be **user-controlled**, meaning they are exposed from servers to clients with the intention of the user being able to explicitly select them for use.
+Prompts are designed to be **user-controlled**, meaning they are exposed from servers to clients with the intention of the user being able to explicitly select them for use.
 
 </Note>
 
 ## Overview
 
 Prompts in MCP are predefined templates that can:
+
 - Accept dynamic arguments
 - Include context from resources
 - Chain multiple interactions
@@ -45,7 +46,7 @@ Clients can discover available prompts through the `prompts/list` endpoint:
 ```typescript
 // Request
 {
-  method: "prompts/list"
+  method: "prompts/list";
 }
 
 // Response
@@ -58,19 +59,19 @@ Clients can discover available prompts through the `prompts/list` endpoint:
         {
           name: "language",
           description: "Programming language",
-          required: true
-        }
-      ]
-    }
-  ]
+          required: true,
+        },
+      ],
+    },
+  ];
 }
 ```
 
 ## Using prompts
 
 To use a prompt, clients make a `prompts/get` request:
 
-```typescript
+````typescript
 // Request
 {
   method: "prompts/get",
@@ -95,7 +96,7 @@ To use a prompt, clients make a `prompts/get` request:
     }
   ]
 }
-```
+````
 
 ## Dynamic prompts
 
@@ -171,25 +172,25 @@ const debugWorkflow = {
         role: "user",
         content: {
           type: "text",
-          text: `Here's an error I'm seeing: ${error}`
-        }
+          text: `Here's an error I'm seeing: ${error}`,
+        },
       },
       {
         role: "assistant",
         content: {
           type: "text",
-          text: "I'll help analyze this error. What have you tried so far?"
-        }
+          text: "I'll help analyze this error. What have you tried so far?",
+        },
       },
       {
         role: "user",
         content: {
           type: "text",
-          text: "I've tried restarting the service, but the error persists."
-        }
-      }
+          text: "I've tried restarting the service, but the error persists.",
+        },
+      },
     ];
-  }
+  },
 };
 ```
 

docs/docs/concepts/prompts.mdx

@@ -7,13 +7,14 @@ Resources are a core primitive in the Model Context Protocol (MCP) that allow se
 
 <Note>
 
-  Resources are designed to be **application-controlled**, meaning that the client application can decide how and when they should be used.
-  Different MCP clients may handle resources differently. For example:
-  - Claude Desktop currently requires users to explicitly select resources before they can be used
-  - Other clients might automatically select resources based on heuristics
-  - Some implementations may even allow the AI model itself to determine which resources to use
+Resources are designed to be **application-controlled**, meaning that the client application can decide how and when they should be used.
+Different MCP clients may handle resources differently. For example:
 
-  Server authors should be prepared to handle any of these interaction patterns when implementing resource support. In order to expose data to models automatically, server authors should use a **model-controlled** primitive such as [Tools](./tools).
+- Claude Desktop currently requires users to explicitly select resources before they can be used
+- Other clients might automatically select resources based on heuristics
+- Some implementations may even allow the AI model itself to determine which resources to use
+
+Server authors should be prepared to handle any of these interaction patterns when implementing resource support. In order to expose data to models automatically, server authors should use a **model-controlled** primitive such as [Tools](./tools).
 
 </Note>
 
@@ -40,6 +41,7 @@ Resources are identified using URIs that follow this format:
 ```
 
 For example:
+
 - `file:///home/user/documents/report.pdf`
 - `postgres://database/customers/schema`
 - `screen://localhost/display1`
@@ -53,6 +55,7 @@ Resources can contain two types of content:
 ### Text resources
 
 Text resources contain UTF-8 encoded text data. These are suitable for:
+
 - Source code
 - Configuration files
 - Log files
@@ -62,6 +65,7 @@ Text resources contain UTF-8 encoded text data. These are suitable for:
 ### Binary resources
 
 Binary resources contain raw binary data encoded in base64. These are suitable for:
+
 - Images
 - PDFs
 - Audio files
@@ -122,7 +126,7 @@ The server responds with a list of resource contents:
 
 <Tip>
 
-  Servers may return multiple resources in response to one `resources/read` request. This could be used, for example, to return a list of files inside a directory when the directory is read.
+Servers may return multiple resources in response to one `resources/read` request. This could be used, for example, to return a list of files inside a directory when the directory is read.
 
 </Tip>
 

docs/docs/concepts/resources.mdx

@@ -76,4 +76,4 @@ Here's how a typical MCP client might expose roots:
 }
 ```
 
-This configuration suggests the server focus on both a local repository and an API endpoint while keeping them logically separated.
+This configuration suggests the server focus on both a local repository and an API endpoint while keeping them logically separated.

docs/docs/concepts/roots.mdx

@@ -7,7 +7,7 @@ Sampling is a powerful MCP feature that allows servers to request LLM completion
 
 <Info>
 
-  This feature of MCP is not yet supported in the Claude Desktop client.
+This feature of MCP is not yet supported in the Claude Desktop client.
 
 </Info>
 
@@ -77,6 +77,7 @@ The `messages` array contains the conversation history to send to the LLM. Each
 The `modelPreferences` object allows servers to specify their model selection preferences:
 
 - `hints`: Array of model name suggestions that clients can use to select an appropriate model:
+
   - `name`: String that can match full or partial model names (e.g. "claude-3", "sonnet")
   - Clients may map hints to equivalent models from different providers
   - Multiple hints are evaluated in preference order
@@ -132,6 +133,7 @@ The client returns a completion result:
 ## Example request
 
 Here's an example of requesting sampling from a client:
+
 ```json
 {
   "method": "sampling/createMessage",

docs/docs/concepts/sampling.mdx

@@ -7,7 +7,7 @@ Tools are a powerful primitive in the Model Context Protocol (MCP) that enable s
 
 <Note>
 
-  Tools are designed to be **model-controlled**, meaning that tools are exposed from servers to clients with the intention of the AI model being able to automatically invoke them (with a human in the loop to grant approval).
+Tools are designed to be **model-controlled**, meaning that tools are exposed from servers to clients with the intention of the AI model being able to automatically invoke them (with a human in the loop to grant approval).
 
 </Note>
 
@@ -336,13 +336,13 @@ Tool annotations serve several key purposes:
 
 The MCP specification defines the following annotations for tools:
 
-| Annotation | Type | Default | Description |
-|------------|------|---------|-------------|
-| `title` | string | - | A human-readable title for the tool, useful for UI display |
-| `readOnlyHint` | boolean | false | If true, indicates the tool does not modify its environment |
-| `destructiveHint` | boolean | true | If true, the tool may perform destructive updates (only meaningful when `readOnlyHint` is false) |
-| `idempotentHint` | boolean | false | If true, calling the tool repeatedly with the same arguments has no additional effect (only meaningful when `readOnlyHint` is false) |
-| `openWorldHint` | boolean | true | If true, the tool may interact with an "open world" of external entities |
+| Annotation        | Type    | Default | Description                                                                                                                          |
+| ----------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `title`           | string  | -       | A human-readable title for the tool, useful for UI display                                                                           |
+| `readOnlyHint`    | boolean | false   | If true, indicates the tool does not modify its environment                                                                          |
+| `destructiveHint` | boolean | true    | If true, the tool may perform destructive updates (only meaningful when `readOnlyHint` is false)                                     |
+| `idempotentHint`  | boolean | false   | If true, calling the tool repeatedly with the same arguments has no additional effect (only meaningful when `readOnlyHint` is false) |
+| `openWorldHint`   | boolean | true    | If true, the tool may interact with an "open world" of external entities                                                             |
 
 ### Example usage