Skip to content

Latest commit

 

History

History
29 lines (27 loc) · 1.41 KB

File metadata and controls

29 lines (27 loc) · 1.41 KB

Here's a suggested structure for breaking it up:

server.py - Main server setup and initialization FastMCP server configuration Lifespan context management Main entry point tools/claim_analyzer.py - The analyze_claim tool implementation Main analyze_claim function Result formatting tools/perspective_history.py - The get_perspective_history tool implementation services/search_service.py - Search-related functionality Query generation functions Brave Search API integration services/llm_service.py - LLM-related functionality Perplexity API integration Confidence scoring logic utils/memory_utils.py - Memory-related utilities Memory storage and retrieval functions utils/prevalence_utils.py - Prevalence calculation logic utils/claim_utils.py - Claim type detection and other claim-specific utilities config.py - Constants, version info, and configuration Benefits of this approach:

Improved Readability: Each file has a clear, single purpose Better Maintainability: Easier to update specific components without affecting others Simplified Testing: Each module can be tested independently Enhanced Collaboration: Team members can work on different components simultaneously Reduced Context Size: LLMs can process smaller files more effectively This modular approach would make the codebase more sustainable as it continues to grow and evolve. It also follows software engineering best practices like the Single Responsibility Principle.