🚀 Try Zilliz Cloud, the fully managed Milvus, for free—experience 10x faster performance! Try Now>>

Milvus
Zilliz
  • Home
  • AI Reference
  • What is the recommended file/folder structure for an Model Context Protocol (MCP) server project?

What is the recommended file/folder structure for an Model Context Protocol (MCP) server project?

The recommended file/folder structure for a Model Context Protocol (MCP) server project should prioritize clarity, modularity, and scalability. A typical structure includes separate directories for application code, configuration, models, services, and documentation. For example, a root directory might contain folders like src/ (core application logic), config/ (environment settings), models/ (model definitions and weights), routes/ (API endpoints), and tests/ (test suites). This separation ensures components remain isolated, making the project easier to maintain and extend. Root-level files like Dockerfile, requirements.txt, and README.md provide essential setup and deployment instructions.

Key directories include src/services for business logic (e.g., model inference pipelines), src/middleware for authentication or logging, and src/schemas for data validation classes. The models/ directory could store model binaries, version-specific subfolders (e.g., v1/, v2/), and preprocessing scripts. Configuration files in config/ (e.g., settings.yaml) centralize environment variables and server parameters. API routes in routes/ define endpoints like /predict or /health and delegate logic to services. Tests should mirror the source structure, with tests/unit and tests/integration validating individual components and end-to-end workflows. Utility scripts for deployment or data processing might reside in scripts/.

Additional considerations include a docs/ folder for API specifications (e.g., OpenAPI YAML files) and architecture diagrams. Use a .env file for environment-specific secrets (e.g., API keys), but exclude it from version control. Include a docker-compose.yml for local development with dependencies like databases. For example, a model cache service in docker-compose.yml could link to the MCP server. Log files might be stored in logs/, with rotation policies defined in the application code. This structure balances practicality with flexibility, allowing teams to adapt it to specific needs while maintaining consistency across environments.

Like the article? Spread the word