Read-only MCP server for creator/video math, returning sourced platform specs and deterministic local calculations.
Look up a social media placement's frame size, ratio, safe-area insets/usable box, source URL, and optional crop/letterbox fit plan.
List all supported placements or filter by platform for browsing/comparison.
Check whether a caption/logo/button rectangle stays inside a placement's safe area and report pixel intrusion per edge.
Simplify aspect ratios, align dimensions to codec blocks, and compute crop or pad plans for arbitrary target ratios.
Estimate encoded video size, target bitrate for a size cap, and bits-per-pixel density.
Convert subtitles between SRT, WebVTT, and ASS/SSA, with format detection and timing shifts.
Estimate BPM from tap timestamps or compute beat/bar lengths from a known BPM.
It does not inspect files or audio, and returns explicit unknown/null where platforms publish no fixed safe area.
Provides platform frame sizes and sourced safe-area calculations for Instagram Reels, including pixel insets and source URLs for the published guidelines.
Provides platform frame specifications and safe-area behavior for TikTok video, explicitly reporting when no fixed safe area is published rather than inventing one.
This server has a remotely hosted endpoint. Open its connector listing for connection details, authentication requirements, and setup instructions:
Zero-dependency TypeScript utilities for video and social creators: aspect-ratio maths, tap tempo, subtitle parsing and conversion, platform frame sizes with sourced safe areas, encoding calculators, colour-palette extraction, GIF encoding, image metadata, and C2PA / AI-provenance detection.
No runtime dependencies. No network calls. Works in the browser, in Node, and in a worker. Every number it returns is one you could check by hand — and where a platform doesn't publish a number, it says so instead of inventing one.
npm install @prismposter/creator-toolsMost of these calculations are scattered across blog posts that quote each other,
and a surprising number of the quoted figures are wrong. The one that started
this library: every "TikTok safe area" pixel table on the open web is invented.
TikTok publishes an overlay template, not a fixed inset — the occluded zone
varies with frame dimensions, caption length, and which ad formats are running.
There is no correct constant, so this library returns null for it and explains
why, rather than shipping a plausible-looking number.
That's the rule the whole package follows:
Derived numbers are derived. A 9:16 frame at 1080 wide is 1920 tall because
that's what the ratio says. Every size in social-sizes is asserted against its
own declared ratio by the test suite.
Quoted numbers name their source. Every safe area links the first-party page
it was read from. safeAreaSourceUrl(placement) returns that URL.
Unknown is a value, not a blank. A platform that publishes nothing gets an
explicit kind: 'unpublished' with the reason attached.
Related MCP server: media-engine
aspect-ratioRatio arithmetic for frames about to be encoded. Handles non-integral cinema ratios (2.39:1) the same way it handles 16:9.
import {
simplifyRatio, cropToRatio, padToRatio, alignToBlock,
} from '@prismposter/creator-tools/aspect-ratio';
simplifyRatio({ width: 1920, height: 1080 }); // { w: 16, h: 9 }
cropToRatio({ width: 1920, height: 1080 }, { w: 9, h: 16 });
// { result: { width: 608, height: 1080 },
// removed: { top: 0, right: 656, bottom: 0, left: 656 },
// areaKept: 0.3167 }
// Codecs want even dimensions; H.264 chroma subsampling makes an odd
// width an encoder error or a silent rescale.
alignToBlock({ width: 1081, height: 607 }); // { width: 1082, height: 608 }
alignToBlock({ width: 1080, height: 1920 }, 16); // { width: 1088, height: 1920 }An odd crop remainder always goes to the bottom/right edge. That's arbitrary, but it's consistent — splitting it differently per call is how a batch of clips ends up a pixel out of register with each other.
social-sizesPlatform frames and safe areas, with sources.
import {
getPlacement, frameSize, safeAreaPx, safeAreaBox, safeAreaSourceUrl,
} from '@prismposter/creator-tools/social-sizes';
const reels = getPlacement('instagram-reels')!;
frameSize(reels); // { width: 1080, height: 1920 }
safeAreaPx(reels); // { top: 269, bottom: 672, left: 65, right: 65 }
safeAreaBox(reels); // { width: 950, height: 979 }
safeAreaSourceUrl(reels); // Meta's Reels ads-guide page
const tiktok = getPlacement('tiktok-video')!;
safeAreaPx(tiktok); // null — and that is the correct answer
tiktok.safeArea.reason; // explains why no fixed table can be rightMeta publishes Reels and Stories as 14% top, 35% bottom, 6% each side. On a 1080×1920 frame that's 269 / 672 / 65 px. The bottom third is not a typo.
safeAreaPx returning null is meaningful — surface it to your user as "this
platform publishes no fixed safe area". Don't substitute zeros, and don't borrow
another platform's numbers.
subtitlesSRT, WebVTT, and ASS/SSA parsing, conversion, and timing edits. Everything routes
through one neutral Cue shape rather than converting format-to-format: six
formats would otherwise need thirty converters, each a place a rounding rule can
quietly differ.
import { convert, parse, shift, scale, deoverlap }
from '@prismposter/creator-tools/subtitles';
const { output, warnings } = convert(srtText, 'vtt');
// Fix subtitles authored against a different frame rate.
scale(parse(srtText).cues, 23.976 / 25);
// Nudge everything 500ms later; cues pushed before zero clamp to zero.
shift(cues, 500);
// Clip overlaps so only one cue is ever on screen.
deoverlap(cues);Parsing is tolerant: a malformed block produces a warning and is skipped, rather
than costing you the other 899 cues in the file. UTF-8 BOMs and CRLF endings are
handled. VTT NOTE/STYLE blocks and inline tags (<v Roger>, <i>) are
stripped; ASS override blocks ({\an8}) are too.
ASS stores centiseconds, so an ASS round-trip is lossy below 10 ms. convert()
tells you so in warnings rather than letting you discover it later.
tempoTap tempo and the beat arithmetic an edit timeline needs.
import { estimateTempo, beatMs, noteMs, beatGrid, snapToBeat }
from '@prismposter/creator-tools/tempo';
estimateTempo(tapTimestamps);
// { bpm: 128.02, taps: 16, spreadMs: 8.4, discarded: 1 }
beatMs(120); // 500
noteMs(120, 'quarter', { triplet: true }); // 333.333
beatGrid(120, 10_000); // [0, 500, 1000, … 10000]
snapToBeat(480, 120); // { timeMs: 500, deltaMs: 20 }The estimator takes the median of a trailing window, not the mean. A tap sequence has two failure modes a mean handles badly: the first taps run late while the user finds the beat, and one missed tap creates an interval at roughly double the true period. Outliers are discarded against the median, because a mean would already have been dragged far enough to keep the bad interval inside tolerance.
spreadMs tells you how much to trust the result — under ~20 ms is a steady
tapper, over ~60 ms means the estimate is soft. beatGrid computes each position
from its index rather than accumulating, so a long sequence cannot drift.
encodingFile size, bitrate, timecode, and frame counts.
import { fileSizeBytes, targetBitrateKbps, bitsPerPixel, toDropFrame }
from '@prismposter/creator-tools/encoding';
fileSizeBytes(60, 8_000); // 60_000_000 bytes
targetBitrateKbps(120, 50_000_000); // kbps to hit a 50 MB cap
bitsPerPixel(1920, 1080, 30, 8_000); // 0.1286
toDropFrame(1_800, 29.97); // '00:01:00;02'Unit convention, stated once: bitrates are decimal (1 Mbps = 1,000,000
bits/s, as every encoder and platform spec means it) and file sizes are binary
(1 MiB = 1,048,576 bytes, as every OS reports it). Mixing the two is why online
calculators disagree by about 5%. formatBytesBinary and formatBytesDecimal
are separate functions so the choice is always explicit.
Drop-frame timecode skips labels, never frames: numbers 00 and 01 are omitted at the start of each minute except every tenth. That's what keeps 29.97 timecode matching wall clock, which non-drop drifts from by ~3.6 s per hour.
paletteMedian-cut colour quantisation, plus the contrast maths for putting text on what it returns.
import { extractPalette, toHex, readableTextOn } from '@prismposter/creator-tools/palette';
const swatches = extractPalette(pixels, 5); // pixels: { r, g, b }[]
swatches.map(toHex); // ['#1b2430', '#3f6d8e', ...]
readableTextOn(swatches[0]); // { onColour: 'black' | 'white', ratio: 8.7 }The box split is chosen at the widest gap along the dominant axis, not at the median pixel count. The textbook median split gives every box the same number of pixels, which is exactly wrong for a photograph: a large flat sky gets subdivided repeatedly while a small saturated accent -- the one colour a designer actually wants -- is averaged into its neighbour and disappears. Splitting at the gap keeps it.
When the source has fewer distinct colours than requested slots you get fewer swatches. Padding the result with near-duplicates would be a palette that lies about the image.
provenanceIs there provenance on this file, and does it say the asset was AI-generated?
import { inspectProvenance } from '@prismposter/creator-tools/provenance';
inspectProvenance(bytes);
// { hasC2paManifest: true, hasIptcSourceType: true, hasProvenance: true,
// declaresAiGenerated: true, declaresCapture: false,
// digitalSourceTypes: ['.../digitalsourcetype/trainedAlgorithmicMedia'],
// assertionLabels: ['c2pa.actions.v2', 'c2pa.claim.v2'],
// manifestOffset: 41, signatureVerified: false }Two markings are in circulation and they are constantly confused:
A C2PA manifest -- a cryptographically signed Content Credential in a JUMBF box.
An IPTC digital source type -- a plain XMP/EXIF string with no signature
at all, which anyone can write with exiftool.
A file can carry either, both, or neither. They are reported separately because they carry entirely different weight, and a great many "AI detector" write-ups treat the second as though it were the first.
It does not verify the signature. signatureVerified is always false,
deliberately. Proving a manifest is valid needs the full C2PA trust list and
certificate-chain validation -- that is what
c2patool and c2pa-node are for, and
you should use them when trust is the question. This answers the cheaper question
those are overkill for, and which is often impossible in a serverless runtime that
cannot ship a native binary: is a credential present, and what does it claim?
That is the check you want when triaging an upload queue and routing only the
interesting files on to a real verifier.
A present manifest is not a trusted manifest. Anyone can sign anything with a self-signed certificate, including a lie.
image-metadataRead what a file says about itself -- and, more usefully, notice when it says nothing.
import { readImageMetadata, isStripped } from '@prismposter/creator-tools/image-metadata';
const meta = readImageMetadata(bytes);
meta.format; // 'jpeg' | 'png' | 'webp' | 'gif' | ...
meta.fields; // parsed EXIF / XMP / text fields
isStripped(meta);Most platforms strip metadata on upload, so an image with none is the normal case
rather than a suspicious one. isStripped exists so you can tell a user that
instead of showing them an empty table.
gifAn animated GIF encoder: global palette, LZW, sub-blocks, the lot.
import { encodeGif, buildGlobalPalette, indexFrame } from '@prismposter/creator-tools/gif';
const palette = buildGlobalPalette(frames, 256);
const bytes = encodeGif({ width, height, palette, frames });GIF allows 256 colours and one global palette across every frame, so the
quantiser matters more than the encoder does -- which is why it shares
palette's median cut rather than carrying its own.
mcp (Model Context Protocol Server)@prismposter/creator-tools ships a zero-dependency MCP stdio server so AI
assistants (Claude Desktop, Cursor, Windsurf, Cline) can query verified
platform safe areas, aspect-ratio crops, bitrates, and subtitle conversions
without hallucinating pixel dimensions.
Add to claude_desktop_config.json or .cursor/mcp.json:
{
"mcpServers": {
"prismposter-creator-tools": {
"command": "npx",
"args": ["-y", "@prismposter/creator-tools"]
}
}
}Exposed MCP tools (all read-only, pure local calculations with an output schema):
get_social_media_placement — one placement's frame size, safe-area insets in pixels, usable box and first-party documentation URL (instagram-reels, youtube-shorts, tiktok-video, etc.), plus a crop / letterbox plan for your source size
list_social_media_placements — every placement, or one platform's, for browsing and comparison
check_safe_area — whether a caption, logo or button box stays inside a placement's safe area, and by how many pixels it intrudes past each edge; TikTok answers unknown with the reason
calculate_aspect_ratio — simplify any ratio, align to codec blocks, and compute centre-crop / letterbox plans for an arbitrary target ratio
estimate_video_bitrate — encoded file size (bytes, MiB, MB), the bitrate that fits a size cap, and bits-per-pixel density
convert_subtitles — convert between SRT, WebVTT and ASS/SSA with format detection and a timing shift
estimate_tempo — BPM from tap timestamps, or beat and bar lengths for a known BPM
A bad call returns an MCP tool error (isError: true) whose message says how to fix it,
for example the valid placement ids for an unknown one.
A hosted version runs at https://www.prismposter.com/api/mcp (Streamable HTTP, no install).
It answers from prismposter.com's larger placement dataset (which also accepts the camelCase ids
used on the site), takes videoKbps and targetCapMb in its bitrate tool, converts SRT and
WebVTT only, and adds a get_prismposter_capabilities tool.
Both are listed in the official MCP Registry as com.prismposter/creator-tools.
Pure functions, no side effects, no I/O. Everything is synchronous and deterministic.
Invalid input returns null, it does not throw. These functions sit behind
text inputs where a half-typed value is normal, not exceptional.
Rounding happens once, at the boundary. Sizes are whole pixels because that's what an encoder takes.
null means "no answer exists", and is always distinguishable from zero.
A wrong type still throws. Rule 2 is about values a user could type. It is not a licence to guess what a caller meant by handing a string to a function that reads bytes.
npm install
npm test # 173 tests
npm run typecheck
npm run buildContributions welcome — see CONTRIBUTING.md. The bar for a new constant is a first-party source; the bar for a new function is a test that would fail without it.
Every module here backs a free tool at prismposter.com/tools -- no account, no upload, no email. If you want the answer rather than the function, start there:
PrismPoster is an AI content workspace -- image, video, remake, character and music studios that share one project, one asset library, and one timeline you can actually finish in.
This library is the boring half of that product: the arithmetic underneath the
studios, extracted because it is genuinely reusable and because a subtitle parser
is not a competitive advantage. provenance exists for the same reason in
reverse -- building AI disclosure into a media product meant learning where the
C2PA tooling is thin, and a dependency-free presence check was the piece that
kept being missing.
MIT © PrismLabs OÜ
Reduce any pixel size to its simplest aspect ratio (1920x1080 is 16:9), round it up to an even or codec-block multiple, and, given a target ratio, return the centre-crop and letterbox/pillarbox plans with the px removed or added per edge. Use this for arbitrary sizes and ratios (cinema 2.39:1, a client's 4:5); when the target is a named platform placement, use get_social_media_placement with sourceWidth/sourceHeight instead, which picks the right ratio for you. Errors on a non-integer or out-of-range size, or on only one of targetRatioW/targetRatioH.
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Frame width in px. | |
| height | Yes | Frame height in px. | |
| blockSize | No | Round dimensions up to a multiple of this: 2 for H.264 4:2:0, 16 for macroblock-aligned. Default 2. | |
| targetRatioH | No | Height term of the target ratio, e.g. 16 for 9:16. Requires targetRatioW. | |
| targetRatioW | No | Width term of the ratio to crop or pad to, e.g. 9 for 9:16 or 2.39 for 2.39:1. Requires targetRatioH. |
| Name | Required | Description |
|---|---|---|
| input | Yes | |
| ratio | Yes | |
| padPlan | Yes | |
| cropPlan | Yes | |
| blockSize | Yes | |
| targetRatio | Yes | |
| alignedToBlock | Yes | |
| formattedRatio | Yes | |
| referenceToolUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real context beyond that: what is returned (crop plan plus letterbox/pillarbox with px removed or added per edge) and what triggers errors (non-integer/out-of-range size, or only one of targetRatioW/targetRatioH).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the primary operation and only three sentences total; the usage/alternative routing is placed after the capability statement. The first sentence is dense with chained clauses but every clause carries information the agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return structure needn't be spelled out, yet the description still summarizes what comes back (crop and letterbox plans, px per edge). Combined with the error conditions and sibling routing, nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description adds meaning on top: the blockSize concept is framed as 'even or codec-block multiple' tied to the ratio workflow, and it clarifies that the ratio pair must be supplied together. It still doesn't explain what units or defaults apply to the returned plan values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific operations (simplify to aspect ratio, round to block multiple, compute centre-crop/letterbox plans) on a specific resource (pixel dimensions). It explicitly contrasts itself with the sibling get_social_media_placement, so an agent can pick between them 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use case (arbitrary sizes and ratios like 2.39:1 or 4:5) and an explicit alternative plus condition (named platform placement → get_social_media_placement with sourceWidth/sourceHeight). It also names the failure conditions, which further bounds correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a rectangle (a caption, logo or button, in px on the placement's own frame, origin top-left) stays inside the placement's published safe area, and by how many px it intrudes past each edge if not. Use this to validate a layout before export; use get_social_media_placement for the raw insets. Returns verdict "inside", "intrudes" or "unknown"; "unknown" means the platform publishes no fixed safe area (TikTok) and comes with the reason instead of a guess. Errors on an unknown placement id or a box with non-positive size.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | Element's left edge in px from the frame's left edge. | |
| y | Yes | Element's top edge in px from the frame's top edge. | |
| width | Yes | Element width in px. | |
| height | Yes | Element height in px. | |
| placementId | Yes | Placement id, e.g. instagram-reels. |
| Name | Required | Description |
|---|---|---|
| box | Yes | |
| frame | Yes | |
| verdict | Yes | |
| safeRectPx | Yes | |
| intrusionPx | Yes | |
| placementId | Yes | |
| withinFrame | Yes | |
| safeAreaKind | Yes | |
| referenceToolUrl | Yes | |
| unpublishedReason | Yes | |
| firstPartySourceUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes further: it enumerates the three verdict values, explains that 'unknown' means the platform publishes no fixed safe area (TikTok) and returns a reason instead of a guess, and states the two error conditions (unknown placement id, non-positive box size). This is behavior an agent cannot infer from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the core check and its result, followed by the routing hint and edge-case behavior. Every clause — units, verdict values, the TikTok fallback, error cases — carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present the description needn't explain return shapes, yet it already summarizes the verdict values. Combined with the stated error conditions and coordinate frame, an agent has everything needed to call this correctly against any of the fourteen placements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already documents each of the five parameters with units and the enum list, so the description only echoes the coordinate framing ('in px on the placement's own frame, origin top-left') and the positive-size requirement already encoded as minimum:1. Baseline 3 is appropriate; no new per-parameter syntax or defaults are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: check whether a rectangle stays inside a placement's published safe area, with units and coordinate frame spelled out. It is immediately distinguishable from sibling get_social_media_placement, which it names as returning raw insets rather than a verdict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('validate a layout before export') and names the alternative with its different purpose ('use get_social_media_placement for the raw insets'). The routing decision is fully determined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert subtitle text between SRT, WebVTT and ASS/SSA, optionally shifting every cue by shiftMs, and return the converted text with the cue count and any warnings. Pass the file contents, not a path. The input format is detected from the content unless fromFormat is given. Malformed blocks are skipped with a warning instead of failing the whole file; converting to ASS rounds timings to 10 ms. Errors when the format cannot be detected or no cue could be parsed.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The full subtitle file contents as text. | |
| shiftMs | No | Move every cue by this many ms: positive is later, negative earlier. Cues pushed before 0 clamp to 0. | |
| toFormat | Yes | Format to convert to. | |
| fromFormat | No | Format of the input. Omit to detect it from the content. |
| Name | Required | Description |
|---|---|---|
| output | Yes | |
| shiftMs | Yes | |
| cueCount | Yes | |
| toFormat | Yes | |
| warnings | Yes | |
| fromFormat | Yes | |
| referenceToolUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only cover read-only/idempotent safety), it discloses real behavioral traits: malformed blocks are skipped with a warning rather than failing the file, ASS output rounds timings to 10 ms, cues shifted before 0 clamp to 0, and it errors when detection fails or no cue parses. These are exactly the failure-mode details an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each carrying distinct payload: purpose, invocation rule, format detection, and error/degradation behavior. The most important constraint (contents not path) appears early rather than buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, it summarizes the return (converted text, cue count, warnings) and enumerates the error conditions, plus the lossy-format caveat for ASS. For a pure-function conversion tool this leaves nothing an agent must infer to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 value by clarifying that `input` is file contents not a path and that `fromFormat` is an override for auto-detection. It restates shiftMs's clamping behavior already in the schema, hence not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (convert) and resource (subtitle text) with an explicit set of formats: SRT, WebVTT, ASS/SSA. No sibling tool overlaps with subtitle conversion, so the scope is unambiguous from the first clause.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the key invocation constraint up front: "Pass the file contents, not a path," and explains that input format is auto-detected unless fromFormat is supplied. It doesn't name alternatives, but no sibling tool is a plausible substitute, so the missing exclusion costs little.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tempo arithmetic for editing to music: pass tap timestamps (ms) to estimate BPM, with a spread figure that shows how steady the taps were, or pass a known bpm to get the beat and 4/4 bar length in ms for cutting on the beat. It works on numbers you supply and does not analyse audio. Taps more than 2.5 s apart restart the count, and outlier intervals (a missed or doubled tap) are discarded. Errors when neither input is given, fewer than two usable taps remain, or bpm is outside 20-400.
| Name | Required | Description | Default |
|---|---|---|---|
| bpm | No | Known tempo in beats per minute. Used instead of the estimate when both are given. | |
| timestampsMs | No | Tap times in ms from a monotonic clock (performance.now()), in order. |
| Name | Required | Description |
|---|---|---|
| bpm | Yes | |
| barMs4_4 | Yes | |
| estimate | Yes | |
| quarterNoteMs | Yes | |
| referenceToolUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral detail beyond them: a 2.5 s gap restarts the tap count, outlier intervals from missed or doubled taps are discarded, and the exact error conditions (no input, fewer than two usable taps, bpm outside 20-400). The 'spread figure' also discloses what the estimate reports about tap steadiness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the tool's purpose and the two usage modes, then the edge-case rules, then errors. Every clause carries information an agent would otherwise have to guess at.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be enumerated, yet the description still tells the agent what the outputs mean (spread = tap steadiness, bar length for cutting on the beat). Combined with the disclosed restart rule and error cases, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 earns above that by explaining what each mode yields (BPM plus spread vs. beat and bar length in ms) rather than just restating the field names. It leaves the precise formula and spread units implicit, which keeps it just short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Tempo arithmetic') and immediately distinguishes its two input modes: tap timestamps to BPM, or a known bpm to beat/4-4 bar length in ms. This is clearly differentiated from every sibling (aspect ratios, bitrate, safe area, subtitles), none of which overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says which input to pass for which outcome and notes that it works on supplied numbers rather than audio, which heads off a plausible misuse. It does not name an alternative tool, but no sibling is a real substitute, so the omission is minor rather than a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Video size and bitrate arithmetic for a clip of durationSec. Pass totalKbps to get the encoded file size (bytes, binary MiB and decimal MB); pass targetBytes to get the highest total bitrate that fits that size; add widthPx, heightPx and fps (with totalKbps) to get bits per pixel, a codec-independent check of whether the bitrate suits the resolution. Kbps is decimal (1 kbps = 1000 bit/s) and covers video plus audio. Use it to plan an export or hit an upload cap; it does not inspect or encode files. Errors when neither totalKbps nor targetBytes is given, or when only some of the bits-per-pixel inputs are.
| Name | Required | Description | Default |
|---|---|---|---|
| fps | No | Frame rate, for bits per pixel. | |
| widthPx | No | Frame width in px, for bits per pixel. | |
| heightPx | No | Frame height in px, for bits per pixel. | |
| totalKbps | No | Combined video + audio bitrate in kbps. Needed for file size and bits per pixel. | |
| durationSec | Yes | Clip length in seconds. | |
| targetBytes | No | File-size cap in bytes (25 MB = 25000000) to solve for the maximum total kbps. |
| Name | Required | Description |
|---|---|---|
| totalKbps | Yes | |
| durationSec | Yes | |
| targetBytes | Yes | |
| bitsPerPixel | Yes | |
| estimatedBytes | Yes | |
| formattedBinary | Yes | |
| formattedDecimal | Yes | |
| referenceToolUrl | Yes | |
| targetBitrateKbps | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, and the description adds substantial behavioral context beyond them. It documents unit conventions ('kbps is decimal, covers video plus audio') and specific error conditions when inputs are missing or incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then efficiently covers each mode, units, use cases, exclusions, and errors. Every sentence adds actionable information for selecting and invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema, the description does not need to explain return values, and it fully covers inputs, modes, units, and failure conditions. Nothing an agent needs in order to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds relational meaning the schema alone does not: totalKbps drives file size, targetBytes solves for bitrate, and width/height/fps plus totalKbps enable the bits-per-pixel check. It also clarifies the error case when only some bits-per-pixel inputs are supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('video size and bitrate arithmetic') and identifies the required input ('durationSec'). It clearly distinguishes the tool from file-inspection or encoding tools by saying 'it does not inspect or encode files.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly explains the three usage modes: pass totalKbps for encoded file size, pass targetBytes for maximum bitrate under a cap, and add width/height/fps with totalKbps for bits-per-pixel. It also names concrete use cases ('plan an export or hit an upload cap') and an exclusion ('does not inspect or encode files').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one social media placement by id and return its frame size, aspect ratio, first-party safe-area insets in px, usable box, and the official page the figures came from. Pass sourceWidth and sourceHeight together to also get the centre-crop and letterbox plan that fits your footage to this placement. Use this when you know the target placement; use list_social_media_placements to browse or compare placements, check_safe_area to test whether an element is clear of the platform UI, and calculate_aspect_ratio for a ratio that is not a platform placement. For TikTok the insets are null with a reason, because TikTok publishes no fixed safe area. Errors on an unknown id (the message lists valid ids) or on only one source dimension.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Placement id, e.g. instagram-reels, tiktok-video or youtube-shorts. | |
| sourceWidth | No | Width of your source footage in px. Requires sourceHeight. | |
| sourceHeight | No | Height of your source footage in px. Requires sourceWidth. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| fit | Yes | |
| kind | Yes | |
| size | Yes | |
| label | Yes | |
| ratio | Yes | |
| platform | Yes | |
| usableBoxPx | Yes | |
| safeAreaKind | Yes | |
| usableSharePct | Yes | |
| referenceToolUrl | Yes | |
| safeAreaInsetsPx | Yes | |
| unpublishedReason | Yes | |
| firstPartySourceUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses that TikTok insets are null with a stated reason, and that the tool errors on unknown ids (listing valid ids) and on a partial source-dimension pair. Those are non-obvious failure modes an agent needs to plan for.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with purpose and return content, followed by the optional-crop affordance, sibling routing, and edge cases. Every sentence carries information that changes agent behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering the safety profile and an output schema covering return shape, the description supplies the remaining essentials: what the fields mean, the optional crop-plan mode, routing to siblings, and the two error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the enum ids and px bounds are already documented. The description still adds value by explaining what passing both sourceWidth and sourceHeight unlocks (centre-crop and letterbox plan) rather than just restating the dependency, though it does not clarify units/limits beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('look up one social media placement by id') and enumerates exactly what is returned: frame size, aspect ratio, safe-area insets, usable box, and provenance page. It is immediately distinguishable from list_social_media_placements or check_safe_area.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when you know the target placement' and then routes three named alternatives (list_social_media_placements for browsing/comparison, check_safe_area for element clearance, calculate_aspect_ratio for non-platform ratios) to their triggering conditions. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every supported social media placement (or one platform's) with frame size, aspect ratio, safe-area insets in px, usable box and first-party source URL, in one response. Use this to browse, compare platforms, or find a placement id; use get_social_media_placement when you already know the id and also need a crop/letterbox plan for your footage. The list is a fixed built-in dataset returned whole, with no paging.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Only return placements for this platform. Omit for all platforms. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| platform | Yes | |
| placements | Yes | |
| canonicalDatasetUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: a fixed built-in dataset returned whole with no paging, which tells the agent not to loop for pages and not to expect live data. It stops short of stating ordering or per-platform completeness guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero filler. The returned-field inventory and the no-paging guarantee are front-loaded, and the sibling routing clause lands last where it is most actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail need not be spelled out, and the description still summarizes the shape. For a single optional-filter list tool over a static dataset, nothing an agent needs in order 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single enum parameter is fully documented as 'Only return placements for this platform. Omit for all platforms.' The description only gestures at it with '(or one platform's)', adding no syntax or default nuance beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (list social media placements) and enumerates the payload an agent gets back: frame size, aspect ratio, safe-area insets, usable box, and source URL. It also names the sibling it is not (get_social_media_placement), so the tool is distinguishable without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use cases (browse, compare platforms, find a placement id) and an explicit when-not plus the alternative: use get_social_media_placement when you already know the id and need a crop/letterbox plan. The routing decision is fully determined by the text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0calculate_aspect_ratio18 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / blockSize / defaultAdded value: +2Input schema / properties / blockSize / descriptionPrevious value: -"Optional codec block alignment (default 2)."New value: +"Round dimensions up to a multiple of this: 2 for H.264 4:2:0, 16 for macroblock-aligned. Default 2."Input schema / properties / blockSize / minimumAdded value: +1Input schema / properties / blockSize / typePrevious value: -"number"New value: +"integer"Input schema / properties / height / descriptionPrevious value: -"Frame height in pixels."New value: +"Frame height in px."Input schema / properties / height / maximumAdded value: +100000Input schema / properties / height / minimumAdded value: +1Input schema / properties / height / typePrevious value: -"number"New value: +"integer"Input schema / properties / targetRatioH / descriptionPrevious value: -"Optional target aspect ratio height term (e.g. 16)."New value: +"Height term of the target ratio, e.g. 16 for 9:16. Requires targetRatioW."Input schema / properties / targetRatioH / exclusiveMinimumAdded value: +0Input schema / properties / targetRatioW / descriptionPrevious value: -"Optional target aspect ratio width term (e.g. 9)."New value: +"Width term of the ratio to crop or pad to, e.g. 9 for 9:16 or 2.39 for 2.39:1. Requires targetRatioH."Input schema / properties / targetRatioW / exclusiveMinimumAdded value: +0Input schema / properties / width / descriptionPrevious value: -"Frame width in pixels."New value: +"Frame width in px."Input schema / properties / width / maximumAdded value: +100000Input schema / properties / width / minimumAdded value: +1Input schema / properties / width / typePrevious value: -"number"New value: +"integer"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "alignedToBlock": {
+ "anyOf": [
+ {
+ "properties": {
+ "height": {
+ "type": "integer"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "blockSize": {
+ "type": "integer"
+ },
+ "cropPlan": {
+ "anyOf": [
+ {
+ "properties": {
+ "areaKept": {
+ "type": "number"
+ },
+ "removed": {
+ "properties": {
+ "bottom": {
+ "type": "integer"
+ },
+ "left": {
+ "type": "integer"
+ },
+ "right": {
+ "type": "integer"
+ },
+ "top": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "top",
+ "right",
+ "bottom",
+ "left"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "properties": {
+ "height": {
+ "type": "integer"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "result",
+ "removed",
+ "areaKept"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "formattedRatio": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "input": {
+ "properties": {
+ "height": {
+ "type": "integer"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ },
+ "padPlan": {
+ "anyOf": [
+ {
+ "properties": {
+ "added": {
+ "properties": {
+ "bottom": {
+ "type": "integer"
+ },
+ "left": {
+ "type": "integer"
+ },
+ "right": {
+ "type": "integer"
+ },
+ "top": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "top",
+ "right",
+ "bottom",
+ "left"
+ ],
+ "type": "object"
+ },
+ "imageFraction": {
+ "type": "number"
+ },
+ "result": {
+ "properties": {
+ "height": {
+ "type": "integer"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "result",
+ "added",
+ "imageFraction"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "ratio": {
+ "anyOf": [
+ {
+ "properties": {
+ "h": {
+ "type": "number"
+ },
+ "w": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "w",
+ "h"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "referenceToolUrl": {
+ "type": "string"
+ },
+ "targetRatio": {
+ "anyOf": [
+ {
+ "properties": {
+ "h": {
+ "type": "number"
+ },
+ "w": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "w",
+ "h"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "input",
+ "ratio",
+ "formattedRatio",
+ "blockSize",
+ "alignedToBlock",
+ "targetRatio",
+ "cropPlan",
+ "padPlan",
+ "referenceToolUrl"
+ ],
+ "type": "object"
+}check_safe_areaconvert_subtitles8 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / fromFormatAdded value: +{
+ "description": "Format of the input. Omit to detect it from the content.",
+ "enum": [
+ "srt",
+ "vtt",
+ "ass"
+ ],
+ "type": "string"
+}Input schema / properties / input / descriptionPrevious value: -"Raw subtitle file content (SRT, VTT, or ASS)."New value: +"The full subtitle file contents as text."Input schema / properties / input / minLengthAdded value: +1Input schema / properties / shiftMs / descriptionPrevious value: -"Optional timing offset in milliseconds (positive delays, negative advances)."New value: +"Move every cue by this many ms: positive is later, negative earlier. Cues pushed before 0 clamp to 0."Input schema / properties / shiftMs / typePrevious value: -"number"New value: +"integer"Input schema / properties / toFormat / descriptionPrevious value: -"Target subtitle format."New value: +"Format to convert to."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "cueCount": {
+ "type": "integer"
+ },
+ "fromFormat": {
+ "enum": [
+ "srt",
+ "vtt",
+ "ass"
+ ],
+ "type": "string"
+ },
+ "output": {
+ "type": "string"
+ },
+ "referenceToolUrl": {
+ "type": "string"
+ },
+ "shiftMs": {
+ "type": "integer"
+ },
+ "toFormat": {
+ "enum": [
+ "srt",
+ "vtt",
+ "ass"
+ ],
+ "type": "string"
+ },
+ "warnings": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "fromFormat",
+ "toFormat",
+ "cueCount",
+ "shiftMs",
+ "warnings",
+ "output",
+ "referenceToolUrl"
+ ],
+ "type": "object"
+}estimate_tempo7 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / bpm / descriptionPrevious value: -"Optional known BPM to calculate quarter-note beat duration in ms."New value: +"Known tempo in beats per minute. Used instead of the estimate when both are given."Input schema / properties / bpm / maximumAdded value: +400Input schema / properties / bpm / minimumAdded value: +20Input schema / properties / timestampsMs / descriptionPrevious value: -"Optional list of monotonic tap timestamps in milliseconds."New value: +"Tap times in ms from a monotonic clock (performance.now()), in order."Input schema / properties / timestampsMs / minItemsAdded value: +2Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "barMs4_4": {
+ "type": "number"
+ },
+ "bpm": {
+ "type": "number"
+ },
+ "estimate": {
+ "anyOf": [
+ {
+ "properties": {
+ "bpm": {
+ "type": "number"
+ },
+ "discarded": {
+ "type": "integer"
+ },
+ "spreadMs": {
+ "type": "number"
+ },
+ "taps": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "bpm",
+ "taps",
+ "spreadMs",
+ "discarded"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "quarterNoteMs": {
+ "type": "number"
+ },
+ "referenceToolUrl": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "estimate",
+ "bpm",
+ "quarterNoteMs",
+ "barMs4_4",
+ "referenceToolUrl"
+ ],
+ "type": "object"
+}estimate_video_bitrate16 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / durationSec / descriptionPrevious value: -"Clip duration in seconds."New value: +"Clip length in seconds."Input schema / properties / durationSec / exclusiveMinimumAdded value: +0Input schema / properties / fps / descriptionPrevious value: -"Optional frame rate for bits-per-pixel."New value: +"Frame rate, for bits per pixel."Input schema / properties / fps / exclusiveMinimumAdded value: +0Input schema / properties / heightPx / descriptionPrevious value: -"Optional frame height in pixels for bits-per-pixel."New value: +"Frame height in px, for bits per pixel."Input schema / properties / heightPx / minimumAdded value: +1Input schema / properties / heightPx / typePrevious value: -"number"New value: +"integer"Input schema / properties / targetBytes / descriptionPrevious value: -"Optional file-size cap in bytes to compute max kbps."New value: +"File-size cap in bytes (25 MB = 25000000) to solve for the maximum total kbps."Input schema / properties / targetBytes / exclusiveMinimumAdded value: +0Input schema / properties / totalKbps / descriptionPrevious value: -"Total bitrate (video + audio) in kbps (decimal)."New value: +"Combined video + audio bitrate in kbps. Needed for file size and bits per pixel."Input schema / properties / totalKbps / exclusiveMinimumAdded value: +0Input schema / properties / widthPx / descriptionPrevious value: -"Optional frame width in pixels for bits-per-pixel."New value: +"Frame width in px, for bits per pixel."Input schema / properties / widthPx / minimumAdded value: +1Input schema / properties / widthPx / typePrevious value: -"number"New value: +"integer"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "bitsPerPixel": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "durationSec": {
+ "type": "number"
+ },
+ "estimatedBytes": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "formattedBinary": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "formattedDecimal": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "referenceToolUrl": {
+ "type": "string"
+ },
+ "targetBitrateKbps": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "targetBytes": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "totalKbps": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "durationSec",
+ "totalKbps",
+ "estimatedBytes",
+ "formattedBinary",
+ "formattedDecimal",
+ "targetBytes",
+ "targetBitrateKbps",
+ "bitsPerPixel",
+ "referenceToolUrl"
+ ],
+ "type": "object"
+}get_social_media_placement12 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / id / descriptionPrevious value: -"Placement ID (e.g. instagram-reels, instagram-story, instagram-feed-portrait, tiktok-video, youtube-shorts, youtube-video, youtube-channel-banner, linkedin-video, x-video, facebook-reels)."New value: +"Placement id, e.g. instagram-reels, tiktok-video or youtube-shorts."Input schema / properties / id / enumAdded value: +[
+ "instagram-reels",
+ "instagram-story",
+ "instagram-feed-portrait",
+ "instagram-feed-square",
+ "tiktok-video",
+ "youtube-shorts",
+ "youtube-video",
+ "youtube-channel-banner",
+ "facebook-reels",
+ "facebook-feed",
+ "linkedin-feed",
+ "linkedin-video",
+ "x-feed-image",
+ "x-video"
+]Input schema / properties / sourceHeight / descriptionPrevious value: -"Optional source frame height in pixels to calculate crop/pad fit."New value: +"Height of your source footage in px. Requires sourceWidth."Input schema / properties / sourceHeight / maximumAdded value: +100000Input schema / properties / sourceHeight / minimumAdded value: +1Input schema / properties / sourceHeight / typePrevious value: -"number"New value: +"integer"Input schema / properties / sourceWidth / descriptionPrevious value: -"Optional source frame width in pixels to calculate crop/pad fit."New value: +"Width of your source footage in px. Requires sourceHeight."Input schema / properties / sourceWidth / maximumAdded value: +100000Input schema / properties / sourceWidth / minimumAdded value: +1Input schema / properties / sourceWidth / typePrevious value: -"number"New value: +"integer"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "firstPartySourceUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fit": {
+ "anyOf": [
+ {
+ "properties": {
+ "crop": {
+ "anyOf": [
+ {
+ "properties": {
+ "areaKept": {
+ "type": "number"
+ },
+ "removed": {
+ "properties": {
+ "bottom": {
+ "type": "integer"
+ },
+ "left": {
+ "type": "integer"
+ },
+ "right": {
+ "type": "integer"
+ },
+ "top": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "top",
+ "right",
+ "bottom",
+ "left"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "properties": {
+ "height": {
+ "type": "integer"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "result",
+ "removed",
+ "areaKept"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "pad": {
+ "anyOf": [
+ {
+ "properties": {
+ "added": {
+ "properties": {
+ "bottom": {
+ "type": "integer"
+ },
+ "left": {
+ "type": "integer"
+ },
+ "right": {
+ "type": "integer"
+ },
+ "top": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "top",
+ "right",
+ "bottom",
+ "left"
+ ],
+ "type": "object"
+ },
+ "imageFraction": {
+ "type": "number"
+ },
+ "result": {
+ "properties": {
+ "height": {
+ "type": "integer"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "result",
+ "added",
+ "imageFraction"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "source": {
+ "properties": {
+ "height": {
+ "type": "integer"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "source",
+ "crop",
+ "pad"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "video",
+ "image"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "platform": {
+ "type": "string"
+ },
+ "ratio": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "referenceToolUrl": {
+ "type": "string"
+ },
+ "safeAreaInsetsPx": {
+ "anyOf": [
+ {
+ "properties": {
+ "bottom": {
+ "type": "integer"
+ },
+ "left": {
+ "type": "integer"
+ },
+ "right": {
+ "type": "integer"
+ },
+ "top": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "top",
+ "right",
+ "bottom",
+ "left"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "safeAreaKind": {
+ "enum": [
+ "published",
+ "unpublished",
+ "noOverlay",
+ "region"
+ ],
+ "type": "string"
+ },
+ "size": {
+ "anyOf": [
+ {
+ "properties": {
+ "height": {
+ "type": "integer"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "unpublishedReason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "usableBoxPx": {
+ "anyOf": [
+ {
+ "properties": {
+ "height": {
+ "type": "integer"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "usableSharePct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "platform",
+ "label",
+ "kind",
+ "ratio",
+ "size",
+ "safeAreaKind",
+ "safeAreaInsetsPx",
+ "usableBoxPx",
+ "usableSharePct",
+ "unpublishedReason",
+ "firstPartySourceUrl",
+ "referenceToolUrl",
+ "fit"
+ ],
+ "type": "object"
+}list_social_media_placements4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / platform / descriptionPrevious value: -"Optional platform filter."New value: +"Only return placements for this platform. Omit for all platforms."Input schema / properties / platform / enumPrevious value: -[
- "instagram",
- "tiktok",
- "youtube",
- "linkedin",
- "x",
- "facebook"
-]New value: +[
+ "instagram",
+ "tiktok",
+ "youtube",
+ "facebook",
+ "linkedin",
+ "x"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "canonicalDatasetUrl": {
+ "type": "string"
+ },
+ "count": {
+ "type": "integer"
+ },
+ "placements": {
+ "items": {
+ "properties": {
+ "firstPartySourceUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "video",
+ "image"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "platform": {
+ "type": "string"
+ },
+ "ratio": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "referenceToolUrl": {
+ "type": "string"
+ },
+ "safeAreaInsetsPx": {
+ "anyOf": [
+ {
+ "properties": {
+ "bottom": {
+ "type": "integer"
+ },
+ "left": {
+ "type": "integer"
+ },
+ "right": {
+ "type": "integer"
+ },
+ "top": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "top",
+ "right",
+ "bottom",
+ "left"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "safeAreaKind": {
+ "enum": [
+ "published",
+ "unpublished",
+ "noOverlay",
+ "region"
+ ],
+ "type": "string"
+ },
+ "size": {
+ "anyOf": [
+ {
+ "properties": {
+ "height": {
+ "type": "integer"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "unpublishedReason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "usableBoxPx": {
+ "anyOf": [
+ {
+ "properties": {
+ "height": {
+ "type": "integer"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "usableSharePct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "platform",
+ "label",
+ "kind",
+ "ratio",
+ "size",
+ "safeAreaKind",
+ "safeAreaInsetsPx",
+ "usableBoxPx",
+ "usableSharePct",
+ "unpublishedReason",
+ "firstPartySourceUrl",
+ "referenceToolUrl"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "platform": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "count",
+ "platform",
+ "canonicalDatasetUrl",
+ "placements"
+ ],
+ "type": "object"
+}v0.3.0calculate_aspect_ratioconvert_subtitlesestimate_tempoestimate_video_bitrateget_social_media_placementlist_social_media_placementsScored across 7 tools
Each tool has a narrow, clearly separated purpose, and the descriptions explicitly cross-reference the nearest alternatives (get vs. list placements, calculate_aspect_ratio vs. placement-specific crop plans, check_safe_area vs. raw insets). There is no meaningful ambiguity about which tool to select for a given task.
All tool names follow a consistent snake_case verb_noun pattern: get_, list_, check_, calculate_, estimate_, and convert_. No mixed conventions or vague names appear in the set.
Seven tools is well-scoped for a creator utility server, with each tool covering a distinct preparation task. None appears redundant or trivially included just to inflate the surface.
The set covers placement discovery and lookup, safe-area validation, aspect-ratio and crop math, bitrate sizing, subtitle conversion, and tempo arithmetic. Minor gaps remain around actual media-file probing/encoding and richer subtitle styling or validation, but these appear intentionally out of scope for an arithmetic/planning toolkit.
Hosted MCP tools for FFmpeg-style video and audio processing through FFMPEG API.
Short-form video tools: Reels/TikTok/Shorts safe zones, bitrate math, SRT checks, export settings.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
MCP server for the FFmpeg Micro video transcoding API — create, monitor, download transcodes.
