MCP tool scopes for models, reading, and generation

The short answer: scopes change what the model can discover

MCP tool scopes are permission labels carried by an authenticated request. A server can use them when answering `tools/list`, so the model receives only the tool definitions authorized for that caller. In the current 2026-07-28 MCP tools specification, the available set may be empty and may vary with request authorization. That makes scope filtering a discovery boundary, not merely an error check after a model has already selected a forbidden tool.

For OfflineCreator's published implementation, the three labels are `models`, `read`, and `generate`. They divide catalog discovery, account and job reading, and generation-changing operations. A models-only credential can expose model discovery without account history or generation controls. A read-only credential can expose balance, status, waiting, output retrieval, and recent jobs without a generation starter. A generate-only credential can expose creation, input upload, and cancellation without automatically exposing account reads. A credential with multiple labels receives the union of those groups.

models

Discover the model catalogExposes `list_models` in the published scope map.

read

Inspect account and generation stateExposes credits, recent jobs, status, waiting, and output retrieval.

generate

Start or change generation workExposes generation creation, input upload, and cancellation.

Read the scope matrix as a set of capabilities

The practical question is not whether one scope is “higher” than another. The published code treats the three names as independent membership checks, with no documented hierarchy in which `generate` silently implies `read` or `models`. Combining `models` and `read` therefore exposes six tools: model listing plus the five read operations. Adding `generate` exposes all nine published tools. This is a product-specific map, not a universal MCP vocabulary; another server can define different scope names and semantics.

The separation is useful because discovery shapes the model's available actions. If a workflow only compares current models and advertised credit costs, `models` is the narrow group. If an operator is diagnosing an existing generation, `read` covers status and output retrieval without offering a new generation call. A workflow that must submit media needs `generate`, but it may also need `models` to choose a valid model and `read` to observe the returned job. Grant the combination required by the full workflow rather than assuming one broad label contains the others.

Catalog-only

modelsUseful when the task ends at model discovery.

Observe existing work

readUseful for balance, job status, waiting, output retrieval, and history.

Create and follow a job

models + generate + readUse the union when discovery, submission, and later observation are all required.

How the published registry filter is implemented

The public `@offlinecreator/mcp` 0.1.2 package defines one table from each of its nine tool names to a required scope. Its server factory accepts an optional scope array. During server construction, a registration helper looks up the required label and returns without calling `registerTool` when that label is absent. The resulting MCP registry is therefore assembled from permitted entries before `tools/list` is answered; disallowed definitions are not registered in that scoped server instance.

This matters more than hiding a button in a client. Tool descriptions and input schemas can enter model context during discovery, so excluding an unauthorized tool reduces both callable surface and irrelevant prompt material. It is still only one layer. The current MCP specification says a server should validate authorization against a returned handle on every call, and the authorization specification requires access-token validation. A filtered list must not be treated as the only enforcement point or as proof that downstream Studio ownership and account checks were tested here.

There is an important compatibility boundary in the package code: when its server factory receives no scope array, or an empty one, the helper allows every registered tool. The bare stdio entry point constructs the server without passing scopes, while the package README says fallback personal keys are scoped. This research verified the published client-side registry code but did not inspect the private Studio endpoint that validates a fallback key or the deployed remote worker that supplies OAuth scopes.

Map

Tool name to one required labelThe package declares the scope requirement in a single table.

Filter

Skip unauthorized registrationA missing required label prevents that tool definition from entering the scoped registry.

Enforce again

Validate every invocation and handleDiscovery filtering is not a substitute for request and object authorization.

Discovery, invocation, and caching are separate checks

A client normally discovers tools with `tools/list`, lets the model select from that response, and invokes a selected name with `tools/call`. The current tools specification permits the list to vary by the authorization attached to each request, not by mutable connection state. It also recommends deterministic ordering while the underlying set is unchanged. A server should therefore derive the same authorized registry for equivalent authorization instead of gradually revealing tools because an earlier call happened on the connection.

If a call needs permission the token lacks, the current authorization specification recommends HTTP 403 with `error="insufficient_scope"` and a `WWW-Authenticate` challenge naming the scopes required for that operation. That error is distinct from a missing tool in a filtered registry and from HTTP 401 for an absent, invalid, or expired token. A client may perform bounded step-up authorization, but it should stop after a few unsuccessful retries.

Caching can otherwise undo correct filtering. The MCP caching specification says a filtered list that varies by user is suitable for `cacheScope: "private"`; caches must not reuse that response across authorization contexts. It also warns that access control must still be applied per primitive and must not rely on cache scope alone. This draft did not capture OfflineCreator's live `tools/list` response, its cache hints, a 403 scope challenge, or a step-up authorization exchange.

Tool is absent

Refresh discovery under the intended authorizationDo not construct a hidden tool call from documentation alone.

401

Repair authenticationThe token is missing, invalid, expired, or otherwise unacceptable.

403 insufficient_scope

Request the named permission or stopUse bounded step-up behavior and preserve previously needed scopes.

Evidence boundary and recent practitioner signal

The protocol claims on this page use the official MCP 2026-07-28 tools, authorization, and caching specifications. The product matrix and registration behavior use the code and README shipped in the public `@offlinecreator/mcp` 0.1.2 package, supplemented by OfflineCreator's live protected-resource metadata and current product page. Those sources establish documented scope names and a published filtering implementation. They do not establish the exact registry returned by the deployed OAuth endpoint to every user.

The refreshed last30days run on August 9 2026 returned 73 complete item records: one arXiv paper, 18 Digg items, 24 GitHub items, five grounding web results, 12 Hacker News stories, six Instagram reels, two Reddit threads, four TikTok videos, and one YouTube video. Item-by-item review classified five as directly relevant to scopes, least privilege, or registry visibility, 21 as marginal context, 39 as irrelevant, four as duplicate URLs, and four as promotional. The five relevant records included the official MCP tools specification, a Descope authorization walkthrough, a GitHub token-to-MCP privilege relay, a Scalekit OAuth token revocation doc, and a FastMCP token audience assertion backport. None established OfflineCreator deployed behavior, and generic introductions, promotions, and comments are not cited as scope evidence.

Coverage remains degraded. Reddit returned two item records with partial status, and X was absent because its optional access was not configured. Techmeme returned zero results. TikTok, Instagram, and YouTube retrieval succeeded, but their results were predominantly generic MCP explanations, tool-calling discussions, or promotional content rather than evidence about authorization scopes. These outcomes must not be interpreted as proof that unavailable channels were silent.

The package version is now @offlinecreator/mcp 0.1.2 (published 2026-08-08). The README lists the same nine tools and the same scope behavior. Live protected-resource metadata at mcp.offlinecreatorstudio.com still advertises models, read, and generate as supported scopes.

Editorial limitation: this draft has no authenticated OAuth flow, personal-key authorization test, `tools/list` comparison across scope combinations, cache test, 401 or 403 capture, generation call, penetration test, independent security audit, or cross-client compatibility test. The page therefore describes the current public specification and shipped package code, while leaving deployed behavior and security outcomes unverified.