GO AI Tools MCP Server

Computes what a developer actually receives from an App Store sale: first removes the storefront's VAT/GST already baked into the customer-facing sticker price, then applies Apple's commission (standard 30%, Small Business Program 15%, or the post-year-one subscription 15%) to that tax-exclusive remainder -- NOT to the sticker price itself, which is the mistake most naive calculators make. Returns a full price breakdown, the effective share of the sticker Apple actually keeps, a side-by-side comparison across all three commission rates (including per-1,000-sales figures), a naive-calculator sanity check showing how far off a 'just take the commission off the top' estimate would be, and warnings when the selected storefront's real tax rate varies by province, state or category (India, Canada, Brazil) rather than being a single fixed number.

Computes BMI (with its standard weight-category label) and body fat percentage via the US Navy circumference method from height, weight, neck, waist, and (for females) hip measurements, plus the resulting lean body mass. The Navy equations are fitted in inches, so metric inputs are converted internally; the body-fat percentage is clamped to 2-75% and rounded to a whole number, matching GO AI's body-fat tool page exactly, including its 'waist must exceed neck (and hip, for the female formula)' impossible-input warning and its out-of-fitted-range caution for raw results below 4% or above 60%.

Calculate Basal Metabolic Rate with Mifflin-St Jeor and Harris-Benedict (plus Katch-McArdle when body_fat_percent is given), then Total Daily Energy Expenditure, a goal-adjusted calorie target (cut/maintain/bulk), and a protein/fat/carb macro split, from sex, age, height, weight and activity level. These are population-average formulas, not a measurement of the person's actual metabolism -- real expenditure commonly varies 200-300 kcal from the estimate, and the result includes a warning flag when a deficit target falls below the usual safety floor.

Looks up one app (by numeric App Store id, or a pasted apps.apple.com URL) in up to 30 App Store storefronts in a single call, via Apple's public iTunes Lookup API, and reports per-market availability, localized title, price and rating. Capped at 30 storefronts per call by design -- there are 173 total App Store storefronts, and this deliberately never sweeps all of them in one call; call again with a different storefronts list to cover more markets. Lookups run one at a time with a short pause between each (matching the pacing the source browser tool uses for its 30-market quick-compare), so a full 30-market call takes roughly ten seconds, not an instant burst.

Searches one Apple App Store country storefront by term, via Apple's public iTunes Search API (the same request the GO AI "App Store storefront checker" tool makes from the browser), and returns matching apps with title, seller, price, rating and a direct App Store link. Returns up to 200 results, Apple's own per-request maximum -- a result of exactly 200 likely means more exist. Results are ordered by Apple's internal relevance, which does not match the ranked list shown in the App Store app, so this cannot be used to track keyword rank.

Given which SDKs and features are present in an iOS app (analytics, crash reporting, ads, attribution, accounts, in-app purchases, location, HealthKit, contacts, search, etc.), returns the App Store Connect privacy data types those items most likely require declaring, grouped the way Apple groups them (Contact info, Identifiers, Usage data, Diagnostics, ...), each with the reason (which chosen item(s) caused it), plus whether App Tracking Transparency/tracking applies and the vendor-documentation date the mapping was checked against. This is a fixed, deterministic lookup table shipped with GO AI's privacy-label-builder page -- not a code scanner and not compliance advice. SDKs change what they collect (sometimes in a minor version) and app configuration changes it further, so treat the result as a starting checklist to verify against each SDK's current documentation, not an answer to submit as-is.

Builds a correct apps.apple.com URL for an app ID or a pasted App Store URL, in a chosen two-letter storefront, with optional App Store Connect campaign attribution parameters (pt, ct, and mt=8). Always returns the assembled URL and a params table describing what each part does. When includeQr is true, also renders the URL as a QR code PNG using the same hand-rolled, dependency-free Reed-Solomon byte-mode encoder (error-correction level M, versions 1-10) the source browser page draws to its own <canvas> -- not a generic QR library, so the module layout, masking, and pixel output match that page exactly. The encoder tops out at 213 UTF-8 bytes for the assembled URL (version 10 ceiling); a longer URL fails cleanly naming the byte counts rather than returning a broken code -- shorten pt/ct or call again with includeQr:false to still get the plain URL. The storefront code is not checked against the list of real App Store storefronts -- a well-formed but unused code just will not have the app listed on it.

