more grammar
This commit is contained in:
parent
b8d437542d
commit
6cac5a1cde
6 changed files with 24 additions and 33 deletions
|
|
@ -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
|
||||
|
|
@ -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.
|
||||
- Load test servers
|
||||
|
|
@ -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 = {
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in a new issue