From 6cac5a1cde2224da0664b4cb0186ed49b65f7817 Mon Sep 17 00:00:00 2001 From: Zack Lee Date: Wed, 20 Nov 2024 12:01:44 -0500 Subject: [PATCH] more grammar --- docs/concepts/architecture.mdx | 36 ++++++++++++++++------------------ docs/concepts/prompts.mdx | 2 +- docs/concepts/resources.mdx | 2 +- docs/concepts/sampling.mdx | 2 +- docs/concepts/tools.mdx | 7 ------- docs/concepts/transport.mdx | 8 ++++---- 6 files changed, 24 insertions(+), 33 deletions(-) diff --git a/docs/concepts/architecture.mdx b/docs/concepts/architecture.mdx index c987d90..63a15ac 100644 --- a/docs/concepts/architecture.mdx +++ b/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 { 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 @@ -277,6 +277,4 @@ await server.connect(transport); - Test different transports - 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. \ No newline at end of file + - Load test servers \ No newline at end of file diff --git a/docs/concepts/prompts.mdx b/docs/concepts/prompts.mdx index d553287..d80407a 100644 --- a/docs/concepts/prompts.mdx +++ b/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 = { diff --git a/docs/concepts/resources.mdx b/docs/concepts/resources.mdx index 517d629..f48f14f 100644 --- a/docs/concepts/resources.mdx +++ b/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 diff --git a/docs/concepts/sampling.mdx b/docs/concepts/sampling.mdx index 21f9dbd..d5aeb78 100644 --- a/docs/concepts/sampling.mdx +++ b/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: diff --git a/docs/concepts/tools.mdx b/docs/concepts/tools.mdx index 2697e84..557186f 100644 --- a/docs/concepts/tools.mdx +++ b/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: diff --git a/docs/concepts/transport.mdx b/docs/concepts/transport.mdx index e9e117c..bc50202 100644 --- a/docs/concepts/transport.mdx +++ b/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