The current setup uses the Model Context Protocol (MCP) which is:
- Request-Response based: Each tool call is a single request that returns a complete response
- JSON-based messaging: Structured but not optimized for streaming
- Stdio transport: Communication over stdin/stdout pipes
- Synchronous by nature: Even with async Python, the protocol itself expects complete responses
Worth noting the system prompt is where lot of editing/polishing is needed:
- parse user intent system prompt is key
- {tools_context}
- decision logic
- tools selection rules
- parameter validation and confirmation
- file input handling
- portfolio file handling pa tools
- spar parameter handling
- univese parameter handling
- realtioship parameter handling
- save/export handling
- response behavior response format
- EXAMPLES
If the user asks a GENERAL KNOWLEDGE question (about companies, facts, definitions, etc.), respond with: {{"type": "general_answer", "answer": "your answer here"}}
remember previous conversations and use context
Let’s take a deeper look at the fundamental infrastructure, if we need to apply better communication experience for users.
First, I have intelligent_client.py and intelligent_client_tcp.py, let’s compare
| spect | intelligent_client.py | intelligent_client_tcp.py |
|---|---|---|
| MCP Transport | STDIO pipes (subprocess) | Raw TCP sockets |
| Connection | Local process spawning | Network connection |
| Protocol | MCP over STDIO | JSON-RPC over TCP |
| Deployment | Single machine | Distributed (over VPN) |
The key is uses STDIO pipes is for local MCP communication and HTTPS for Azure OpenAI, while the TCP version uses raw TCP sockets for remote MCP communication. At present, for a small team, STDIO is sufficient.
Further, I’d like to explore gRPC over JSON-RPC,
| Aspect | JSON-RPC (Current) | gRPC |
|---|---|---|
| Message Format | Text-based JSON | Binary Protocol Buffers |
| Schema Definition | Loose/Dynamic | Strict .proto files |
| Type Safety | Runtime validation | Compile-time validation |
| Performance | Slower (JSON parsing) | Faster (binary serialization) |
| Human Readability | Easy to debug/inspect | Requires tools to inspect |
| Streaming | Request/Response only | 4 streaming patterns |
| Code Generation | Manual implementation | Auto-generated clients |
gRPC is more for performance optimization, hence in my case, json-RPC is a good solution.