Ignix

Import external files

import_media

Download public URLs and re-host them on durable Ignix storage, returning stable URLs usable as post media or as the file of a chatbot flow node. Use it for any asset that lives outside Ignix (a signed URL, a temporary CDN link, an image the user gave you): links from other services expire and the post would publish without media. One file with url, or up to 50 at once with urls (an album, a batch of photos): each comes back with its own result. Images, video, audio and PDF/Word/Excel/CSV/ZIP documents are accepted (an SVG, such as a logo from a website, is converted to a PNG about 2000 px wide with a transparent background); anything else is refused, because re-hosting an arbitrary file would put someone else's content on our domain. This needs a URL that is already public — if the file is on the user's machine, use upload_media instead. Docs: https://ignix.social/help/content-library

Input Schema

Name	Required	Description
`url`	No	Public https URL of the file.
`type`	No	What the file is. Inferred from the URL when omitted, defaulting to image. Audio and documents are for chatbot flow nodes, not for posts.
`urls`	No	Several public https URLs (up to 50) to import in one call. Use instead of `url`.
`description`	No	Optional note stored with the asset in the library.
`workspaceId`	No	Workspace to work on (an id from list_workspaces). Not needed when this connection is tied to one workspace, or when you pass an account: the account's workspace is used.
`idempotencyKey`	No	Optional. A unique id for this action (16-128 chars: letters, digits, _ : . -). If you are unsure whether a call went through (timeout, network error), repeat it with the SAME idempotencyKey and the same arguments: you get the original result and nothing is done twice.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 18, 2026

addedInput schema / properties / urls

Added value: +{
+  "description": "Several public https URLs (up to 50) to import in one call. Use instead of `url`.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 50,
+  "type": "array"
+}

removedInput schema / required
```
Removed value: -[
-  "url"
-]
```

First observedOct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) by disclosing what is accepted and refused, that unsupported files are rejected to avoid re-hosting third-party content, and that SVGs are converted to a ~2000px PNG with transparent background. Batch behavior ('each comes back with its own result') and the public-URL prerequisite are also stated.

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

Conciseness4/5

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

Front-loaded with the core action and result, and every sentence carries actionable content (acceptance list, SVG conversion, upload_media routing, docs link). It is a dense single paragraph rather than a structured list, which slightly hurts scannability but not enough to call it bloated.

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

Completeness5/5

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

No output schema exists, yet the description explains the return value (stable URLs, per-item results in batch mode). With all six parameters documented in the schema and the safety profile in annotations, nothing an agent needs to call this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds the url-vs-urls relationship ('One file with `url`, or up to 50 at once with `urls`') and the intended use case for batches (album, batch of photos). Type inference is restated from the schema rather than extended, keeping this just above baseline.

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 and resource — download public URLs and re-host them on durable Ignix storage — plus the concrete output (stable URLs usable as post media or chatbot flow node files). It also distinguishes itself from the sibling upload_media, so an agent can tell the two apart without opening either schema.

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?

Explicit when-to-use list (signed URL, temporary CDN link, image the user gave you) with the underlying rationale that external links expire and posts would publish without media. It also gives an explicit when-not and names the alternative: 'if the file is on the user's machine, use upload_media instead.'

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

All Ignix tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?