Thank you for your interest in contributing to the Quilt MCP Server! This guide will help you get started with contributing code, documentation, bug reports, and feature requests.
# Fork and clone the repository
git clone https://github.com/your-username/quilt-mcp-server.git
cd quilt-mcp-server
# Set up development environment
cp env.example .env
# Edit .env with your AWS credentials and Quilt settings
# Install dependencies
uv sync --group test
# Validate setup
make test
make coverageTo test your local changes with Claude Desktop, configure it to use your local development version:
macOS/Linux:
Edit ~/.config/claude/claude_desktop_config.json:
{
"mcpServers": {
"quilt-uvx": {
"command": "uvx",
"args": [
"--from",
"/absolute/path/to/your/quilt-mcp-server",
"quilt-mcp"
]
}
}
}Windows:
Edit %APPDATA%\Claude\claude_desktop_config.json with the same configuration.
Activating changes:
- Save the configuration file
- Quit Claude Desktop completely (Cmd+Q on macOS)
- Restart Claude Desktop
- Your local MCP server will initialize with your development code
Testing workflow:
- Make code changes in your local repository
- Restart Claude Desktop to pick up changes
- Test the functionality in Claude Desktop
- Iterate until satisfied
- Run tests:
make test && make coverage - Commit and push your changes
We use a structured branch naming system:
| Prefix | Purpose | Example |
|---|---|---|
feature/ |
New features | feature/unified-search |
fix/ |
Bug fixes | fix/athena-connection-timeout |
docs/ |
Documentation | docs/api-reference-update |
test/ |
Test improvements | test/real-world-scenarios |
refactor/ |
Code refactoring | refactor/search-architecture |
chore/ |
Maintenance tasks | chore/update-dependencies |
# 1. Create feature branch
git checkout -b feature/your-feature-name
# 2. Make changes
# ... edit files ...
# 3. Run tests
make coverage # Unit tests (must maintain 85%+ coverage)
make test # Integration validation
python test_cases/sail_user_stories_real_test.py # Real-world tests
# 4. Commit with descriptive message
git add .
git commit -m \"Add unified search across multiple backends
- Implement parallel search across GraphQL, Elasticsearch, and S3
- Add intelligent query parsing and result ranking
- Include comprehensive error handling and fallback mechanisms
- Add 15 new test cases covering edge cases
Fixes #123\"
# 5. Push and create PR
git push origin feature/your-feature-name- Keep modules focused by responsibility; prefer extraction over adding unrelated concerns to large files.
- Prefer cohesive architecture over hard LOC thresholds; split when a module mixes concerns or has unclear boundaries.
- Avoid circular imports: move shared contracts/types into dedicated modules (
types/,protocols/, shared helpers). - For backend operations, keep orchestration in
QuiltOpsand implement backend-specific behavior in_backend_*primitives. - Reuse shared helpers (
src/quilt_mcp/utils/helpers.py,src/quilt_mcp/backends/utils.py) instead of duplicating registry/bucket parsing logic.
Good organization examples:
- Package CRUD APIs in
src/quilt_mcp/tools/package_crud.py; S3 ingestion workflow insrc/quilt_mcp/tools/s3_package_ingestion.py. - GraphQL transport in
src/quilt_mcp/backends/platform_graphql_client.py; operation text insrc/quilt_mcp/backends/graphql_queries.py.
When reporting bugs, please include:
Required Information:
- Environment: OS, Python version, MCP client (Claude Desktop, Cursor, etc.)
- Configuration: Relevant environment variables (redact sensitive info)
- Steps to Reproduce: Clear, numbered steps
- Expected Behavior: What should happen
- Actual Behavior: What actually happens
- Error Messages: Full error messages and stack traces
- Minimal Example: Smallest code example that reproduces the issue
When adding new tools, follow this structure:
# app/quilt_mcp/tools/your_new_tool.py
from typing import Dict, Any, Optional
from ..validators import validate_required_params
async def your_new_tool(
required_param: str,
optional_param: Optional[str] = None,
**kwargs
) -> Dict[str, Any]:
\"\"\"
Brief description of what this tool does.
Args:
required_param: Description of required parameter
optional_param: Description of optional parameter
Returns:
Dict containing:
- success: Whether operation succeeded
- data: Tool-specific response data
- message: Human-readable status message
Raises:
ValueError: When required parameters are invalid
ConnectionError: When external service is unavailable
\"\"\"
# Validate inputs
validate_required_params({'required_param': required_param})
try:
# Implementation here
result = await some_async_operation(required_param)
return {
'success': True,
'data': result,
'message': f'Successfully processed {required_param}'
}
except Exception as e:
return {
'success': False,
'error': str(e),
'message': f'Failed to process {required_param}: {str(e)}'
}Tool Requirements:
- Async Support: All tools must be async-compatible
- Error Handling: Graceful error handling with meaningful messages
- Input Validation: Validate all inputs using our validator functions
- Documentation: Comprehensive docstrings with examples
- Testing: Unit tests with 85%+ coverage
- Real-World Testing: Include in integration test scenarios
Unit Tests:
# tests/test_your_new_tool.py
import pytest
from unittest.mock import AsyncMock, patch
from app.quilt_mcp.tools.your_new_tool import your_new_tool
class TestYourNewTool:
@pytest.mark.asyncio
async def test_successful_operation(self):
\"\"\"Test successful tool execution\"\"\"
result = await your_new_tool(required_param=\"test_value\")
assert result['success'] is True
assert 'data' in result
assert result['message'].startswith('Successfully')
@pytest.mark.asyncio
async def test_invalid_input(self):
\"\"\"Test error handling for invalid input\"\"\"
with pytest.raises(ValueError):
await your_new_tool(required_param=\"\")
@pytest.mark.asyncio
async def test_external_service_failure(self):
\"\"\"Test graceful handling of external service failures\"\"\"
with patch('app.quilt_mcp.tools.your_new_tool.some_async_operation') as mock_op:
mock_op.side_effect = ConnectionError(\"Service unavailable\")
result = await your_new_tool(required_param=\"test\")
assert result['success'] is False
assert 'Service unavailable' in result['error']Integration Tests:
# Add to test_cases/comprehensive_test_scenarios.json
{
\"test_id\": \"your_new_tool_integration\",
\"description\": \"Test your new tool with real data\",
\"tool_name\": \"your_new_tool\",
\"parameters\": {
\"required_param\": \"real_test_value\"
},
\"expected_success\": true,
\"validation_checks\": [
\"response.success == True\",
\"'data' in response\",
\"len(response.data) > 0\"
]
}We welcome improvements to:
- API Documentation: Tool descriptions and examples
- User Guides: Installation, configuration, and usage
- Developer Guides: Architecture and contribution instructions
- Examples: Real-world usage scenarios
Documentation Standards:
- Use clear, concise language
- Include code examples for all features
- Test all code examples to ensure they work
- Follow our markdown style guide
- Include screenshots for UI-related documentation
- Unit Tests: Maintain 85%+ code coverage
- Integration Tests: All new tools must have integration tests
- Real-World Tests: Include scenarios in our real-world test suite
- Performance Tests: For tools that may impact performance
# Unit tests (required for all contributions)
make coverage
# Integration tests (required for new tools)
make test
# Real-world scenarios (recommended for significant features)
python test_cases/sail_user_stories_real_test.py
python test_cases/ccle_computational_biology_test_runner.py
# Performance benchmarks (for performance-critical changes)
python test_cases/mcp_comprehensive_test_simulation.py- Use Real Data When Possible: Our tests use actual Benchling and Quilt data
- Mock External Services: Mock AWS services for unit tests
- Provide Test Fixtures: Include sample data for complex scenarios
- Document Test Setup: Clear instructions for running tests
We follow PEP 8 with these specific guidelines:
# Good: Clear function names and documentation
async def create_package_from_s3_objects(
package_name: str,
s3_uris: List[str],
metadata: Optional[Dict[str, Any]] = None
) -> Dict[str, Any]:
\"\"\"
Create a Quilt package from S3 objects with intelligent organization.
Args:
package_name: Name in namespace/package format
s3_uris: List of S3 URIs to include
metadata: Optional metadata dictionary
Returns:
Package creation result with status and details
\"\"\"
# Good: Error handling with context
try:
result = await quilt_operation()
except QuiltAPIError as e:
logger.error(f\"Quilt API error in {operation_name}: {e}\")
return {
'success': False,
'error': f\"Quilt API error: {e}\",
'message': f\"Failed to {operation_name}. Please check your Quilt configuration.\"
}
# Good: Input validation
if not package_name or '/' not in package_name:
raise ValueError(\"Package name must be in 'namespace/package' format\")Use conventional commit format:
type(scope): brief description
Detailed explanation of changes, including:
- What was changed and why
- Any breaking changes
- Related issue numbers
Fixes #123
Closes #456Types:
feat: New featuresfix: Bug fixesdocs: Documentation changestest: Test additions/changesrefactor: Code refactoringchore: Maintenance tasks
Before submitting a PR, ensure:
- Tests Pass: All tests pass with 85%+ coverage
- Documentation Updated: Relevant docs are updated
- Real-World Testing: Significant features tested with real data
- Breaking Changes Documented: Any breaking changes are clearly noted
- Issue References: PR references related issues
## Description
Brief description of changes
## Type of Change
- [ ] Bug fix (non-breaking change that fixes an issue)
- [ ] New feature (non-breaking change that adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update
## Testing
- [ ] Unit tests pass (make coverage)
- [ ] Integration tests pass (make test)
- [ ] Real-world tests pass (if applicable)
- [ ] Manual testing completed
## Checklist
- [ ] Code follows style guidelines
- [ ] Self-review completed
- [ ] Documentation updated
- [ ] Tests added/updated
- [ ] No breaking changes (or clearly documented)
## Related Issues
Fixes #123
Relates to #456
## Screenshots (if applicable)
[Include screenshots for UI changes]
## Additional Notes
[Any additional information for reviewers]- Automated Checks: CI runs tests and coverage analysis
- Code Review: Maintainers review code quality and design
- Testing: Reviewers may test changes locally
- Documentation Review: Ensure docs are accurate and complete
- Approval: At least one maintainer approval required
- Merge: Squash and merge to main branch
| Label | Purpose |
|---|---|
bug |
Something isn't working |
enhancement |
New feature or request |
documentation |
Improvements to docs |
good first issue |
Good for newcomers |
help wanted |
Extra attention needed |
priority: high |
High priority issue |
priority: low |
Low priority issue |
status: blocked |
Blocked by external dependency |
status: in progress |
Currently being worked on |
We organize work into milestones:
- v0.6.0: Next minor release
- v1.0.0: Major release milestone
- Backlog: Future considerations
- Be Respectful: Treat all community members with respect
- Be Inclusive: Welcome contributors from all backgrounds
- Be Constructive: Provide helpful feedback and suggestions
- Be Patient: Remember that everyone is learning
- GitHub Issues: Bug reports and feature requests
- GitHub Discussions: General questions and community chat
- Pull Requests: Code review and collaboration
- Documentation: Check docs/ first
- Issues: Search existing issues before creating new ones
- Discussions: Use GitHub Discussions for questions
- Maintainers: Tag maintainers for urgent issues
Looking for ways to contribute? Here are some areas where we'd love help:
- New MCP Tools: Additional Quilt operations
- Performance Optimization: Faster search and data operations
- Error Handling: Better error messages and recovery
- Documentation: User guides and examples
- Testing: Additional real-world test scenarios
- Monitoring: Observability and metrics
- Security: Security audits and improvements
- Integrations: Support for additional MCP clients
- Documentation Fixes: Typos and clarity improvements
- Test Coverage: Tests for existing functionality
- Code Cleanup: Refactoring and code organization
- Examples: Usage examples and tutorials
- Maintainers: @maintainer1, @maintainer2
- Issues: GitHub Issues
- Discussions: GitHub Discussions
Thank you for contributing to the Quilt MCP Server! π