Synthesia docs llms.txt vs the Sume Avatar 1.0 guide for AI assistants

Synthesia's docs offer llms.txt and .md pages for agents. Here is how to hand an AI assistant the Sume Avatar 1.0 guide, schema and tool list instead.

5 min readSume
All posts

To get an AI assistant to integrate Sume Avatar 1.0 correctly, give it the Avatar guide pages and the live OpenAPI schema, not a paraphrase. The Sume Avatar 1.0 page in the dashboard also has an LLMs menu that builds a ChatGPT or Claude prompt around the model's llms.txt, and the hosted MCP server exposes a tools_schema call for exact fields.

Synthesia set a convention worth copying. Its documentation hub says to visit https://docs.synthesia.io/llms.txt for an index of all pages formatted in Markdown and endpoints in OpenAPI, and that appending .md to any documentation URL returns a Markdown version. That is Synthesia's own docs; this post is about what Sume offers for the same job.

What does Sume give an assistant to read?

Three things are documented, and they have different jobs.

Where an assistant gets Sume Avatar 1.0 facts (read 2026-10-03)
SourceWhat it is good forWhere
Avatar guidesIntent, limits, which route to usedocs.sume.com/models/avatar and /models/avatar-videos
OpenAPI schemaExact request and response fieldsapi.sume.com/reference/json
Hosted MCP tools_schemaOne tool's input schema at call timeMCP tools_schema with a tool name

How does the LLMs menu work?

On the Avatar 1.0 page of the API dashboard, an LLMs menu fetches the model's llms.txt (path /models/sume/avatar/v1.0/llms.txt on the Sume origin) and opens a new ChatGPT or Claude chat with the prompt "Read this Sume Avatar 1.0 model guide and help me integrate it" followed by the Markdown URL. It is a convenience for a human; an agent running in your own harness should fetch the same pages directly.

The Playground guide says to use the Avatar playground to validate payloads before moving them into server code, CLI commands or agent workflows, and to use the live OpenAPI schema for exact fields.

How should an agent ask for the exact fields?

Under the hosted MCP server, the documented flow for a paid tool is to call tools_schema with the tool name, such as avatars_create, before submitting. The MCP tools and gates page lists the avatar tools: reads (avatars_list, avatars_get, avatars_search, avatar-videos_list, avatar-videos_get) and paid writes (avatars_create, avatar-videos_create, avatar-video-previews_create).

For a CLI-driven agent the equivalent is sume tools schema avatars.create --json and sume tools schema avatar-videos.create --json, which the CLI docs give for inspecting exact request-body fields.

What should the assistant be told not to do?

Give it three rules: submit one bounded job first, confirm paid work with you, and recover an existing job instead of retrying a paid command. Those come straight from the CLI agent guidance, where --confirm-paid is required for Avatar and Avatar Video runs.

The assistant also needs the Avatar basics up front: three input types (prompt, props, photo), public HTTPS image URLs, and a 4-60 second script window. Without them, a generic model tends to invent a body field that does not exist.

What is missing compared with Synthesia?

This post did not confirm a .md suffix convention on docs.sume.com, so it does not claim one. The Avatar 1.0 model has its own llms.txt path, the main site serves a root /llms.txt index, and the OpenAPI schema is public. If you need more than that for your agent, paste the specific guide pages into the assistant's context.

How do you keep the assistant's answers current?

Point it at the live schema each session instead of pasting an old copy. The OpenAPI schema is the contract, and the docs guides explain intent. When a guide and the schema disagree, trust the schema and report the gap.

Keep your API key out of the prompt. Give the assistant the key through its environment or MCP configuration, not in chat text.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume