How prompt moderation applies to MCP and CLI generations

Apply Studio policy to MCP and CLI requests

OfflineCreator's Terms and Acceptable Use Policy expressly cover the web Studio, personal API keys, MCP server, and CLI. They make the account holder responsible for automated and agent-driven requests. The current MCP and CLI page separately describes those interfaces as access to the cloud Studio service, with generation inputs sent to the disclosed provider rather than processed locally, and states that the same credits, model costs, moderation, and automatic refunds apply outside the browser.

The reviewed generation service screens a prompt before provider dispatch, and the policies say providers apply their own safety systems. This evidence supports a Studio screening step and a separate provider boundary; it does not prove that every client transport has an identical implementation path. Passing the Studio screen does not override account rules or guarantee provider acceptance.

Follow the current prompt-screening sequence

The reviewed moderation implementation trims the prompt, rejects text shorter than three characters or longer than 2,000 characters, and checks a defined set of blocked patterns. A blocked match returns a policy-conflict reason instead of proceeding. These are implementation facts from the reviewed repository snapshot, not a complete restatement of every rule in the Acceptable Use Policy.

In the reviewed generation service, this prompt check occurs before adult-content entitlement handling, rate-limit checks, credit reservation, and submission to fal.ai. That ordering matters during troubleshooting: a moderation rejection is not a provider failure and should not be diagnosed by repeatedly changing clients or retrying the same request through another Studio surface.

1. Validate

Prompt length and request shapeThe generation request schema and moderation function enforce the current three-to-2,000-character boundary.

2. Screen

Hard policy patternsA match returns a MODERATION error before generation work is reserved or dispatched.

3. Continue

Entitlement and operational checksOnly an allowed prompt advances to later account, rate, credit, and provider steps.

Separate hard blocks, restricted uses, and provider decisions

The current Acceptable Use Policy prohibits sexual content involving minors, non-consensual intimate imagery, fraud instruments, credible threats or facilitation of violent wrongdoing, malware, infrastructure compromise, and attempts to circumvent moderation, safety systems, rate limits, or authentication. It also places conditions on deceptive depictions of identifiable people and says higher-risk political, medical, financial, employment, housing, and legal uses may require disclosure or human review.

The current code is narrower than the policy text: its hard-pattern list covers specified child-sexual-content phrasing, non-consensual content, sexual deepfakes, certain fake identity documents, and graphic torture or dismemberment phrasing. It separately detects specified adult sexual terms and checks an active Studio subscription, while explicitly preserving the hard blocks. Do not read that implementation detail as permission for any use forbidden by policy or law.

Hard block

A subscription does not override itThe reviewed code keeps acceptable-use blocks separate from adult-content entitlement handling.

Restricted use

Add disclosure or human review where requiredPolicy obligations can apply even when a prompt does not match a local blocked pattern.

Provider decision

An upstream safety system can still refusePassing one screening layer is not a guarantee of generation or downstream usability.

Handle a rejection without trying to evade it

When an MCP or CLI generation is rejected, preserve the error category and review the requested outcome against the Acceptable Use Policy before rewriting anything. Clarifying an ordinary creative request is different from disguising prohibited intent. The policy expressly forbids evading moderation, and the Terms identify safety-control bypass as grounds for limiting, suspending, or terminating access.

The Acceptable Use Policy documents human review only when an account has been actioned: the user may reply to the enforcement notice or email support within 30 days. It does not document a separate appeal process for one blocked prompt. For a possibly mistaken prompt rejection, keep the intended outcome explicit, avoid obfuscation or credential cycling, and do not represent the account-action appeal as a guaranteed prompt-level remedy.

MODERATION

Stop and compare the request with policyDo not retry the same prohibited intent through web, MCP, CLI, or another key.

Provider refusal

Treat it as a separate upstream decisionA provider may apply additional restrictions after Studio screening.

Possible false positive

Do not claim a prompt-level appealThe published human-review route is limited to an account action the user believes was wrong.

Evidence limits for this moderation guide

The supported boundary is narrow: the policies cover MCP and CLI use, the reviewed code shows the current prompt checks and their order, and the Privacy Policy describes cloud-provider processing. None of those sources measures screening accuracy, recall, false-positive rates, or safety effectiveness, so this guide makes no such claim.

The blocked-pattern implementation is not a complete copy of the Acceptable Use Policy, and passing it is neither permission for a prohibited use nor a promise that a provider will accept the request. Community findings are not used to support any factual passage on this page; coverage limitations remain in the research brief for editorial review.