DollhouseMCP

# Dollhouse MCP Status Report *Generated: September 8, 2025* ## System Overview **Dollhouse MCP Version:** 1.7.2 **Runtime:** Node.js v24.1.0 on macOS ARM64 **User:** mickdarling **Status:** Operational with Issues ## ✅ What's Working ### Core System - **MCP Connection**: ✅ Connected and stable - **Configuration Management**: ✅ Working properly - **User Profile**: ✅ Successfully configured (username: mickdarling) - **Sync Enabled**: ✅ Successfully enabled sync functionality ### Local Portfolio Access - **File System Access**: ✅ Full access to `/Users/mick/.dollhouse/portfolio` - **Local Element Discovery**: ✅ Properly reading all element types - **Local Portfolio Structure**: ✅ Complete and well-organized #### Local Portfolio Inventory - **Personas**: ~45 files ✅ - **Skills**: 60+ files ✅ - **Templates**: 35+ files ✅ - **Agents**: 24+ files ✅ - **Ensembles**: 4 files ✅ - **Memories**: 3 files ✅ ### Configuration Settings - **Privacy Scanning**: ✅ Enabled for secrets and PII - **Individual Sync**: ✅ Configured with confirmation and diff preview - **Authentication**: ✅ OAuth enabled - **Element Directory**: ✅ Properly set to local portfolio path ## ❌ Critical Issues ### 1. **GitHub Remote Portfolio Listing - BROKEN** **Problem**: The `list-remote` operation only returns personas (231 items), completely missing other element types. **Expected Behavior**: Should return all element types (skills, templates, agents, ensembles, memories) from GitHub repository. **Current Behavior**: ``` Found 231 elements: **personas** (231): [shows all personas] [NO OTHER ELEMENT TYPES DISPLAYED] ``` **Impact**: - Cannot verify GitHub repository contents - Cannot identify sync discrepancies - Potential data loss risk if other elements aren't actually synced **Attempted Fixes**: - ✅ Tried filtering by element type (`{"type": "skills"}`) - ✅ Tried including private elements (`{"include_private": true}`) - ✅ Verified sync is enabled - ❌ All attempts return same result (personas only) ### 2. **Element Type Filtering - NOT WORKING** **Problem**: When filtering `list-remote` by element type, it still returns all personas instead of the requested element type. **Test Case**: ``` sync_portfolio operation: "list-remote", filter: {"type": "skills"} Result: Returns all 231 personas instead of skills ``` ### 3. **Compare Operation - DISABLED** **Problem**: Cannot compare individual elements between local and remote. **Error**: "Sync is Disabled - Portfolio sync is currently disabled for privacy" **Note**: This occurs even though sync is enabled in configuration (`sync.enabled: true`) ## 🔍 Investigation Needed ### Questions for Developer 1. **Is the GitHub repository structure correct?** - Are skills/templates/agents/ensembles/memories actually in the remote repository? - What's the expected directory structure on GitHub? 2. **Is there a known bug in v1.7.2's `list-remote` functionality?** - Does it properly scan all element type directories? - Are there any known filtering issues? 3. **Why does compare operation report "sync disabled" when sync.enabled = true?** - Is there a separate privacy setting affecting compare operations? - Are there additional permissions needed? 4. **What's the expected behavior for bulk operations?** - Should `bulk-download` and `bulk-upload` work with current configuration? - Are there prerequisites we're missing? ## 🧪 Suggested Tests ### Test 1: Manual GitHub Repository Verification - Developer should manually check GitHub repository structure - Verify all element types are present and properly organized - Compare against local portfolio structure ### Test 2: List-Remote Debugging - Add debug logging to `list-remote` operation - Verify it's scanning all expected directories - Check if element type filtering is functioning ### Test 3: Compare Operation Investigation - Identify why compare reports sync as disabled - Test with minimal element to isolate the issue - Verify privacy settings aren't blocking operation ### Test 4: Alternative Listing Method - Test if there's an alternative way to list remote elements - Consider implementing per-element-type listing - Verify GitHub API connectivity and permissions ## 📊 Configuration Details ```yaml user: username: mickdarling email: null display_name: null github: portfolio: repository_url: null repository_name: dollhouse-portfolio default_branch: main auto_create: true auth: use_oauth: true token_source: environment sync: enabled: true individual: require_confirmation: true show_diff_before_sync: true track_versions: true keep_history: 10 bulk: upload_enabled: false download_enabled: false require_preview: true respect_local_only: true privacy: scan_for_secrets: true scan_for_pii: true warn_on_sensitive: true collection: auto_submit: false require_review: true add_attribution: true elements: default_element_dir: /Users/mick/.dollhouse/portfolio ``` ## 🎯 Priority Actions 1. **HIGH**: Fix `list-remote` to show all element types, not just personas 2. **HIGH**: Fix element type filtering in `list-remote` operations 3. **MEDIUM**: Resolve compare operation "sync disabled" error 4. **MEDIUM**: Enable and test bulk operations 5. **LOW**: Add repository_url to configuration once GitHub sync is verified ## 💡 Notes - User (mickdarling) has a substantial local portfolio that appears well-organized - Most test personas in GitHub listing suggest extensive QA testing has occurred - The abundance of test entries (timestamps in filenames) indicates active development/testing - Local portfolio is significantly more diverse than what GitHub listing shows --- **Report compiled by:** Claude via Dollhouse MCP investigation **Next Steps:** Developer investigation of `list-remote` functionality and GitHub repository structure verification