Skip to main content
Glama

Check a Carousel Deck's Readiness

antix_check_deck_readiness
Read-onlyIdempotent

Lint a deck for the problems that make a carousel not worth posting yet: slides still carrying the seeded placeholder copy, headline ink that is nearly invisible on a flat background, a slide whose layout is waiting for a picture — and what the slides show as drawn: copy that does not fit its place, runs too long, overlaps other copy, leaves the slide or is too small to read on a phone, copy that cannot be read on the picture behind it, a typeface the slides cannot be drawn in, a swipe cue on the last slide, an arrow that points back or away from the copy. FREE, read-only, deterministic — it never calls a model and never spends a credit.

Each finding carries level (fix = broken, check = worth a look), the layers it is about and the exact correction, so the loop is: antix_get_deck → antix_check_deck_readiness → antix_edit_deck_slides (set_copy / set_text_style / set_layout / set_fonts / set_colors / set_background) → re-check. Two rounds, then tell the user what is left.

look:true also returns ONE small picture of all the slides, numbered as the findings number them, as an image block. Look at it to judge what cannot be measured — spacing, balance, emphasis, whether the slides read as one deck — and say what you see. It is for you, not for the reply: the deck panel already shows the slides to the user.

This checks structure, not taste. ready:true means nothing measurable is broken — it is not a judgement that the carousel is good, and the user always has the final word. It also mirrors the paid-art placeholder guard: a slide reported placeholder_copy here is a slide antix_generate_deck_slide_images will refuse to illustrate.

Input Schema

NameRequiredDescriptionDefault
lookNoAlso return ONE small picture of all the slides, numbered, to look at: spacing, balance, whether the slides read as one deck. Use it when judging how the deck looks; leave it out for a routine check.
deckIdYesDeck to lint. Get ids from antix_get_deck.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, it discloses that the tool is FREE, read-only, deterministic, never calls a model, and never spends credits. It also explains finding levels (`fix` vs `check`), that `ready:true` is not a taste judgement, and that placeholder findings mirror the paid-art placeholder guard.

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 purpose and workflow are front-loaded, and the dense checklist is relevant to understanding what the linter detects. It is longer than typical, but most sentences carry operational value rather than restating the title.

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

Completeness5/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 explains the finding shape (`level`, `layers`, exact correction), the expected edit loop, the optional image behavior, and the limits of `ready:true`. It is complete enough for an agent to call and interpret the tool correctly.

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 is 3. The description still adds useful meaning for `look:true`: it returns one small numbered image block, the numbering matches findings, and the image is for the agent rather than the user reply because the deck panel already shows the slides.

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 opens with a precise verb and resource: lint a carousel deck for posting blockers. It goes further by enumerating the exact classes of problems detected and clearly separates structural checks from subjective taste.

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 workflow: antix_get_deck → antix_check_deck_readiness → antix_edit_deck_slides → re-check, with a two-round limit and instruction to tell the user what remains. It also states when to use `look:true` versus leaving it out for a routine check.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources