Skip to content

Move Prompt object instantiation from server to prompt manager #687

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 0 commits into from

Conversation

ramjibc
Copy link

@ramjibc ramjibc commented May 12, 2025

The Prompt() decorator in server.py is instantiating a Prompt object before adding it to the list of prompts. This is inconsistent with how the Tool() decorator works; it delegates tool instantiation to the tool manager.

Motivation and Context

To make the decorators consistent and create clear separation of concerns: I have moved prompt object instantiation from server.py to prompts/manager.py.

How Has This Been Tested?

I updated and ran all unit tests.

Breaking Changes

No. Users will not be impacted as the prompt() decorator's signature remains unchanged.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

Separation of concerns: instantiation and managements of prompt objects should be done by the prompt manager, not the server.

Copy link
Contributor

@ihrpr ihrpr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for working on this!
There are a few concerns:

  1. API Change for Direct Usage: The add_prompt() method signature changes from accepting a Prompt to accepting a function. This breaks backwards compatibility.
  2. Less Flexibility: With the old design, users could create custom Prompt objects with specific configurations before
    adding them. Now they're forced to use the manager's instantiation logic.
  3. Inconsistent Manager APIs: While this makes server decorators consistent, it makes the manager APIs inconsistent:
    • ToolManager.add_tool() accepts both functions and Tool objects
    • PromptManager.add_prompt() now only accepts functions

@ramjibc
Copy link
Author

ramjibc commented Jun 1, 2025

Thank you for the review @ihrpr . I have addressed your comments, but primarily from the backward compatibility perspective. Also, I don't see this in code

Inconsistent Manager APIs: While this makes server decorators consistent, it makes the manager APIs inconsistent:
ToolManager.add_tool() accepts both functions and Tool objects
PromptManager.add_prompt() now only accepts functions

I see ToolManager.add_tool() taking only a function as input.

In any case, I have made changes such that the code doesn't break for existing users but moves it a bit closer to achieving clear separation of concerns. Let me know your comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants