Skip to main content
Glama
Sign In
scratch-unified-mcp

scratch-unified-mcp

by blessed0x
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Sb3 Screenshot Jpeg

sb3_screenshot_jpeg

Capture the live stage of a running Scratch project as a compressed JPEG image. Use this to inspect the current visual output headlessly.

Instructions

Capture the live stage as compressed JPEG. (proxied)

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": "sb3_screenshot_jpeg"
  }
}

Input Schema

NameRequiredDescriptionDefault
qualityNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden, but it only reveals that the output is a compressed JPEG and that the capture is proxied. It does not mention side effects, prerequisites like a running project/VM, timing, or failure behavior. The 'proxied' note adds a little context but is too terse to be sufficient.

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 a single front-loaded sentence with no filler; the parenthetical 'proxied' adds a relevant behavioral note. Every word earns its place.

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?

For a one-optional-parameter capture tool with an output schema, the core action and format are stated. However, the description omits parameter semantics and any relationship to the active project/VM, so it is only minimally complete.

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

Parameters1/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 by explaining the quality parameter, but it does not. The word 'compressed' only hints at quality; it never states valid values, effect of lower/higher quality, or that quality defaults to 80.

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 names a specific verb ('Capture'), a distinct resource ('the live stage'), and the output format ('compressed JPEG'). This clearly differentiates the tool from the sibling sb3_screenshot, which is positioned as the plain/uncompressed capture alternative.

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

Usage Guidelines2/5

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

There is no guidance about when to choose this JPEG variant over sb3_screenshot or how 'proxied' affects the call. The only implied usage is that a compressed JPEG is desired, but no explicit when-to-use or alternative is described.

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

Deploy Server

Other Tools