godot-sprite-mcp

Overview Schema Source Related Servers Discussions Admin

inspect_spritesheet

Analyze a PNG spritesheet’s alpha channel to detect and return frame rectangles, so you can discover its layout before building animations.

Instructions

Inspect a PNG spritesheet and return frame rectangles.

Use this tool before building animations when you need to discover the frame layout of a spritesheet. The alpha channel is analysed; pixels with alpha strictly greater than alpha_threshold count as opaque.

Args: image_path: Absolute path, relative path, or res://... URI to the source PNG. alpha_threshold: Opaque-pixel cutoff in the inclusive range 0..255. Defaults to 10, so nearly transparent antialiasing is ignored. mode: Detection strategy: "grid" finds fully transparent horizontal/vertical separator lines, "islands" finds 8-connected opaque islands and their tight bounding boxes, and "auto" tries "grid" first and falls back to "islands" when cell sizes are not uniform. project_root: Optional Godot project root directory used to resolve res:// URIs or relative paths.

Returns: A JSON-compatible dictionary with image_width, image_height, the detected mode, frame_count, and frames. Every frame is {"id": int, "x": int, "y": int, "w": int, "h": int, "pivot_bottom_center": [float, float]}. Frames are ordered top to bottom (row-clustered), then left to right.

Input Schema

Name	Required	Default
`mode`	No	auto
`image_path`	Yes
`project_root`	No
`alpha_threshold`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 31, 2026

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the full behavioral burden. It describes the analysis method (alpha channel, threshold semantics, mode fallback), which is helpful, but does not explicitly state that the tool is read-only or non-destructive. An agent might infer safety from 'Inspect', but it is not confirmed, which is a notable gap without annotations.

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?

The description is well-structured with a summary, usage note, Args, and Returns sections, and is front-loaded with the core purpose. It is efficient, though the Returns section redundantly re-describes the output schema, adding some unnecessary length.

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?

Given a 4-parameter tool with an output schema, the description covers parameter semantics, usage context, and return structure thoroughly. It lacks only an explicit safety/read-only statement, which is minor given the inspection nature and the presence of the output schema for return details.

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

Parameters5/5

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

Schema description coverage is 0%, but the description compensates fully by explaining all four parameters: image_path (accepted path forms), alpha_threshold (range, default, effect), mode (values and fallback behavior), and project_root (purpose for resolving URIs). Each parameter gains meaning beyond the bare schema.

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 (inspect) and resource (PNG spritesheet) with the output (frame rectangles). It distinguishes itself from animation-building siblings by saying 'Use this tool before building animations,' but does not explicitly name the alternative tool, so an agent must infer the distinction from context.

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?

Gives a clear context for use: 'before building animations when you need to discover the frame layout of a spritesheet.' It does not explicitly state when not to use this tool or name the sibling it should be used instead of, leaving some inference required.

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

Deploy Server