Sume MCP generation_admission_rejected: read the preview first

A Sume paid MCP call fails with generation_admission_rejected when the generation admission preview says it would not accept the request. The error carries the whole preview, so read it, change the request or wait, and only then retry; do not strip your spend cap to get past it.

Where it is thrown

Paid creates on the hosted MCP price the request with the admission preview before they submit. If the preview does not report that it would accept the request, the call stops with this code and returns the preview object. The same check guards the fixed-price path and the avatar preview-to-video step, so you can meet it from several tools. Nothing has been submitted when it fires.

What to read in the preview

Do not parse prose. Keep the preview as data and show the agent the fields it needs: whether it would be accepted, the usage estimate, and any adjustments. Generation concurrency and queue capacity depend on the plan, so a rejection under load is often a capacity message and not a problem with your payload. The preflight post shows how to read balance first.

Handler

A small router keeps the refusals apart.

def route(err: dict) -> str:
    code = err.get('code')
    if code == 'generation_admission_rejected':
        return 'inspect preview, change request: ' + str(err.get('preview'))
    if code == 'max_spend_exceeded':
        return 'ask user to raise cap or shrink job'
    if code == 'missing_usage_estimate':
        return 'stop; do not retry without a cap'
    return 'unhandled: ' + str(code)

print(route({'code': 'generation_admission_rejected', 'preview': {'would_accept': False}}))

Limits

The preview is advisory about price and acceptance at that moment. A call that passes can still fail later for provider reasons, and those arrive as a failed job, not as this code.

Three refusals that look alike

A rejected preview, an estimate above your cap and a missing estimate are three different refusals with three different codes. Mixing them up leads an agent to drop the cap, which is the one thing that turns a refusal into an unbounded spend. Keep the codes separate in your handler and give each its own next action.

Checklist before you ship

• Log the whole preview object from the error, not only the message.
• Do not remove max_spend_usd to get past the rejection.
• Check the balance and the concurrency headroom before resending.
• Change the request, or wait, before the next attempt.