The affordance manager was experiencing race conditions where client tools were called before the manager was fully initialized, leading to "Affordance manager not available" errors. This has been fixed with a comprehensive solution that ensures:

1. Singleton Pattern: Only one affordance manager instance is created per session
2. Promise-based Initialization: Proper async initialization with waiting mechanisms
3. Immediate Availability: Manager is created as soon as possible, not waiting for MCP connections
4. Reliable Access: Client tools wait for manager availability with detailed error reporting

Before:

• Multiple instances could be created
• No coordination between creation attempts
• Direct constructor access

After:

• Static getInstance() method ensures singleton
• Promise-based initialization prevents race conditions
• Private constructor prevents direct instantiation
• isInitialized() method for status checking
• reset() method for cleanup

Before:

• Required MCP clients to be connected before creating manager
• Could create multiple instances
• Restoration tied to creation

After:

• Creates manager immediately when client pool is available
• Separates manager creation from affordance restoration
• Defers restoration until MCP clients connect (if needed)
• Better logging and error handling

Before:

• Immediate failure if manager not available
• Simple error messages
• No waiting mechanism

After:

• getAffordanceManager() function waits up to 15 seconds
• Detailed error messages with status information
• Progressive logging during wait
• Fallback to passed manager parameter

New Tool: check_affordance_status

• Reports detailed initialization status
• Shows MCP client pool availability
• Indicates singleton initialization state
• Provides debugging information

1. App starts → Config loads → Client pool created
2. AffordanceManager.getInstance() called immediately
3. Singleton instance created and made globally available
4. If MCP clients connected OR no servers configured:
   → Restore persistent affordances immediately
5. If MCP servers configured but not connected:
   → Defer restoration until clients connect
6. Client tools use getAffordanceManager() which:
   → Returns immediately if available
   → Waits up to 15 seconds with progress logging
   → Provides detailed error if timeout

• Immediate Availability: Affordances work as soon as app loads
• No Race Conditions: Tools always work when system is ready
• Better Error Messages: Clear feedback about what's happening
• Offline Support: Works without MCP servers

• Predictable Lifecycle: Clear initialization sequence
• Singleton Safety: No duplicate instances
• Comprehensive Logging: Easy debugging
• Status Monitoring: Built-in status checking

• Reliable Interface: Tools work consistently
• Status Visibility: Can check initialization progress
• Clear Error Handling: Helpful error messages
• Immediate Feedback: No silent failures

• Use check_affordance_status to monitor initialization
• If tools return "not available" errors, wait and retry
• Errors now include detailed status information
• Persistent affordances restore automatically when ready

• Use AffordanceManager.getInstance() instead of constructor
• Manager is available immediately after client pool creation
• Check AffordanceManager.isInitialized() for status
• Use AffordanceManager.reset() for cleanup

1. App Still Loading: Tools wait with progress logging
2. MCP Servers Configured but Not Connected: Manager works, restoration deferred
3. No MCP Servers: Manager works immediately
4. Initialization Failure: Detailed error messages with status
5. Multiple Initialization Attempts: Singleton prevents duplicates

• Test with no MCP servers (offline mode)
• Test with MCP servers that fail to connect
• Test rapid tool calls during initialization
• Test page refresh with persistent affordances
• Test error scenarios and timeout handling

• [App] prefix for app-level initialization
• [AffordanceManager] prefix for manager operations
• [getAffordanceManager] prefix for tool access
• Progress logging every 2 seconds during waits

Use check_affordance_status to get:

• Manager availability status
• MCP client pool status
• Connected client count
• Singleton initialization state
• Detailed debugging information

This implementation ensures the affordance system is robust, predictable, and provides clear feedback about its readiness state.