open_sprite_in_editorOpen a sprite from the user's SpriteForge library in the pixel editor for hand-editing (inline where the app shows interactive cards, otherwise via the returned edit link). Edits save to the edit session, not straight to the library: when the user is done, call save_to_library with the session_id to update the library copy (its previous version is kept in the sprite's history).
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantive behavior beyond annotations: edits go to an edit session rather than the library, save_to_library is required to persist, and the prior version is retained in history. This is exactly the kind of consequence disclosure annotations cannot carry. It stops short of covering failure modes or what the returned edit link contains.
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?
Two tight sentences with the action and delivery mechanism front-loaded, and the critical persistence caveat immediately after. The parenthetical about inline vs. link is slightly dense but earns its place.
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?
No output schema exists, and the description adequately explains what is returned (inline interactive card or an edit link) plus the session lifecycle. The main omission is the origin/format of asset_id, which leaves the agent without guidance on sourcing the sole required argument.
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?
The single parameter asset_id has 0% schema description coverage, and the description never explains what an asset_id is or where to obtain one (e.g., from list_sprites). With low coverage the description should compensate, and it does not.
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?
Specific verb+resource: opens a library sprite in the pixel editor for hand-editing. It distinguishes itself from siblings like get_sprite_from_library (retrieve) and open_full_editor (whole editor) by naming SpriteForge library sprites and the pixel editor.
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?
Clear context for when the tool applies (hand-editing a library sprite) and describes the inline-vs-edit-link delivery. It also gives the follow-up workflow: call save_to_library with session_id when done. It does not explicitly contrast with open_full_editor or get_sprite_from_library, so 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.