Skip to main content
Planned design guide. The Talent API MCP server and its OAuth flow are not available. The tool calls below describe the intended interface. Use the test-mode HTTP quickstart for a runnable integration. Start with the runnable quickstart and sandbox support matrix.
An agent checks a use with the check_use tool and passes the authorization it gets to the tool that generates. That tool verifies the token before it runs. The check tells the agent what is allowed; the verification in the tool is what enforces it. This design describes both sides using the fictional talent Maya Okafor. The Talent API MCP interface is not yet available.
1

Export your test key

2

Get your account ID

An authorization token names the platform it was issued to in aud. In this design your account is both the platform and the licensee, so your tool accepts tokens whose aud is your own account ID.
3

Review the planned MCP interface

No Talent API MCP connection can be configured yet. The proposed OAuth transport and scopes are described in MCP design. The existing Licensed Studio MCP and Mintlify docs-search MCP have different purposes and do not supply these tools.The proposed interface has ten tools. Their arguments mirror the API request bodies and parameters:
4

Check the use

When the agent is asked for an image of a real person, it calls check_use with the prompt it will send to the generation tool. Your client sends:
tools/call
The result carries the check in structuredContent:
result
On deny, the agent tells the user reasons[].sentence and does not call the generation tool. An agent that can come back to the conversation can pass on_escalate: "hold" instead. On escalate, it tells the user the request is with a reviewer and reads the outcome later with get_check, passing { "check_id": "chk_…" }.
5

Pass the token to your tool

Give your generation tool an authorization argument, and describe it so the agent knows to fill it:
Tool definition
The agent then calls it with the prompt it checked, the instructions and the token:
tools/call
6

Verify the token in the tool

Before the tool runs anything that names a person, it verifies the token offline against the JWKS: the signature, typ, iss, that aud is your account, exp and iat with at most 60 seconds of leeway, that tlp.ver is 1.x and every obligation type is one it handles, that the model matches, and that it has run fewer than max_generations for this token’s jti.
A verified token decodes to claims like these:
If verification fails, return a tool error and generate nothing. The agent can run check_use again:
result
7

Generate and submit the output from the tool

Generate with the prompt and the instructions. The tool holds the bytes, so it submits them itself with your secret key, naming the check from the token’s jti. It returns the image to the agent only when the generation is allow.
Embed c2pa in the image’s C2PA manifest, as in Embedding provenance, and return the image with the disclosure text. When the agent holds the output instead of the tool, it calls submit_generation with the same arguments. A video, or an output held for release, returns status: "checking" or "held"; the agent reads the decision later with get_generation, passing { "generation_id": "gen_…" }, and delivers only on allowed or released.
8

Verify the receipt from the agent

Anyone downstream can check what the agent produced. The agent calls verify_receipt with the receipt ID:
tools/call
The result’s structuredContent is a verification with result: "verified" and the receipt’s live use_status.
An agent can skip check_use. A tool that generates without verifying the token gives the talent no protection, so verify on every call that can produce a real person.

Next

Agent builders

Token passing, tool-side verification and caching in production.

MCP tools

Each tool, its arguments and results.

Authorization token

Every claim, and the verification rules.

Model providers

Verifying tokens at an inference API.