Tevyon

Request the user's consent

request_consent

Face Swap, Character Swap, the talking photo and Lip-Sync with an own photo (params.references) show real people. Before they start, the user confirms in Tevyon (signed in) that they hold the rights to the pictures and the consent of everyone shown, including the words they will say. Pass the same job_type and params as for generate; send the user confirm_url, then call generate with consent_id. A consent works once, for exactly these files and words, for two hours: changed words need a new one.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "job_type": "<job_type>",
      "params": "<params>"
    },
    "name": "request_consent"
  }
}

Input Schema

Name	Required	Description	Default
`params`	Yes	Parameters by the model's schema from list_models; prompt is required.
`job_type`	Yes	A job type that needs consent (face_swap, character_swap, video_avatar, lip_sync with references), from list_models.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Besides the annotations (non-read-only, non-idempotent, non-destructive), the description discloses traits the annotations cannot: the consent is single-use, scoped to exactly these files and words, valid for two hours, and must be re-obtained if the words change. It also notes the user must be signed in to Tevyon to confirm, which is a real auth/precondition detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The affected job types are front-loaded and every clause carries information, including the two-hour single-use constraint. Some sentences are dense and the flow phrasing ('send the user confirm_url') is slightly elliptical, but there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description nonetheless implies the response supplies confirm_url and consent_id, and it covers the precondition (signed-in user) and the expiry rule. Minor gaps remain, such as what happens on an expired or mismatched consent, but nothing essential to calling it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description adds cross-tool meaning: job_type and params must mirror the values later sent to generate, and the consent binds those exact files and words. This tells the agent why the parameters must match rather than just what they are.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource (request consent) and precisely enumerates the operations that require it: Face Swap, Character Swap, talking photo, and Lip-Sync with own photo, all tied to params.references. It also implicitly separates this from the sibling 'generate' by framing this as the prerequisite step. An agent can tell what this does and what it is not without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit when: before any generation that shows real people. It gives explicit sequencing: pass the same job_type and params as for generate, send the user confirm_url, then call generate with consent_id. The alternative path (generate without consent) is effectively excluded, so no inference is required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Tevyon tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?