Skip to main content
Glama
marvtub

Takes for Mac

by marvtub
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

make_image

Generate or change images for a Takes video project using Google or OpenAI: create drafts first, then redraw the chosen draft as a 4K final.

Instructions

Make or change an image straight from Google or OpenAI (much cheaper than a Higgsfield image: never use higgsfield for images). Drafts first, final last: while the user finds the direction, draw with GPT Image (fast, 1536 px at most): flare (GPT Image 2.5 Flare, the default for a new image) or sunburst (GPT Image 2.5 Sunburst, the default for a change or with references). When the user likes a draft, make its final: from= redraws it with Nano Banana 2.1 at 4K, the newest and sharpest, with the draft and its references as the guide and the same prompt (add one only for a change). Never make a final before the user picks. When one model fails the next one draws. Waits about 10-60 s and returns the file, /generated/-vN.png, and the model that drew it; the Assets tab shows both. Change an image: images=[session files] (a thumbnail, a still, 'sketch' with shot=) and say what to change. One image per ask.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromNoThe draft the user picked: make its final (Nano Banana 2.1, 4K, same picture).
nameNoShort file name. Default: the prompt's first words.
shotNoWith images=['sketch']: the shot whose sketch to use.
finalNoDraw the final now with Nano Banana 2.1 at 4K, without a draft. Prefer a draft, then from.
modelNoFor a draft: default flare, or sunburst with images.
formatNoShape, e.g. 16:9, 9:16, 4:5, 1:1. Default 1:1, or the input's shape.
imagesNoSession images to change or use as references (paths, or 'sketch' with shot).
promptNoWhat the image shows, or what to change in the given images. Optional with from.
qualityNoDefault medium.
sessionYesSession as 'Project/folder', an absolute path, or its id (from get_session). An old path still works after a rename or move.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true) by disclosing latency ('waits about 10-60 s'), the returned artifact path ('<session>/generated/<name>-vN.png') plus the model used, and fallback behavior ('When one model fails the next one draws'). This is exactly the extra context annotations cannot carry.

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

Conciseness3/5

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

The opening sentence is front-loaded and useful, and most sentences carry workflow information that cannot be dropped. However, the prose is dense with nested parentheticals ('flare (GPT Image 2.5 Flare, the default for a new image)'), which hurts scannability and makes the reader reconstruct the flow.

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?

For a mutation tool with no output schema, the description covers what is produced (file path, model, Assets tab), timing, fallback, and the full draft/final lifecycle. Nothing an agent needs to call 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 parameters are already documented, but the description adds real workflow meaning: it explains that 'from' redraws a picked draft at 4K with the same prompt, that 'images' takes session files or 'sketch' with shot, and that prompt is optional with from. This is more than restating the schema.

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?

States a specific verb and resource ('Make or change an image') and immediately scopes the source ('straight from Google or OpenAI'), then explicitly names the sibling it must not use ('never use higgsfield for images'). An agent can distinguish this from higgsfield without opening either 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?

Gives an explicit draft-then-final workflow, names the conditions that select each model ('flare... default for a new image', 'sunburst... default for a change'), and states exclusions ('Never make a final before the user picks', 'One image per ask'). Alternatives and when-not rules are both present.

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

Deploy Server

Other Tools