For Template URI Completions with > 1 substitution variable as a String, each get the same value

[jwflicker]

Bug description

 @McpComplete(uri = "file://workspace/{project}/{projectRelativePath}")
   	public List<String> completeRelativePath(
   			@McpProgressToken String progressToken,
   			String project, String projectRelativePath) {

For an @McpComplete implementation like above, the two String params receive the same value. And there is no indication which argument the completion is for.

There is enough data higher in the stack at AbstractMcpCompleteMethodCallback.buildArgs() to figure this out:

but in this condensed form of String args i'm not sure there is enough context to react:

IIRC what i've seen elsewhere is that arguments are assumed to get filled in serially, and that values in the request.context.arguments are considered 'complete' and that the parameter currently needing completion is in the request.argument.

Environment
Please provide as many details as possible: Spring MCP version, Java version, which vector store you use if any, etc

Steps to reproduce
Steps to reproduce the issue.

Expected behavior
A clear and concise description of what you expected to happen.

Minimal Complete Reproducible example
Please provide a failing test or a minimal complete verifiable example that reproduces the issue.
Bug reports that are reproducible will take priority in resolution over reports that are not reproducible.

[tzolov]

Hi @jwflicker,

Thanks for exploring this. Currently, you can use CompleteRequest to receive the entire request, including CompleteContext:

@McpComplete(...)
public CompleteResult completeCountryName(CompleteRequest request) {
  ...
}

For consistency, we should support CompleteRequest.CompleteContext parameters the same way we handle CompleteRequest.CompleteArgument.

However, supporting CompleteContext arguments individually would require new dedicated annotations (like @McpCompleteArg and @McpCompleteContextArg) since we can't rely on parameter order. I'm not convinced these additional annotations would be that useful.

Let's start by adding support for CompleteRequest.CompleteContext parameters first.

[tzolov]

Thinking about this it seems that we might need McpCompleteArg after all to be able to reliably identify the completion argument or perhaps try to reuse the @McpArg.