-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
Feature Request: Model Family Adaptations for MCP
Is your feature request related to a problem? Please describe.
The Model Context Protocol (MCP) currently lacks a mechanism to adapt prompts, tool descriptions, and parameters based on the specific model family being used. As noted in issue #86, there's an opportunity to implement internationalization (i18n) support, but this could be extended to include model-specific adaptations as well. This creates inefficiencies when different models require different prompt formats or have varying capabilities, forcing developers to maintain separate implementations or complex conditional logic outside the protocol.
Describe the solution you'd like
Extend the Model Context Protocol to include a model family adaptation mechanism that works similarly to the proposed i18n support in PR #115. This would allow:
- Specification of preferred model families in client requests (similar to Accept-Language headers)
- Server-side adaptation of prompts, tool descriptions, and parameters based on the requested model family
- String substitution patterns that can be extracted and updated systematically (similar to i18n localization files)
- The ability to provide "model hints" that suggest optimal formats for specific model architectures
The implementation would build upon the proposed locale support in issue #86, extending it to include model family preferences that can be specified via the Accept header in JSON-RPC requests. For example, a client could specify Accept: application/json; model=anthropic-claude-3 to indicate their preferred model family.
Describe alternatives you've considered
- Client-side adaptations: Requiring clients to handle all model-specific adaptations before sending requests, which increases client complexity and reduces portability.
- Server-side model detection: Automatically detecting model capabilities and adapting on the server side without explicit hints, which would be less precise and harder to customize.
- Static model configuration files: Using separate configuration files for each model family, which would be less flexible than a dynamic approach integrated into the protocol.
Additional context
This feature would build upon the internationalization work proposed in issue #86 and PR #115, but extend it to cover model-specific adaptations. Just as i18n allows for language localization, this feature would allow for "model localization" where prompts and tools can be optimized for specific model families.
The system could support:
- Model family preferences with fallbacks (e.g.,
anthropic-claude-3,openai-gpt-4;q=0.9) - Template variations based on model family (similar to how i18n templates work)
- Automatic adaptation of tool schemas, prompt formats, and parameter descriptions
This would significantly improve interoperability between different models and simplify the development of applications that need to work with multiple model providers or adapt as models evolve.