Ravenpost

Import app store screenshots

import_app_screenshots

Copy an app's store listing pictures — its phone screenshots and its icon — from the App Store or Google Play into the media library, returning media ids: the screenshots become shots for create_video (app_showcase especially) and the icon its brand mark (iconMediaId). Reads the listing the workspace's brand profile holds when no url is given. Costs no credits; a picture already imported is reused rather than copied again. Apple's listing is read through its lookup API; Google Play's from its page, best effort.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "import_app_screenshots"
  }
}

Input Schema

Name	Required	Description
`url`	No	The App Store or Google Play link; omit to use the brand profile's
`limit`	No	How many screenshots at most (default 6)
`store`	No	Which of the profile's listings to read (default: the App Store one when both are saved)
`workspaceId`	No	Which workspace to act in — an id from list_workspaces. Optional with a single workspace; REQUIRED once there are several, where guessing would mean posting one client's content to another client's accounts. Ask the user which one before publishing.

Output Schema

Name	Required	Description	Default
`ok`	No
`icon`	No
`name`	No
`next`	No
`store`	No
`reused`	No
`screenshots`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond annotations, it discloses that the operation costs no credits, reuses already-imported pictures, reads from the brand profile when no URL is provided, and treats Google Play extraction as best effort. These details add meaningful behavioral context while remaining consistent with the annotations.

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?

The description is compact and front-loaded, leading with the action and resource before covering fallback behavior, credit cost, and reuse. Every clause contributes useful context without unnecessary repetition.

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?

Given the output schema exists, the description need not explain return values in detail. It still covers the key operational facts an agent needs: source stores, profile fallback, credit cost, reuse behavior, and downstream use of imported media.

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?

Schema description coverage is 100%, so the schema already documents url, limit, store, and workspaceId thoroughly. The description adds some context about url omission but does not significantly expand parameter semantics beyond what the schema provides.

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?

The description states a specific verb and resource: copy an app's store listing screenshots and icon from the App Store or Google Play into the media library. It also explains the downstream purpose, naming create_video and iconMediaId, which distinguishes it from generic media tools such as upload_media or attach_media.

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

Usage Guidelines4/5

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

The description clarifies the core usage context: omit the URL to use the workspace brand profile, and the resulting screenshots feed create_video. It does not explicitly compare against alternatives like upload_media or capture_screenshot, but the intended use case is clear.

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

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