more grammar

docs/concepts/architecture.mdx

@@ -1,5 +1,5 @@
 ---
-title: "Core Architecture"
+title: "Core architecture"
 description: "Understand how MCP connects clients, servers, and LLMs"
 ---
 
@@ -27,7 +27,7 @@ flowchart LR
 
 ## Core components
 
-### Protocol Layer
+### Protocol layer
 
 The protocol layer handles message framing, request/response linking, and high-level communication patterns. Key classes include:
 
@@ -51,7 +51,7 @@ class Protocol<SendRequestT, SendNotificationT, SendResultT> {
 
 The transport layer handles the actual communication between clients and servers. MCP supports multiple transport mechanisms:
 
-1. **stdio Transport**
+1. **Stdio transport**
    - Uses standard input/output for communication
    - Ideal for local processes
    ```typescript
@@ -61,7 +61,7 @@ The transport layer handles the actual communication between clients and servers
    }
    ```
 
-2. **WebSocket Transport**
+2. **WebSocket transport**
    - Enables real-time bidirectional communication
    - Supports remote connections
    ```typescript
@@ -71,7 +71,7 @@ The transport layer handles the actual communication between clients and servers
    }
    ```
 
-3. **SSE Transport**
+3. **SSE transport**
    - Uses Server-Sent Events for server-to-client messages
    - HTTP POST for client-to-server messages
    ```typescript
@@ -136,7 +136,7 @@ sequenceDiagram
 3. Client sends `initialized` notification
 4. Normal message exchange begins
 
-### 2. Message Exchange
+### 2. Message exchange
 
 After initialization, the following patterns are supported:
 
@@ -206,54 +206,54 @@ await server.connect(transport);
 
 ### Transport selection
 
-1. **Local Communication**
+1. **Local communication**
    - Use stdio transport for local processes
    - Efficient for same-machine communication
    - Simple process management
 
-2. **Remote Communication**
+2. **Remote communication**
    - WebSocket for full-duplex communication
    - SSE for scenarios requiring HTTP compatibility
    - Consider security implications
 
-### Message Handling
+### Message handling
 
-1. **Request Processing**
+1. **Request processing**
    - Validate inputs thoroughly
    - Use type-safe schemas
    - Handle errors gracefully
    - Implement timeouts
 
-2. **Progress Reporting**
+2. **Progress reporting**
    - Use progress tokens for long operations
    - Report progress incrementally
    - Include total progress when known
 
-3. **Error Management**
+3. **Error management**
    - Use appropriate error codes
    - Include helpful error messages
    - Clean up resources on errors
 
 ## Security considerations
 
-1. **Transport Security**
+1. **Transport security**
    - Use TLS for remote connections
    - Validate connection origins
    - Implement authentication when needed
 
-2. **Message Validation**
+2. **Message validation**
    - Validate all incoming messages
    - Sanitize inputs
    - Check message size limits
    - Verify JSON-RPC format
 
-3. **Resource Protection**
+3. **Resource protection**
    - Implement access controls
    - Validate resource paths
    - Monitor resource usage
    - Rate limit requests
 
-4. **Error Handling**
+4. **Error handling**
    - Don't leak sensitive information
    - Log security-relevant errors
    - Implement proper cleanup
@@ -278,5 +278,3 @@ await server.connect(transport);
    - Verify error handling
    - Check edge cases
    - Load test servers
-
-This architecture provides a robust foundation for building MCP integrations while maintaining flexibility for different use cases and deployment scenarios.

docs/concepts/prompts.mdx

@@ -97,7 +97,7 @@ To use a prompt, clients make a `prompts/get` request:
 
 Prompts can be dynamic and include:
 
-### Context Integration
+### Context integration
 
 ```typescript
 const analyzeLogsPrompt = {

docs/concepts/resources.mdx

@@ -38,7 +38,7 @@ The protocol and path structure is defined by the MCP server implementation. Ser
 
 Resources can contain two types of content:
 
-### Text Resources
+### Text resources
 
 Text resources contain UTF-8 encoded text data. These are suitable for:
 - Source code

docs/concepts/sampling.mdx

@@ -141,7 +141,7 @@ When implementing sampling:
 9. Test with various model parameters
 10. Monitor sampling costs
 
-## Human-in-the-loop controls
+## Human in the loop controls
 
 Sampling is designed with human oversight in mind:
 

docs/concepts/tools.mdx

@@ -31,13 +31,6 @@ Each tool is defined with the following structure:
 }
 ```
 
-The `inputSchema` uses JSON Schema to define the expected parameters and their types. This enables:
-
-- Parameter validation
-- Type checking
-- Documentation of required vs optional parameters
-- Complex nested parameter structures
-
 ## Implementing tools
 
 Here's an example of implementing a basic tool in an MCP server:

docs/concepts/transport.mdx

@@ -73,7 +73,7 @@ const transport = new WebSocketClientTransport(
 await client.connect(transport);
 ```
 
-### Server-sent events (SSE)
+### Server-sent events
 
 SSE transport enables server-to-client streaming with HTTP POST requests for client-to-server communication. This is useful when WebSocket support isn't available.
 
@@ -256,21 +256,21 @@ Tips for debugging transport issues:
 
 Choose the appropriate transport based on your needs:
 
-### Use stdio when:
+### Use stdio when
 
 - Building command-line tools
 - Implementing local integrations
 - Needing simple process communication
 - Working with shell scripts
 
-### Use WebSocket when:
+### Use WebSocket when
 
 - Real-time updates are needed
 - Low latency is required
 - Bidirectional communication is necessary
 - Working with web applications
 
-### Use SSE when:
+### Use SSE when
 
 - Only server-to-client streaming is needed
 - WebSocket support is limited