Skip to content

fix(opencode): resolve MCP prompts with real arguments, not $N placeholders#33639

Open
Haohao-end wants to merge 1 commit into
anomalyco:devfrom
Haohao-end:issue-33564-mcp-prompt-args
Open

fix(opencode): resolve MCP prompts with real arguments, not $N placeholders#33639
Haohao-end wants to merge 1 commit into
anomalyco:devfrom
Haohao-end:issue-33564-mcp-prompt-args

Conversation

@Haohao-end

Copy link
Copy Markdown

Issue for this PR

Closes #33564

Type of change

  • Bug fix

What does this PR do?

MCP prompt commands sent literal $1/$2 strings as argument values to prompts/get when registering commands. Servers that validate argument types (e.g. precision: int) rejected them, logging failed to getPrompt at startup and leaving the command with an empty template.

Since listPrompts argument metadata has no type info, a type-correct placeholder can't be synthesized. Instead, resolve MCP prompt templates at invocation: store prompt metadata in Command.state and add Command.template(name, args), which calls getPrompt with the user's real positional arguments (servers coerce numeric strings). Non-MCP commands are unchanged.

How did you verify your code works?

  • oxlint clean on both changed files
  • types verified against the codebase (noUncheckedIndexedAccess is off, so args[i] is string)
  • repro: a typed-arg MCP prompt (e.g. precision: int) no longer logs $2/$1 conversion errors at startup; invoking it with real args renders the prompt server-side

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

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.

[Bug] MCP prompt arguments receive literal $1/$2 placeholders instead of user input — type validation fails

1 participant