Skip to main content
Glama

manage_filters

Destructive

Manage the filter stack: op list | set_visibility | delete. list returns every filter on the photo (layers inside groups included), top of the stack first; it is the way to check what add_adjustment and add_effect produced and to find a filter's id for a re-edit. set_visibility switches one filter on or off without deleting it. delete permanently removes it (there is no undo). There is no apply op (creating or re-editing a filter is the job of add_adjustment and add_effect) and no reorder: delete and re-create the filters in the order you want.

Input Schema

NameRequiredDescriptionDefault
opYes'list' returns every filter on the image (including filters on layers inside groups), top of stack first, with layer/layer_id (which layer the filter lives on, and that layer's id), id/name/type/visible/mask/source and params. source "editmamei" = exact ledger record, with params in add_adjustment's own field names and units, so they can be passed straight back on a re-edit. source "readback" = a filter made outside Editmamei: it is listed as type "other" without its settings, and cannot be re-edited. 'set_visibility' toggles one filter without deleting it. 'delete' removes one. There is no 'reorder' — the editor has no API for it; delete and re-create the filters in the desired order instead.
imageYesImage id, as returned by open_photo.
visibleNoRequired for set_visibility.
filter_idNoRequired for set_visibility / delete.

Output Schema

NameRequiredDescriptionDefault
nameNo
deletedNo
filtersNo
visibleNo
filter_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / op / description
      Previous value: -"'list' returns every filter on the image (including filters on layers inside groups), top of stack first, with layer/layer_id (which layer the filter lives on, and that layer's id), id/name/operation/visible/mask/source and params. source \"editmamei\" = exact ledger record, with params in add_adjustment's own field names and units, so they can be passed straight back on a re-edit. source \"readback\" = a filter Editmamei did not create; its params are raw property names and units (not add_adjustment fields), lossy for per-channel curves after a reload, and such a filter cannot be re-edited. 'set_visibility' toggles one filter without deleting it. 'delete' removes one. There is no 'reorder' — the editor has no API for it; delete and re-create the filters in the desired order instead."New value: +"'list' returns every filter on the image (including filters on layers inside groups), top of stack first, with layer/layer_id (which layer the filter lives on, and that layer's id), id/name/type/visible/mask/source and params. source \"editmamei\" = exact ledger record, with params in add_adjustment's own field names and units, so they can be passed straight back on a re-edit. source \"readback\" = a filter made outside Editmamei: it is listed as type \"other\" without its settings, and cannot be re-edited. 'set_visibility' toggles one filter without deleting it. 'delete' removes one. There is no 'reorder' — the editor has no API for it; delete and re-create the filters in the desired order instead."
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so safety is partly covered. The description adds valuable specifics beyond that: delete is permanent with 'no undo', set_visibility is non-destructive, and no reorder API exists. Slightly redundant with the destructive hint but adds real operational context.

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?

Front-loaded with the op enumeration, then usage and constraints in logical order; every sentence carries information. Some minor overlap with the schema's op description (layer inclusion, no reorder), which is the only reason it isn't a 5.

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

Completeness5/5

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

An output schema exists, so return formats need not be explained, and the description still covers all three ops, their side effects, and the absence of apply/reorder. Complete for a multi-op mutation tool.

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 description coverage is 100%, so the schema already documents op, image, visible, and filter_id plus the editmamei/readback source semantics. The description largely restates op behavior already in the enum description, so the baseline 3 is appropriate.

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

Purpose5/5

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

Opens with a specific verb+resource plus an enumerated op list ('Manage the filter stack: op list | set_visibility | delete'), and explicitly distinguishes itself from siblings add_adjustment/add_effect for creation/editing. An agent can tell what this tool does without opening the schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use: 'list' is the way to check what add_adjustment/add_effect produced and to find a filter's id for re-edit; set_visibility vs delete are contrasted by reversibility. It also names the alternatives for the absent operations ('no apply... no reorder: delete and re-create').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources