You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement tool conflict resolution for Virtual MCP Server (#2365)
* Implement tool conflict resolution for Virtual MCP Server
Add three conflict resolution strategies (prefix, priority, manual) to handle
duplicate tool names across multiple backend MCP servers in vMCP aggregation.
This implements the aggregation conflict resolution portion of the Virtual MCP
Server proposal (THV-2106), enabling vMCP to merge capabilities from multiple
backends while resolving naming conflicts.
Key features:
- Prefix strategy: automatically prefixes tools with workload identifier
(supports {workload}_, {workload}., custom formats)
- Priority strategy: explicit ordering with first-wins semantics
(drops lower-priority conflicting tools with warnings)
- Manual strategy: requires explicit overrides with startup validation
(fails if any conflicts lack overrides, safest for production)
- Reuses existing mcp.WithToolsFilter/Override middleware logic
- Per-backend tool filtering and overrides applied before conflict resolution
- Tracks conflict metadata (count resolved, strategy used)
Implementation:
- Extracted shared filtering/override logic from pkg/mcp/tool_filter.go
- Created applyFilteringAndOverrides() as single source of truth
- Both HTTP middleware and aggregator use the same battle-tested code
- Updated defaultAggregator to integrate conflict resolver
- Comprehensive table-driven unit tests for all strategies
This follows DDD principles with clear bounded contexts and maintains
backward compatibility with existing middleware behavior.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <[email protected]>
* Address review comments on tool conflict resolution
- Add nil check in tool_adapter.go to prevent panic when tool not found in originalToolsByName map
- Add comment explaining O(n²) complexity is acceptable for small tool lists
- Improve warning message when priority strategy drops tools from backends not in priority list
- Show which backends were involved when dropping conflicting tools
Co-authored-by: Juan Antonio Osorio <[email protected]>
* Add clarifying comments for conflict resolution logic
Address review feedback by adding detailed comments explaining:
1. What "resolved conflict" means in the context of conflict resolution:
- Prefix strategy: Renaming tools proactively prevents collisions
- Manual strategy: Explicit overrides resolve existing conflicts
- Priority strategy: Drops duplicates rather than renaming
2. Manual resolver validation: Documents that collision detection after
override prevents new conflicts from being introduced by bad config
These clarifications help reviewers understand that renaming IS conflict
resolution, not just a side effect.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <[email protected]>
* Remove ConflictsResolved counter from aggregation metadata
Remove the ConflictsResolved counter as it was not defined in the proposal
and caused confusion about what constitutes a "resolved conflict" vs a
preventive renaming.
The ConflictStrategy field remains to indicate which resolution approach
was used (prefix, priority, manual), which is sufficient for observability.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <[email protected]>
* Refactor conflict resolvers into separate files
Split conflict_resolver.go into focused files for better code organization:
- prefix_resolver.go: PrefixConflictResolver implementation
- priority_resolver.go: PriorityConflictResolver implementation
- manual_resolver.go: ManualConflictResolver implementation
- conflict_resolver.go: Factory function and shared helpers
Each strategy now has its own file, making the code easier to navigate
and maintain. Shared helpers (groupToolsByName, toolWithBackend) remain
in conflict_resolver.go for reuse.
No functional changes - pure refactoring.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <[email protected]>
* Use prefix strategy as fallback in priority resolver
Change priority resolver to use prefix strategy for backends not in the
priority list instead of dropping their conflicting tools. This prevents
data loss while maintaining explicit control for prioritized backends.
Behavior:
- Backends in priority list: priority strategy (first wins)
- Backends NOT in priority list with conflicts: prefix strategy fallback
- Example: priority_order=["github"], but slack+teams both have "send_message"
Result: "slack_send_message" and "teams_send_message" (both included)
This addresses review feedback about dropping tools unnecessarily and
provides a more practical default behavior.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <[email protected]>
---------
Co-authored-by: Claude <[email protected]>
Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
Co-authored-by: Juan Antonio Osorio <[email protected]>
0 commit comments