Skip to main content
Glama
genart-dev

genart-mcp

by genart-dev

compare_sketches

Captures 2–4 sketches side by side and compares them across composition, color, rhythm, unity, and expression to reveal design differences.

Instructions

Side-by-side capture of 2-4 sketches with a structured comparison framework across specified aspects.

Input Schema

NameRequiredDescriptionDefault
aspectsNoAspects to compare (default: all five)
sketchIdsYesIDs of 2-4 sketches to compare
previewSizeNoMax dimension for inline preview JPEGs (default: 300)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

C2.9/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 burden of behavioral disclosure. It implies a visual capture and comparison but does not state whether the operation is read-only, whether it saves anything, what the return format is, or how the comparison is surfaced.

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 compact sentence and leads with the core visual comparison behavior. It is appropriately sized, though the phrase 'structured comparison framework' is somewhat vague filler.

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

Completeness2/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 no annotations, so the description should explain what the tool returns and how the comparison is presented. It does not, leaving the agent unsure whether to expect an image, structured comparison text, or saved artifact.

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 coverage is 100%, so the schema already documents sketchIds, aspects, and previewSize. The description adds only the 2-4 sketch constraint and the notion of specified aspects, matching rather than extending the schema, so the baseline 3 is appropriate.

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?

The description clearly states a side-by-side comparison of 2-4 sketches across specified aspects, which is specific enough to distinguish it from general preview or screenshot tools. It does not explicitly name relevant siblings such as critique_sketch or preview_sketch, so it falls short of full sibling differentiation.

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?

It describes what the tool does but gives no guidance on when to use it instead of alternatives such as critique_sketch, preview_sketch, or capture_batch. There are no exclusions, prerequisites, or selection conditions.

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