Shotlingo

Import image from URL

import_image

Bring the user’s own screenshot into Shotlingo from a public https link; the server downloads it, so no pixels pass through the chat. Use it when the user can give a link (their own site, a CDN, a shared-file direct link) instead of base64. PNG, JPEG, WebP or GIF, 8 MB ceiling, direct file links only (not a web page). as:"images" (default) just stores it and returns a url; as:"pages" with a projectId also adds a new page showing it full-bleed (right for an already-finished store screenshot). Returns url, width, height. Next: for a RAW app screen call apply_device_frame (projectId, pageId, imageUrl) or generate_page with imageUrl and deviceId; for a finished screenshot imported as a page go on with render_screenshot.

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": {
      "url": "<url>"
    },
    "name": "import_image"
  }
}

Input Schema

Name	Required	Description	Default
`as`	No
`url`	Yes
`pageName`	No
`projectId`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare a non-read-only, open-world, non-destructive operation, and the description adds exactly the context they lack: the server-side fetch (no pixels through chat), 8 MB ceiling, accepted formats (PNG/JPEG/WebP/GIF), and the hard constraint that it must be a direct file link, not a web page. It also discloses what each mode does side-effect-wise — `as:"images"` only stores, `as:"pages"` creates a new page — which is the key behavioral difference for a mutating tool.

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

Conciseness5/5

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

Front-loads the purpose, then usage condition, then constraints, then mode semantics, then return values, then next steps — a clear information hierarchy with an explicit 'Next:' cue. Every clause carries load; there is no restatement of the title or filler.

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?

For a 4-parameter mutating import tool with no output schema, the description covers what it does, when to choose it, size/format/link constraints, the two modes and their side effects, and the return fields (url, width, height). Only `pageName` is left unexplained, a minor gap against otherwise thorough coverage.

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 description coverage is 0%, so the description must compensate, and it does for three of four parameters: `url` (public https direct file link), `as` (enum values with defaults and effects), and `projectId` (required when `as:"pages"`). `pageName` is never mentioned, leaving one parameter undocumented anywhere.

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 ('Bring the user's own screenshot into Shotlingo from a public https link') and immediately clarifies the mechanism ('the server downloads it'), which distinguishes it from base64-based upload_image. The scope (public https, direct file link) is precise enough that an agent can distinguish it from all siblings without opening a 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?

Explicitly says when to use it ('when the user can give a link ... instead of base64'), names acceptable link sources, and names the modal alternative. It also provides explicit routing for follow-up steps: apply_device_frame / generate_page for raw screens, render_screenshot for finished screenshots imported as pages.

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

All Shotlingo 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.