Include context into completions #966
Conversation
| return Completion(values=["users_db", "products_db", "analytics_db"], total=3, hasMore=False) | ||
| elif argument.name == "table": | ||
| # Complete table names based on selected database | ||
| if context and context.arguments: |
There was a problem hiding this comment.
maybe overpolishing, but do we want a test where the server errors on not enough context (e.g. "need a database to complete tables" and the client receives it?
| @@ -364,6 +364,24 @@ def decorator(fn: AnyFunction) -> AnyFunction: | |||
|
|
|||
| return decorator | |||
|
|
|||
| def completion(self): | |||
There was a problem hiding this comment.
Is it weird to route all completions to the same function in the high level API? Alternative would be to defer adding the fastmcp decorator for now and do something fancier that routes on URI, but agree that it's nice to bring fastmcp decorator coverage to parity with the lowlevel server.
Also a) maybe it's natural for "real" servers to route all completion requests through the same handler, and b) we could always add new decorators (resource_completion, prompt_completion) later.
There was a problem hiding this comment.
yeah, it is quite weird even on the lowlevel, TS has completions handling on a field that needs to be completed, which I found quite nice.
I'd love to make it nicer, but for now to have at least a way to handle completions on FastMCP level and not do to things like _server.
Details: modelcontextprotocol/modelcontextprotocol#598
Closes: #917
Implementation:
CompletionContexttype with optional arguments field to store previously resolved parametersCompleteRequestParamsto include optional context parametercomplete()method to accept context_arguments parameterAPI Improvements:
completion()decorator method to FastMCP for cleaner API (lowlevel already had it)