SpriteMCP

Overview Schema Source Related Servers Discussions Admin

get_view_lock

Retrieve the fixed side-profile view and layering rules, ensuring far objects render behind and near objects in front for consistent depth in pixel art.

Instructions

Permanent view + layering rules (side profile; far behind, near in front).

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

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 25, 2026

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the call is read-only, what it returns, or whether invoking it has any side effects; the word 'Permanent' hints at persistence but leaves the actual behavior opaque.

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 a single concise sentence with no filler, and the core concept is front-loaded. However, it is cryptic and prioritizes brevity over clarity, which slightly reduces its value as a navigation aid.

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?

With no parameters and an output schema present, the tool is trivial to invoke and return-value documentation is not required. Still, the description leaves gaps about the tool's precise purpose and when it should be selected, making it minimally complete but not fully contextualized among related tools.

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?

The tool has zero parameters and the input schema is empty, so the baseline of 4 applies. The description adds no parameter-level detail, but none is required for invocation.

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

Purpose3/5

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

The description 'Permanent view + layering rules (side profile; far behind, near in front)' identifies the resource and explains the concept, and the tool name supplies the 'get' verb. However, it reads as a definition rather than an explicit statement of the operation, such as 'Retrieves the current view lock', and it does not differentiate the tool from siblings like get_draw_order or get_layer_pixels.

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 on when to use this tool versus alternatives. The description does not mention any context, preconditions, or exclusions, nor does it reference the related layering and draw-order tools that an agent might need to distinguish it from.

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