Cactal

Import assets from public URLs

websiteAssets_importFromUrl

Fetches 1-10 public http(s) URLs server-side, one at a time, and stores each as a ready asset with no upload or finalize step. Media only: images, fonts, PDF, audio, video, dotLottie, and Rive; text, data, documents, and archives are refused. Images, fonts, and PDFs must parse as what they claim, hosts on private addresses are rejected, the upload kind and MIME rules apply, and each download is capped at 30 MiB (larger files must be uploaded directly). Each item may carry a description and, for images, a category. Name each item by url, or by photo: the number over a picture on contact sheets webResearch.profile or webResearch.viewImage showed you, which saves copying its long signed link. assets carries successes with CDN URLs and sourceUrl; errors carries failures typed invalid_url, non_public_address, unreachable, too_large, unsupported_type, signature_expired, or unknown_photo (a number you were not shown or that expired; look at the pictures again for current numbers). Import only assets you have the right to use.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "websiteId": "<websiteId>",
      "items": "<items>"
    },
    "name": "websiteAssets_importFromUrl"
  }
}

Input Schema

Name	Required	Description	Default
`items`	Yes	Each item succeeds or fails on its own.
`websiteId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false; the description adds useful context (server-side, one-at-a-time, 30 MiB cap, private-address rejection, no finalize step). This is solid supplementary detail, but it does not explicitly state mutation permanence or per-item partial-failure semantics beyond what the `items` schema already implies. Good value, not exceptional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the essential scope and constraints, but it is a very dense single block covering types, validation, caps, error taxonomy, and legal caveats. All sentences are relevant, yet the packing makes it harder to scan than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does explain return structure (assets with CDN URLs and sourceUrl; errors with typed reasons), which is helpful. However, some behavioral edge cases, such as whether a partially successful batch commits successes and whether retry is safe (idempotentHint=false), are not surfaced. It is adequate but not fully self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description meaningfully clarifies the `photo` field (contact-sheet numbers from webResearch.profile/viewImage) and `category`/`description` usage, but the overall schema coverage is only 50% and fields like `filename` are left to the schema. It improves comprehension of the trickiest parameter without fully documenting every field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (fetches and stores) on a specific resource (public http(s) URLs) and explicitly contrasts with the direct-upload/finalize flow. An agent can tell exactly what this tool produces — ready assets with CDN URLs — versus a generic upload.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use constraints (media types allowed, text/data/documents/archives refused), names the fallback for large files (upload directly instead), and explains the `photo` shortcut over the `url` path. This routes the agent away from wrong inputs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Cactal tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?