You are reviewing a third-party MCP server. Its elicitation schema includes a card number field, and the author argues it is safe because the user can decline and the value is only sent to their own payment provider. What is the strongest objection?

The principle — When a specification names a category of data and forbids a mechanism for it, the review question is not how careful the implementation is but whether the mechanism was allowed.

Why the key is correct — The text is a prohibition with an enumerated list: privacy considerations: servers must not use form mode to request sensitive information such as passwords, API keys, access tokens, or payment credentials. A card number is a payment credential. The remedy is not to abandon the flow but to relocate it, because those interactions belong in URL mode, which keeps the data out of band so it never passes through the client or the LLM context. That mode exists for this: the interaction happens out of band and its data never passes through the client, which makes this mode suitable for sensitive flows such as credential entry or third-party OAuth authorization.

Why the others are wrong — The user's ability to decline is real but does not turn a barred mechanism into an allowed one. Naming the server as the sole risk understates the rule, which is also about the client and the model's context. And abandoning the requirement is stricter than the specification, which supplies a compliant way to meet it.

Remember this — The fix for a barred field is a different mode, not a more careful form. Reviewing against a named prohibition is faster and more reliable than reviewing against a judgement of risk, and it is the reason the list is enumerated: an author defending a design on care rather than on mechanism has already skipped the only question the review needed to ask.

Sources — MCP first-party documentation.