Skip to main content
Glama
Sign In

Moatless

by store.moatless
OverviewDiscussionsAdmin

Get a screenshot upload URL

screenshot_upload_url

A URL to upload screenshots to one of the actor's listings, for one device, valid for an hour. POST each image to it as multipart form data: the file as image, and optionally a caption. Upload them in the order they should appear.

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": {
      "input": "<input>",
      "context": "<context>"
    },
    "name": "screenshot_upload_url"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputYes
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. Never include personal data, such as names, email addresses or message text; refer to people by role, such as "the user" or "a buyer".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / context
      Added value: +{
+  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. Never include personal data, such as names, email addresses or message text; refer to people by role, such as \"the user\" or \"a buyer\".",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "input"
-]New value: +[
+  "input",
+  "context"
+]
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only declare openWorldHint=false and destructiveHint=false, so the description must carry the behavioral burden and it does: the URL expires after one hour, payload format and field names are specified, and ordering of images is called out. It still omits what happens if the URL expires mid-upload or whether calling it has any side effect on the listing itself, which keeps it below 5.

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?

Four short sentences, front-loaded with what is returned and its lifetime, then the exact mechanics. Every sentence carries information the agent needs and nothing is repeated from the schema.

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

Completeness4/5

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

There is no output schema, and the description effectively supplies the return semantics (a URL with a one-hour TTL) plus the follow-up protocol, so an agent knows what to do. Remaining gaps are secondary: no mention of authorization requirements, size/format limits, or whether a new call is needed per device.

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 adds no meaning for the two actual inputs (`input.listing_id` and `input.device`); device values are knowable only from the schema enum. With schema description coverage at 50%, the description compensates by describing the multipart fields used against the returned URL, but those are not schema parameters, so the net gain over the schema is limited.

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

Purpose4/5

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

States a specific verb and resource: it returns an upload URL for screenshots attached to one of the actor's listings, scoped to a single device, with a one-hour lifetime. That is far more informative than the title alone. It does not explicitly name a sibling such as update_screenshot or remove_screenshot to distinguish the workflow step, so it stops short of a 5.

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

Usage Guidelines3/5

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

Usage of the returned URL is spelled out well (POST multipart form data, file as `image`, optional `caption`, upload in display order), which tells the agent how to act after calling. However, there is no guidance on when this tool is the right choice versus update_screenshot/remove_screenshot, and no prerequisites such as ownership of the listing are stated. Usage is implied rather than framed.

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

All Moatless toolsInspect
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