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.
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 The result carries the check in On
check_use with the prompt it
will send to the generation tool. Your client sends:tools/call
structuredContent:result
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 The agent then calls it with the prompt it checked, the instructions and the token:
authorization argument, and describe it so the agent knows to
fill it:Tool definition
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, A verified token decodes to claims like these:If verification fails, return a tool error and generate nothing. The agent can run
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.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 Embed
jti. It returns the image to
the agent only when the generation is allow.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 The result’s
verify_receipt with the
receipt ID:tools/call
structuredContent is a verification with result: "verified" and the receipt’s
live use_status.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.