Is aicut MCP server safe?

Findings (2)

• highWrite-action tools reachable without authenticationauth.open-write
• lowUnusually long tool description (over 2,000 characters)poison.long-description

  tool list_models: …Returns the AI video, image and audio models this API can generate with, each with the exact parameters it accepts (names, allowed values, limits, defaults where it has them), the media inputs it takes, and its pricing. WHEN: always call this before the first `generate_video`, `generate_image` or `generate_audio` of a session. Model names cannot be guessed, and neither can which resolutions, durations or aspect ratios a given model allows - `generate_*` rejects a combination this endpoint does not publish. The one exception is a speech model's `voice`, whose published `options` are a RECOMMENDED set rather than a closed one: prefer them, but a voice id the user gives you is accepted too. NARROW IT, DO NOT PULL IT. The unfiltered listing is several thousand tokens, most of it pricing tables, and every argument below SELECTS from it without changing a single entry. `query` is free text - send the user's own words (`query: 'vertical product ad'`) and read `ignored_query_terms` on the way back: those are the words that match nothing in the catalog and were dropped, so if it comes back holding most of your sentence, the narrowing you got was smaller than you asked for. `tags` is the closed vocabulary, ANDed - `tags: ['video', 'vertical', 'reference-image']` is the precise version of that same question. `type` is the product, `model` is one id once you know it. THE TAGS, and every one of them is DERIVED from a field on the entry beside it rather than hand-labelled: `video` / `image` / `audio` (the product); `speech` / `music` / `sound-effects` (which audio product); `vertical` / `horizontal` / `square` (computed from the model's own `aspect_ratios`, so a model with several carries several); `image-input` and its detail `start-image` / `end-image` / `reference-image`, or `text-only` when the model takes no picture at all; `native-audio` when the model takes an `audio` switch you can turn on (it defaults to OFF, and a model can carry sound natively without offering the switch). `tag_vocabulary` rides on every answer, so you never have to guess one - an unknown tag is a 400 naming the whole set, not an empty list. THERE IS NO DURATION TAG on purpose: any cut between 'short' and 'long' would be taste frozen into a catalog. Durations are searchable instead (`query: '10'` finds the models offering a 10-second clip) and every entry carries its full `durations` array. IT PAGES ONLY IF YOU ASK. With no `limit` you get every matching model, which is this endpoint's long-standing behaviour and is fine once you have filtered. Send `limit` when you have not: the answer then carries `total_matching`, `has_more` and `next_cursor`, and READ THEM before telling a user something does not exist - a page is not the catalog. Continue with `cursor` set to that `next_cursor` and the SAME `query` / `tags` / `type`; changing a filter invalidates the cursor and is a 400, not a silent restart. PRICING COMES IN TWO SHAPES, and each entry carries exactly one. Video and image models carry `pricing`, an enumerated table: match the row whose resolution, duration, quality and audio equal the settings you intend to send, and that is what the generation costs. Audio models carry `pricing_rates` instead - a rate over an input with no fixed set of values (per character of speech, per minute of music, per second of sound effect) - so there is no row to match and you must NOT multiply the rate out yourself. Price those with `estimate_only: true` on `generate_audio`. OUTPUT: this returns JSON for you to read. When you report back to the user, give them the media URL plus a one-line summary. Do not paste the raw JSON, job ids, or internal field names into the conversation.…