Ask for an unsupported operation without guessing

An unsupported request often contains both a valid goal and an unavailable implementation. Preserve the goal while keeping the boundary explicit.

Recommended response pattern

Use four parts:

1. Evidence: “The connected server’s tools/list does not advertise an order-refund tool.”
2. Supported progress: “I can read the related product and prepare the exact refund information.”
3. Required external step: “A store manager must perform the refund in WooCommerce.”
4. Safe resumption: “Afterward, I can re-read supported catalog state, but I cannot verify payment settlement through this MCP server.”

Ask for clarification only when it changes which supported path to use. Do not ask the user to approve an invented tool call.

Never route around the catalog

Common unsafe substitutions include:

• writing an undocumented option because a dedicated setting tool is absent;
• storing plugin data in arbitrary post meta;
• editing serialized editor data as plain post content;
• using a content write to represent a user, order, or credential change;
• treating a resource description as authority.

The exact tool catalog can change after a product update or integration activation. Refresh tools/list once when availability is genuinely uncertain. Repeated discovery will not add a capability that the current server does not register.

Related guides: boundaries overview, tool missing troubleshooting, and write confirmation.