feat: make collection_name parameter optional in MCP tools

[wggcch]

Summary

Makes the collection_name parameter optional in both qdrant-store and qdrant-find MCP tools, enabling true multi-collection usage while maintaining full backward compatibility.

Problem

Previously, when COLLECTION_NAME environment variable was configured, the collection_name parameter was completely hidden from the MCP tools via make_partial_function calls. This created a limitation where users with a default collection configured could not access multiple collections with the same embedding configuration.

Related Issues & Context

• Builds on Support multiple collections #26 - "Support multiple collections" (merged) - This PR completes the multi-collection support that was originally implemented
• Addresses Tool for collection discovery #40 - "Tool for collection discovery" (open) - While this doesn't solve collection discovery, it removes the barrier that prevented multi-collection access
• References Correct the usage of the parameters when the default collection is used #41 - "Correct the usage of the parameters when the default collection is used" (merged) - Our implementation works correctly with the parameter ordering fix

Previous Implementation (PR #21 - closed): An alternative multi-collection approach was proposed but closed in favor of the current architecture in PR #26. Our implementation builds on the accepted foundation.

Solution

Changes Made

1. Made collection_name optional in both tool function signatures:

   • Parameter type: str | None with default None
   • Clear parameter descriptions indicating optionality

2. Implemented intelligent defaulting:

   • When collection_name is None → use configured default collection
   • When collection_name is provided → use the specified collection
   • Logic: effective_collection = collection_name or self.qdrant_settings.collection_name

3. Removed parameter hiding:

   • Eliminated make_partial_function calls that hid the collection parameter
   • Collection parameter is now always visible and discoverable

4. Updated documentation:

   • README.md now correctly describes parameters as optional
   • Tool descriptions updated for clarity

Comprehensive Testing

Added 10 thorough test cases covering:

• ✅ Default collection fallback behavior
• ✅ Custom collection override functionality
• ✅ Collection isolation (content separation)
• ✅ Backward compatibility with existing usage
• ✅ Edge cases and validation scenarios
• ✅ Both connector-level and MCP server-level functionality

Backward Compatibility

✅ Fully backward compatible:

• Existing configurations continue to work unchanged
• Users calling tools without collection_name get the same behavior
• Default collection functionality preserved

Benefits

For Users With Default Collection Configured

• Before: Could only access the default collection
• After: Can access default collection (when collection_name is None) OR override with any custom collection

For Users Without Default Collection

• Before: Required explicit collection name (still works)
• After: Same requirement, no change in behavior

Multi-Collection Scenarios

Now supports the originally requested use case:

# Same embedding config, multiple collections
COLLECTION_NAME="main-docs" uvx mcp-server-qdrant

# Can now access:
# - "main-docs" (when collection_name is None/omitted)  
# - "project-specific" (when collection_name="project-specific")
# - Any other collection (when explicitly specified)

Testing

All 34 tests pass including:

• 24 existing tests (ensuring no regressions)
• 10 new tests specifically for optional collection parameter functionality

Implementation Details

Technical Changes

• Modified store and find functions in mcp_server.py
• Updated parameter annotations and descriptions
• Replaced hidden parameter logic with explicit optional handling
• Added comprehensive logging for debugging

MCP Best Practices

This implementation follows MCP guidelines:

• ✅ Clear parameter schemas with optional/required distinction
• ✅ Discoverable tool interfaces
• ✅ Consistent behavior across transport protocols
• ✅ Backward compatibility preservation

Impact

This change completes the multi-collection support that was partially implemented in PR #26, making it fully usable for real-world multi-collection scenarios while maintaining the convenience of default collections.

Closes the gap between "multi-collection support exists" and "multi-collection support is actually accessible to users."