GO AI Tools

Reviewed Jan 1, 2000.

• tools: 31 tools scanned
• metadata: scanned

No findings.

Tools (31)

• estimate_ai_tokens

  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.

• generate_app_icon_set

  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

• build_app_store_link

  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 a

• calculate_app_store_net_revenue

  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.

• appstore_search

  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.

• appstore_compare_markets

  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.

• calculate_bmi_and_body_fat

  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%.

• bpm_delay_calculator

  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.

• css_clamp_calculator

  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.

• image_compress

  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.

• image_compression_curve

  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 base6

• check_contrast

  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.

• find_nearest_passing_color

  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.

• strip_image_metadata

  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 f

• generate_favicon_set

  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 o

• project_weight_goal_date

  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).

• convert_heic_to_jpg_png

  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 d

• inspect_mobileprovision

  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.

• recommend_ai_model

  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.

• oklch_convert

  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.

• oklch_ramp

  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.

• plant_watering_calendar

  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.

• build_app_privacy_label

  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.

• recipe_convert_ingredient

  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.

• recipe_scale

  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).

• resize_images

  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 siz

• render_app_store_screenshot

  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.

• check_strings_files

  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.

• calculate_tdee

  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.

• convert_video_to_gif

  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 fit

• estimate_window_light

  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.