Converts iPhone HEIC/HEIF photos to JPEG or PNG, decoding with a WebAssembly build of libheif (LGPL-3.0) and re-encoding with sharp -- the same pipeline as GO AI's browser-based HEIC converter tool, run server-side. Accepts 1-50 files as {filename, dataBase64} (each up to ~30MB decoded); every file is byte-sniffed by its actual magic bytes, never by filename extension or claimed mime type, so an iPhone photo that iOS already delivered as a JPEG (picked from Photos rather than Files) is detected and reported as already_converted -- passed through unchanged, not re-encoded -- while real HEIC/HEIF input is decoded and re-encoded to the requested format (JPEG with a caller-set quality 50-100, or lossless PNG). Any orientation stored on the HEIC is applied automatically during decode, so output comes out right-side up. Metadata (EXIF: GPS, timestamp, camera) is not carried over, matching the source page. Each converted or passed-through file is returned individually (inline if small, as a download link if large), or bundled as one converted.zip when bundleAsZip is true and more than one file produced output; a file that fails to decode is reported with status failed and an error message rather than aborting the batch. The JSON report lists status, dimensions, and before/after byte sizes for every input file, in input order.

Ports GO AI's browser Live Photo-to-GIF tool server-side: trims a SHORT video clip and converts it to an animated GIF, or (a server-side addition the browser tool cannot do) a real MP4/WebM video. Input is base64 video bytes plus its mimeType (any container/codec this server's ffmpeg build can decode) and a trim range in seconds (startSeconds/endSeconds). HARD LIMITS -- this runs in a 400 MB container on one shared vCPU behind a proxy that hangs up at 125s, so an over-budget request is REJECTED up front with a message naming the limit rather than accepted and then killed. Read these before calling: (1) the video itself must decode to at most 4 MB -- send a pre-trimmed clip, not a whole recording; (2) the trim range must span at least 0.25s and at most 10s; (3) width x height x frames must not exceed 12 megapixels TOTAL across the whole animation. That third one is the binding limit in practice and it is easy to trip with a portrait clip: at size=480 a 9:16 video is 480x854, so it fits about 29 frames (~2.9s at fps=10) -- while a 16:9 video at the same size is 480x270 and fits the full frame cap. If a call is rejected, the error names the exact frame/size that would fit; do not retry with the same numbers. size picks the output width in px (0 keeps the source's own width, clamped to 720; otherwise 720/480/320/240, default 320). Height is derived to preserve aspect ratio and both are forced even (a hard requirement of GIF and most video codecs). fps (10/12/15/20/25, default 10) is the target sampling rate; because GIF frame delays are whole hundredths of a second, the achieved rate (actualFps in the result) is rounded and rarely matches exactly what was requested -- always read actualFps back, do not assume it equals fps. speed (0.5/1/1.5/2) scales playback; speed below 1 samples MORE frames from the same span and so costs more of the pixel budget. motion is loop (plays once per cycle, restarts abruptly), bounce (plays forward then backward so it never visibly cuts -- this roughly DOUBLES the emitted frame count and therefore halves the span that fits the pixel budget), or once (plays through and stops; GIF only, this disables the NETSCAPE2.0 loop extension). For format 'gif' (the default): at most 120 frames are sampled from the trim range (bounce mirrors the middle back on top of that afterward, so a bounced GIF can carry up to 238 frames if the pixel budget allows), and colours (256/128/64, default 256) sets the palette size. The palette is a single median-cut palette built across every sampled frame at once, not per frame, exactly like the source -- a clip with wildly different scenes (e.g. a cut between two very different shots) will show banding because the whole clip is sharing one 256-or-fewer-colour palette. dither (default true) enables Floyd-Steinberg dithering, which smooths gradients at the cost of file size and adds visible noise to flat graphics/screen recordings -- turn it off for those. For format 'mp4' (H.264) or 'webm' (VP9): frame sampling and the GIF palette pipeline are skipped entirely and ffmpeg encodes the trimmed/scaled/speed-adjusted clip directly in one pass; audio is always dropped, since the source tool this is ported from is silent-GIF/loop focused and has no audio-preserving path of its own. The same trim-span and pixel limits apply. Frame extraction for GIF approximates the source's exact evenly-spaced-timestamp sampling with ffmpeg's own fps-filter resampling of the decoded stream (documented in code as a deliberate simplification, not a literal port) -- for most clips this is visually indistinguishable, but timing will not be bit-identical to the browser tool's output for the same input. Returns the encoded file (inline if small, otherwise a download link) plus a JSON stats object: frameCount (gif only), width, height, byteSize, requestedFps, actualFps, delayCentiseconds (gif only), format, outputPixels, maxOutputPixels, and more. An oversized request, a trim under 0.25s, an undecodable video, or an unsupported codec is reported as a tool error naming the problem, never a crash.

Heuristic estimate (NOT a real per-model BPE tokenizer) of how many tokens a piece of text will become, ported from GO AI's browser-side token counter. Blends a chars/4 and words/0.75 baseline with surcharges for punctuation, digits and non-Latin script; typically within ±10-15% for ordinary English prose and ±15-25% when non-Latin script is detected -- code and heavily punctuated text tend to tokenize denser than this suggests. Also reports whether the text fits a set of context windows (default: 8K/128K/200K/1M/2M tokens, or pass your own) and, if you supply per-million-token prices, an estimated USD cost. Use a provider's own tokenizer for exact billing figures.

Estimates the indoor light level a window gives a plant, in the category words houseplant care guides use (Direct sun / Bright indirect / Medium light / Low light / Too dark), from the window's hemisphere, compass aspect, what obstructs it, and how far back the plant sits from the glass. This is a small heuristic scoring table ported from GO AI's window-light tool page, not a physical light-meter reading or a per-location sun-position model — it correctly flips which compass direction is 'bright' for the southern hemisphere and flags the direct-west-sun scorch risk, and returns the reasoning behind the verdict plus a shortlist of plants suited to that light level.

Turns one source image into a ZIP containing a complete iOS Xcode AppIcon.appiconset (AppIcon.png at 1024x1024, plus a hand-written Contents.json Xcode accepts, and optionally AppIcon-Dark.png and AppIcon-Tinted.png for the appearance variants modern iOS asks for), a full Android mipmap-mdpi/hdpi/xhdpi/xxhdpi/xxxhdpi set of ic_launcher.png files (48/72/96/144/192px), and a flat sizes/ folder with 24 icon-<px>.png files from 16 to 1024px. Any transparency in the source is flattened onto the given background colour first (Apple rejects icons with alpha). A non-square source is centered and letterboxed onto a square canvas rather than stretched. Every output size is produced by repeatedly halving the source (a box-filter-equivalent downscale) before one final resize to the exact target, which keeps small icons sharp instead of muddy. The dark variant is a mechanical darken (source composited at 82% opacity over black) offered as a starting point, not a real design pass -- review it before shipping. The tinted variant is a Rec.709 greyscale luminance map, which is what iOS actually wants for that slot (it applies the colour itself). The JSON result reports the source dimensions, whether it had transparency, the file count, and two non-fatal warnings when the source was not square or not exactly 1024px on its longest side. Always returns as a resource_link (a 30+ file ZIP is never small enough to inline) -- fetch the link to get the archive.

Turns one source image into a complete favicon set: favicon.ico (a real multi-resolution ICO container holding 16, 32 and 48px PNG-encoded entries -- not a single-size file with an .ico extension), favicon-96x96.png, apple-touch-icon.png (180px, flattened onto backgroundColor because iOS paints transparency black there), web-app-manifest-192x192.png and web-app-manifest-512x512.png (optionally padded to Android's maskable safe zone -- the artwork shrunk to a centred 80%-width square on the background colour, reproducing the source tool's square padding rather than clipping to the actual inscribed-circle safe area), site.webmanifest, and the exact 5-line HTML <head> snippet (favicon.ico link, favicon-96x96.png link, apple-touch-icon link, apple-mobile-web-app-title meta, manifest link) ready to paste. A non-square source is centred on a transparent square canvas first, so nothing is stretched. Ported from GO AI's browser-based favicon tool, run server-side with @napi-rs/canvas instead of a DOM <canvas>. Every PNG and the .ico are small (a few KB to worst-case a couple hundred KB), so all six files are returned individually rather than zipped -- each name matters (favicon.ico and site.webmanifest belong at the site root) and there is no batching benefit to a ZIP at this size. The JSON result carries the manifest JSON text, the HTML snippet text, a per-file table of what each output is for, and a warning when the source is smaller than 512px on its longer side (the 512 icon will be upscaled). Fails with a clear message rather than throwing if the input cannot be decoded as an image.

Downscales an image to fit within a maximum dimension (default 1600px on the longer side, never enlarges -- matching GO AI's browser compressor tool) and re-encodes it as JPEG, WebP or AVIF at a given quality (1-100 scale, default 75). Input is base64-encoded image bytes (any format sharp/libvips can decode: JPEG, PNG, WebP, AVIF, GIF, TIFF, ...), not a file path or URL, capped at this server's input size limit. Returns the compressed image bytes plus a stats object: original and compressed dimensions and byte sizes, and the percent size change (positive = smaller, negative = the re-encode came out bigger, which happens when compressing an already-small, already-compressed image). Re-encoding always strips EXIF/ICC metadata, exactly like the source tool.

Analysis-only tool (no image bytes returned): re-encodes an image at the same fixed 14 quality levels GO AI's browser compressor samples to draw its size-against-quality curve (5, 10, ..., through 100 -- see the qualities in each returned point), for JPEG, WebP or AVIF, and reports the resulting byte size and percent change at each level. The image is first downscaled to fit within maxDimension (default 1600px on the longer side, never enlarged), exactly as the source's working canvas is, then every quality level is encoded one at a time. Because this repeats the encode 14 times, its maxDimension is capped at 2000px -- lower than image_compress's 4000px -- which costs nothing in practice, since the knee of the curve is a property of the image's content and sits in the same place at either size. Use this to find that 'knee' (where size stops dropping much per quality point) for a specific image, or image_compress to actually get the compressed bytes at one chosen quality. Input is base64-encoded image bytes, not a file path or URL.

Converts a color to and from OKLCH. Accepts either a CSS color string via `color` (hex, rgb()/rgba(), hsl()/hsla(), or oklch()) or explicit OKLCH lightness/chroma/hue via l, c and h — supply one or the other. Returns the canonical oklch() text for the color exactly as requested, plus its sRGB-gamut-mapped hex/rgb()/hsl() equivalents. Gamut mapping follows the CSS Color 4 algorithm (bisecting on chroma at constant lightness and hue, not channel-clipping) and only targets sRGB — there is no P3 or Rec2020 support.

Builds a perceptually even OKLCH swatch ramp from a base color (same `color` or l/c/h input as oklch_convert) by sweeping one channel — hue, lightness, or chroma — while holding the other two fixed, so every swatch keeps the same visual weight (this is the reason to build a ramp in OKLCH rather than HSL). Each step is gamut-mapped to sRGB with the CSS Color 4 chroma-reduction algorithm and returned with its hex preview, plus a ready-to-paste `:root { --name-1: oklch(...); ... }` CSS block.

Converts an amount of one ingredient between cup, tablespoon, teaspoon, millilitre, gram and ounce using that specific ingredient's own USDA FoodData Central portion weight, not a single water-based figure applied to everything -- a cup of flour (125 g) and a cup of honey (339 g) do not weigh the same. Supports an ingredient's own measurement-style variants where USDA publishes more than one (packed vs loose brown sugar, sifted vs unsifted powdered sugar, whole vs sliced/slivered/ground nuts, etc.), and for baking powder, baking soda and yeast uses USDA's own published teaspoon weight rather than dividing the cup weight by 48, since a spoon measurement of a fine powder is not proportionate to its cup measurement. Also reports, for information, what a generic water-density converter would have said for the same input and by how much that would have been wrong -- omitted when the requested unit is already grams or ounces.

Scales a pasted recipe (one ingredient per array entry, e.g. '2 cups all-purpose flour') from one servings count to another, multiplying each line's leading amount by the ratio and reformatting it as a whole number or simple/mixed fraction rather than a decimal. When a line's unit and ingredient can both be recognised against GO AI's density table, appends the scaled amount's weight in grams in parentheses; lines already given in grams or ounces, lines whose ingredient isn't recognised, and lines that don't start with a parseable amount are returned unchanged (the last completely as-is, typos included).

Resolves a musical tempo — either a direct BPM, or a set of tap timestamps/intervals run through the same median-filtered outlier rejection and 2-second session-reset logic as GO AI's tap-tempo tool — then returns the full straight/dotted/triplet delay and LFO-rate table (ms and Hz) for a set of note divisions, plus bar-length and bars<->seconds conversion for a time signature. All arithmetic (not a real audio engine) — useful for setting delay/reverb/LFO times to a track's tempo.

Computes the WCAG 2.x contrast ratio between a foreground (text) and background hex colour, and reports AA/AAA pass or fail for normal text, large text, and UI components (icons/borders/focus rings) separately, since WCAG grades each case on its own threshold. Also reports the newer APCA Lc figure alongside it for information -- APCA is not yet what conformance is measured against, only the WCAG ratio is.

Generates a CSS clamp() declaration (in rem) that linearly interpolates a size between a value at a small viewport width and a value at a large one, exactly matching GO AI's clamp() calculator tool (same slope/intercept math, rounded to 4 decimal places). Returns a status: 'sameViewports' when the two viewport widths are equal (no line can be drawn -- css is null), 'flat' when the min and max sizes are equal (a constant, clamp() unneeded), 'inverted' when the max size is smaller than the min (still valid CSS, but the computed size shrinks as the viewport grows), or 'ok' otherwise. Optionally evaluates the computed pixel size at a list of preview viewport widths, and optionally generates a matched fluid type scale by multiplying both endpoints by ratio^step for a given number of steps -- unlike the website's five-option dropdown, any positive ratio is accepted here since the underlying math is not limited to those presets.

Reads an iOS/macOS provisioning profile (.mobileprovision or .provisionprofile, given as base64) by byte-searching its CMS/PKCS7-signed container for the embedded '<?xml ... </plist>' property list and parsing that XML -- it never validates or decodes the cryptographic signature, and does not report on the embedded certificates beyond how many there are. Reports expiry status and days remaining, profile type (development/ad hoc vs. enterprise vs. App Store distribution, classified only from the registered-device list and the ProvisionsAllDevices flag), team and application identifiers, the full entitlements dictionary, and the count and UDIDs of registered devices. Returns a structured { ok: false, error, message } result (not a thrown error) for an unreadable input, a file with no embedded plist, or a plist that fails to parse.

Given a foreground/background hex pair, moves only the lightness of one side (hue and saturation held fixed) in the smallest step that clears a target WCAG contrast ratio, so a failing brand colour can be fixed without draining its hue. Defaults to the 4.5:1 normal-text AA threshold, matching the source page's fix buttons; pass a named threshold ('normal-aa', 'normal-aaa', 'large-aa', 'large-aaa', 'ui-aa') or a custom numeric ratio to target something else. Reports found:false when even pure black or white in that hue cannot reach the target -- that pair needs a different hue, not a different lightness.

Builds a soil-check interval per houseplant from a fixed drought-tolerance table (32 common houseplants), adjusted by pot size, pot material, light and season, and returns both a schedule breakdown and the full text of a downloadable RFC 5545 .ics calendar file -- one recurring all-day 'check the soil' reminder per plant (deliberately never 'water', since only the plant's own soil can say that). Matches GO AI's browser watering-calendar tool exactly, including its northern-hemisphere-season default when `season` is omitted, its terracotta/glazed/low-light/winter multipliers, and its 75-octet .ics line folding. The starting intervals are heuristic drought-tolerance bands, not a measurement of any specific plant, pot or room -- the tool says so in its own FAQ.

Projects the calendar date a goal body weight is reached under a fixed daily calorie intake. Unlike a naive straight-line calculator (kg to lose x 7700 / deficit, also returned here for comparison), this recomputes Mifflin-St Jeor maintenance calories at each simulated day as weight falls, so the effective deficit narrows the way it really does -- meaning the projected date is later than, or equal to, the naive one, never earlier. Refuses to project a date when the resulting intake falls below a 1500 kcal (men) / 1200 kcal (women) floor, and reports a 'plateau' outcome instead of a date when the goal sits at or below the weight where maintenance would settle at that intake (an asymptote that a fixed intake alone can never cross). Adult-only inputs (18+); only projects weight loss (goalWeight must be less than currentWeight).

Static editorial recommendation -- NOT a live benchmark or leaderboard -- for which of six AI models (GPT-5, Gemini, Grok 4, Claude, DeepSeek, Kimi) to use for a given kind of task, ported from GO AI's own daily side-by-side-use judgement, current as of August 2026. Pick a task and get the recommended model plus the reasoning and a second-opinion backup. The optional `priority` can bias the pick toward cost (routes to DeepSeek) or freshness (routes to Grok) instead of the default quality pick -- but only for tasks where that tradeoff is actually offered; otherwise the quality default is returned unchanged. This reflects one team's opinion, not measured accuracy or pricing data.

Composite one or more app screenshots into a drawn device frame (rounded bezel, Dynamic Island on phone-shaped canvases) with a gradient background and optional headline/caption text, and export as PNG at any/all of the 4 official App Store Connect sizes. A blank page (image omitted) draws no device, for a title card or an outro. A device positioned past the edge of its page is drawn spilling onto the neighbouring page too, so a set can run one screenshot into the next. LIMITS — this runs on a small shared host, so an over-limit call is refused immediately, before any rendering, with a message saying how to split it: at most 10 pages at any one size, 2 at size:"all" (which renders every page 4 times over — a longer set needs one call per size); at most 12 rendered PNGs per call (pages x sizes); 6 MP per screenshot and 4 MB of screenshot bytes summed across the whole call (send JPEG, not PNG, for a multi-page set); and at most 40 text layers of 512 characters each.

Resizes a batch of 1+ images to a named real-world preset (App Store screenshots, Open Graph/social cards, Android launcher icon densities, a favicon set) or a custom width/height, using contain (whole picture, padded), cover (fills the frame, crops overflow) or stretch (distorts to fit) fitting. Each resized image is PNG-encoded (EXIF/ICC metadata stripped on re-encode, matching the source page) and every image is auto-rotated per its embedded EXIF orientation before resizing. All outputs are packaged into one uncompressed ZIP (PNG bytes are already compressed, so a second pass would not shrink them), foldered by preset (e.g. "social/photo-1200x630.png", or "android/mipmap-hdpi/icon.png" for the Android density preset, which names each size's folder after its density instead of suffixing the pixel size). This always returns as a resource_link (a batch ZIP is never small enough, or singular enough, to inline) -- fetch the link to get the archive. Per-file output dimensions and byte sizes are reported in the JSON result. Each input image (base64) is capped by this server's per-input byte limit.

Compares two or more iOS Localizable.strings files (sent as base64-encoded raw file bytes, not text) against a base file and reports keys missing from each other file, keys present in another file but not the base ("extra", reported but not counted toward the issue total), values byte-identical to the base (often untranslated, sometimes intentionally so), duplicate values under different keys within the same file (case- and trailing-punctuation-insensitive), and lines that fail to parse with their line number. Sniffs a UTF-8 or UTF-16 LE/BE byte-order mark per file so files exported by Xcode in UTF-16 decode correctly instead of producing a wall of parse errors. Does not support the newer .xcstrings JSON catalogue format, and does not check plural rules or placeholder (%@/%d) consistency between files -- it is a pure key/value diff.

Reads a JPEG or PNG's hidden metadata (JPEG: EXIF — camera make/model, lens, body/lens serial numbers, capture date, GPS coordinates and altitude — plus XMP, IPTC/Photoshop resources and comment segments; PNG: tEXt/iTXt/zTXt/eXIf/tIME chunks) and returns a structured report of exactly what it found, including the size of every metadata segment/chunk that was removed. Optionally (include_cleaned_image, default true) also returns the same image with those segments/chunks stripped at the byte level: no re-encoding and no pixel decode, so the compressed image data, ICC profile, and JFIF/PNG structure are copied unchanged. It runs a byte-for-byte self-check that the retained image data is actually unchanged before handing back a cleaned file — if that check fails, no cleaned file is returned even though the report is still produced. Only JPEG and PNG signatures are recognized (not TIFF or other formats); stripping a photo's EXIF Orientation tag can make it appear rotated, which the report flags.