Is GO AI Tools MCP server safe?

Findings (2)

• lowUnusually long tool description (over 2,000 characters)poison.long-description

  tool 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 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.…

• lowNo source repository listedmaint.no-repo