AIGE

Set a Deck's Handle and Avatar (free)

antix_set_deck_identity

Idempotent

Print the user's handle on every slide of a carousel deck and set their account picture just before it — the avatar is drawn round, sized to the handle, on every slide whose layout prints a handle, and it follows the handle through later edits, layouts and deck shapes. FREE. Change either part alone. handle: exactly as the user gave it ("" prints none). The picture, one way: avatar — a file from this conversation (an upload, or one you made); avatarUrl — a direct link to an image file the user gave (a profile PAGE such as instagram.com/name cannot be read; ask for the picture instead); fromAccount — the Instagram, Threads or TikTok account the user connected in AIGE, which also supplies the handle (Instagram and Threads) unless handle is given. removeAvatar:true takes the picture away. avatarSlides chooses the slides that show it (by slide id; the rest keep it turned off, so it comes back without the picture being handed over again) — design.identity.avatarSlides says which slides show it now (numbered from 1). The picture is screened and stored with the deck. Requires the current expectedVersion. Returns the deck with its re-rendered previews.

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": {
      "deckId": "<deckId>",
      "expectedVersion": "<expectedVersion>"
    },
    "name": "antix_set_deck_identity"
  }
}

Input Schema

Name	Required	Description
`avatar`	No	The user's picture as a file from this conversation: one they uploaded, or one you made with your own image generation.
`deckId`	Yes
`handle`	No	The handle printed on every slide, e.g. "@northside", exactly as the user gave it. "" prints none.
`locale`	No
`avatarUrl`	No	A direct link to the user's picture (an image file, not a profile page — profile pages cannot be read). Only a link the user gave.
`projectId`	No	AIGE project whose Canvas should receive the updated deck.
`fromAccount`	No	Use the account the user connected in AIGE: its handle (Instagram and Threads; unless handle is given) and its profile picture (unless avatar or avatarUrl is given).
`avatarSlides`	No	Exactly the slides that show the picture (by slide id); the others keep it, turned off, so it can be turned on again without the picture. Omit to show it on every slide that prints a handle. design.identity.avatarSlides lists the slides showing it now.
`removeAvatar`	No	true takes the picture off every slide.
`accountHandle`	No
`expectedVersion`	Yes	REQUIRED: the deck version you last read. A stale value fails with DECK_CONFLICT before any work.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well past the supplied idempotentHint/destructiveHint annotations: the avatar is drawn round and sized to the handle, persists through later edits, layouts and deck shapes, is screened and stored with the deck, and the call requires expectedVersion and returns the deck with re-rendered previews. The avatarSlides behavior (unlisted slides keep the picture turned off so it needn't be re-uploaded) is a genuinely useful non-obvious trait.

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?

Front-loads the core action and the FREE note, then enumerates parameter behavior in a single dense paragraph with no filler sentences. It is heavy — roughly 200 words in one block, with some phrasing repeated from the schema (e.g. 'exactly as the user gave it') — but nearly every clause carries information.

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?

For an 11-parameter mutation tool with a nested avatar object and no output schema, the description covers the concurrency requirement, the return value, upload/screening behavior and avatar persistence. Gaps remain around projectId, accountHandle and locale, which are left entirely to a mostly undocumented schema.

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?

With 73% schema coverage the bar is moderate, and the description adds real meaning: precedence between handle and fromAccount, the empty-string convention for handle, why a profile URL cannot be used, and how avatarSlides interacts with design.identity.avatarSlides. It stays silent on locale, projectId and accountHandle, which remain undocumented in both places.

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

Purpose4/5

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

Opens with a concrete verb+resource: print the user's handle on every slide of a carousel deck and set their account picture at deck-identity level. The deck-wide scope ('every slide whose layout prints a handle') implicitly separates it from slide-level siblings such as antix_set_slide_picture, but no sibling is named explicitly.

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

Usage Guidelines4/5

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

Gives clear operational guidance: 'Change either part alone,' three mutually exclusive ways to supply the picture (avatar / avatarUrl / fromAccount), 'removeAvatar:true takes the picture away,' and a corrective instruction to ask the user for a picture when only a profile PAGE link exists. Lacks explicit when-not-to-use guidance against adjacent tools like antix_set_deck_shape or antix_attach_deck_image.

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

All AIGE 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?