Use least-privilege scopes with OfflineCreator MCP

Choose the smallest OfflineCreator scope for the task

OfflineCreator's live protected-resource metadata advertises three scopes: models, read, and generate. The published @offlinecreator/mcp 0.1.2 server maps list_models to models; get_credits, list_generations, get_generation, wait_generation, and download_output to read; and generate, upload_input, and cancel_generation to generate. That is the concrete scope-to-tool mapping available in public first-party artifacts on August 9, 2026.

Start from the action the client must perform, not from a blanket request for all advertised scopes. A client that only compares the launch catalog and costs needs models under the published mapping. A client that checks balance or follows existing jobs needs read. A client that starts work, supplies an image, or cancels a reserved generation needs generate. When one workflow crosses boundaries, request the union needed for that workflow and no more.

models

list_modelsUse for catalog, workflow, and cost discovery in the published package.

read

get_credits, list_generations, get_generation, wait_generation, download_outputUse for account balance and existing-generation status or output access.

generate

generate, upload_input, cancel_generationUse when the client may start, submit, or cancel generation work.

Match common client jobs to grants

For model shopping without account inspection, begin with models. Adding read would expose balance and generation-history tools that the stated task does not require. For a monitoring client that never creates work, use read and add models only if it must resolve model metadata. For an image or video creation client, generate covers the published mutation tools. In the published package, generate with wait:true can wait internally after starting work, and upload_input with wait:true can wait internally after submitting an uploaded image; those internal waits remain part of generate-scoped calls.

Do not infer that generate automatically contains the separate read or models tool groups. The public metadata lists three names without a hierarchy, and the published package checks whether each registered tool's required name is present. A workflow that starts a job and then separately calls wait_generation needs both generate and read. By contrast, a direct generate call with wait:true needs generate, plus models only if the client must first discover a model. An image-to-video flow can discover a model, reserve work, upload input, and wait through upload_input with models plus generate; read is added only for separate status, history, wait_generation, or download calls.

Catalog review

modelsLists available models without adding balance, history, or generation tools.

Job monitor

readChecks credits and existing generation state without adding creation tools.

Create and wait

generateUse generate({wait:true}) or upload_input({wait:true}) when the same generate-scoped call should wait internally.

Discover, create, and wait

models + generateAdds catalog discovery while keeping internal waiting inside the generate-scoped call.

Separate follow-up

readAdd read for distinct wait_generation, status, history, credit, or download tool calls.

Understand what package filtering proves

In the published 0.1.2 package, each tool name has one required scope. During server construction, the package skips registration when the supplied scope array does not include that required name. This means the resulting local stdio or API-key fallback server exposes only registered tools for a nonempty scope list. The same source also treats an absent or empty scope array as allowing every tool, so callers should not describe an unscoped package instance as least privilege.

This code is evidence for the published package, not a runtime audit of the hosted remote OAuth service. OfflineCreator's product page says remote clients use tools authorized by the OAuth connection or fallback personal API key, and the live metadata advertises the three scope names. This research did not connect a client or compare tools/list responses under different OAuth grants, so it cannot establish that the hosted service uses precisely the package's registration path.

Prefer operation-specific requests and step-up authorization

The July 28, 2026 MCP authorization specification tells clients to request only scopes necessary for their intended operations. For initial authorization, it prioritizes a scope value supplied in the server's WWW-Authenticate challenge; if no challenge scope is available, it falls back to scopes_supported in protected-resource metadata. It also treats a later insufficient_scope challenge as authoritative for the current operation and describes requesting the union of current and newly required scopes.

Applied here, that guidance means a client should not automatically turn OfflineCreator's metadata list into an all-scopes request when a narrower challenge or known task is available. Begin with models for discovery, for example, and step up to generate only when creation is requested. Add read when the client separately calls wait_generation or another status, history, credit, or download tool; generate({wait:true}) and upload_input({wait:true}) can perform their own internal wait while remaining generate-scoped. The specification defines scope selection, while OfflineCreator's published package defines these product-specific tool behaviors.

Test denial, discovery, and workflow completion

A least-privilege review needs both a positive and a negative test. With models only, confirm that list_models is available and that read- and generate-group tools are not exposed by the package instance. With read only, confirm that status and output tools work while generate, upload_input, and cancel_generation remain unavailable. With generate only, confirm that mutation tools are present, that generate({wait:true}) and upload_input({wait:true}) can wait internally, and that the separate wait_generation and download_output tools remain unavailable.

Then test the smallest complete workflow rather than only tool discovery. A create-and-wait client should succeed with generate alone when it uses a generate-scoped wait:true path. A workflow that starts work and later invokes wait_generation as a separate tool should require generate plus read. Record the client, transport, package or hosted endpoint, requested scopes, granted scopes, visible tools, and denied calls. MCP's current security tutorial recommends splitting catch-all permissions by tool or capability where possible and checking required scopes at the resource server; it does not make the product-specific mapping for OfflineCreator.

Use the next security check that matches your connection

For remote OAuth, inspect the requested and granted scope set during connection, then repeat tools/list and denied-call tests after any step-up. For a fallback personal API key, select only the groups required by the automation and verify the resulting package tool list. Revisit OAuth flow and revocation separately: scope minimization limits authority, but it does not establish how tokens are stored, refreshed, or invalidated.

Evidence boundary and unresolved gaps

The supported answer is narrow: public metadata advertises models, read, and generate; the public 0.1.2 package supplies a nine-tool mapping and filters registration for nonempty scope arrays; the product page says OAuth connections or fallback keys authorize MCP tools; and current MCP guidance favors task-specific scopes and operation-specific challenges. None of those sources is an independent security audit.

Recent community evidence contributes no claim to this page. The August 9, 2026 engine pass returned 65 items with zero OfflineCreator-specific scope-to-tool records after classification, and source coverage was degraded by Reddit HTTP 429, Instagram HTTP 404, and unconfigured X. This page therefore relies on current primary product artifacts and MCP documentation rather than community anecdotes. The incomplete community pass must not be read as evidence that discussion was absent.

This pass did not authorize a production OAuth client, create scoped keys, invoke tools, inspect a consent screen, compare hosted tools/list results, test insufficient_scope challenges, or verify server-side denial after direct calls. It also did not establish whether hosted OAuth uses the public package's exact filtering code. Treat the mapping as current published evidence and require runtime tests before a security approval.