Spiritmarch Aseprite MCP

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

No annotations exist, so the description carries the full burden. It describes the high-level behavior (find, validate, report) and reveals the read-only-looking nature of the tool, but omits details like what happens on failure, whether any files are modified, or what format the capability flags/report take.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: purpose in the first sentence, argument semantics in a structured block. Every sentence adds value; there is no fluff or repetition.

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

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

For a single-optional-parameter diagnostic tool, the description covers the purpose, the parameter, and the mode-select logic. It does not detail the output structure or failure modes, which is a minor gap given there is no output schema and no annotations to backfill the behavior, but overall it is sufficient for correct invocation.

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

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

Schema coverage is 0%, so the description must compensate. It fully explains the only parameter, 'mode', listing both valid values ('full', 'path') and the purpose of the non-default choice. This gives an agent everything it needs to set the parameter correctly.

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

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

Description states precise actions: find, validate version/Lua, report capability flags. This clearly differentiates it from sibling sprite tools (preview, inspect, patch, export, commit) which all handle sprite files rather than the Aseprite environment itself.

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

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

Provides clear context for choosing between modes ('full' default vs 'path' for quick binary check), which is directly actionable for the agent. It stops short of explicitly naming alternatives or exclusion conditions, but the diagnostic purpose makes the intended use obvious in context.

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

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

With no annotations, the description carries the full transparency burden. It discloses key behaviors: writes a .bak on overwrite, restores from that .bak, checks presence of files, and deletes the staging workspace directory. This is substantive and alerts an agent to destructive side effects, even if output/return details are not specified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a summary sentence and then organized by mode in a compact bullet-style list. Each line earns its place with a specific behavior, though adding parameter references would make it even more efficient.

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

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

For a multi-mode tool with four parameterscaster, no annotations, and no output schema, this description is incomplete. It omits which parameters each mode requires, what verify_commit returns, how workspace_id relates to the staging directory, and what happens on missing files or failed rollback. An agent needs more to invoke all modes correctly.

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

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 for all four parameters. It only indirectly explains artifact and destination via commit_single's copy behavior, while workspace_id is never defined, and the required mode parameter's values are only listed informally with no explicit parameter mapping.

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

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

The description states a specific operation class ('Promote staged artifacts to a project path') and enumerates four concrete modes with distinct verbs: copy, restore, check, and delete. This is clear enough to distinguish the tool from the sprite-focused siblings, though it does not explicitly contrast itself with them.

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

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

The mode list effectively serves as usage guidance: commit_single for copying, rollback_single for restoring, verify_commit for checking, and discard_workspace for deleting. It provides clear context for when to invoke each mode, though it does not mention alternatives or exclusions relative to sibling tools.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure. It mentions modes but doesn't explain their effects, output formats, side effects like overwriting, or any requirements. It's too vague to predict tool behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short but under-specified rather than concise. It front-loads the action but omits essential details. The mode list is a hint, not an explanation. Every sentence is minimal but not informative.

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

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

Given the absence of annotations and output schema, this description is severely inadequate. It fails to explain modes, parameter meanings, or the export process. An agent would need to guess or experiment to use it correctly.

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

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. It does not explain any parameter—mode values are listed but not defined, and scale, filename, frame_index, and workspace_id are entirely unaddressed. No compensation at all.

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

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

The description clearly states a specific action (export) and resource (staged artifacts into workspace artifacts folder). The mention of modes (frame/gif/spritesheet) adds specificity and distinguishes it from sibling tools like sprite_preview or sprite_inspect, though it doesn't explicitly name them.

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

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

No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, typical scenarios, or exclusions. An agent has no direction on selecting this over sprite_preview, sprite_patch, or file_commit.

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

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

With no annotations provided, the description carries the behavioral burden itself. It discloses that open 'copies path into a new staging workspace', which is a side effect rather than a pure read, and says what each mode returns. It does not cover permission requirements, failure modes, or whether copies/workspaces persist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a one-line purpose, then organized as a compact bulleted mode list. Every line conveys a distinct operation, prerequisite, or return value with no filler.

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

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

For a multi-mode tool with no output schema and no annotations, the description covers all modes, required parameters, and return types sufficiently to select and invoke the tool. It lacks error-handling and permission details, but those are not essential for basic correct invocation.

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

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

Schema description coverage is 0% and no enums exist, so the description is the only source of parameter meaning. It maps every parameter to a mode: path for open, workspace_id for sprite_info/list_layers, family for operation_list, name for operation_describe, and mode for dispatch. This fully compensates for the bare schema.

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

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

The description opens with a specific verb and resources ('Read sprites, workspaces, and the operation catalog') and then lists six discrete modes with their targets. This clearly differentiates an inspection/listing tool from sibling tools like sprite_patch or sprite_export.

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

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

Each mode is given a clear context and prerequisite: sprite_info and list_layers 'need workspace_id', operation_list has an 'optional family filter', and operation_describe takes 'name='. It does not explicitly state when to avoid this tool in favor of a sibling, so exclusions are missing, but the usage context is otherwise clear.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does state that the tool works on a staged copy (implying non-destructive to the original) and that it validates before applying. However, it omits failure modes, whether operations are applied atomically, reversibility, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two lines plus arg annotations. The core purpose is front-loaded, and every sentence adds information. There is no fluff.

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

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

For a tool that applies an ordered operation list, the description leaves critical details out: what ops are supported, what params each op takes, whether the list is atomic, and what the result looks like. Without an output schema, the description should carry more load, but it doesn't.

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

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. It does: workspace_id is explained as the staging workspace from sprite_inspect mode=open, and operations_json is described as a JSON array of objects each with 'op' and params. This gives actionable structure beyond the bare string type, though the set of valid op values is still unspecified.

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

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

The description states a clear verb-resource pair: validate and apply an ordered operation list to the staged sprite copy. It also references the staging workflow from sprite_inspect mode=open, which differentiates it from sibling tools like sprite_export and sprite_preview.

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

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

The first arg description, 'Staging workspace from sprite_inspect mode=open', gives a clear precondition and workflow context: the tool is meant to be used after sprite_inspect has opened a staging workspace. It doesn't explicitly list exclusions or alternatives, but the staged-copy context implies when it should be used versus other sprite tools.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does disclose a key side effect, 'writes under workspace artifacts', which is valuable. But it does not clarify whether it overwrites existing artifacts, whether the staged state is modified, or what happens on repeated calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one efficient sentence with no filler. The main action is front-loadedhare, and the side-effect warning is neatly contained in a parenthetical.

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

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

The description is too sparse for a tool with no output schema and no annotations. It doesn't say what the tool returns, where exactly artifacts are written, or what 'staged frame' means. An agent is left guessing about the result format and how to locate the preview artifact.

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

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. It does connect 'scaled' to scale, 'frame' to frame_index, and 'workspace' to workspace_id, giving partial context. However, it doesn't explain scaling interpretation, frame indexing, or artifact output details.

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

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

The description clearly identifies a specific action, 'Render a scaled still', a resource ('a staged frame'), and a purpose ('for review'). It is distinguishable from siblings by name and intent, though it does not explicitly contrast with sprite_inspect or sprite_export.

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

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

The phrase 'for review' implies when to use it, and 'scaled still' suggests a lightweight, visual check rather than a full export. However, there is no explicit guidance on when not to use it or which sibling tool should be chosen instead.

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