Skip to main content
Glama

photoshop_list_brush_presets

Retrieve installed Photoshop brush presets to find available brushes; filter names by case-insensitive substring and limit returned results.

Instructions

List installed Photoshop brush presets. Supports optional case-insensitive filtering and a result limit.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of preset names to return
queryNoOptional case-insensitive substring filter

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.8.0-preview.1

TDQS

A3.6/5.0
Behavior3/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. 'List installed' implies a safe read, and it discloses that filtering is case-insensitive substring and that results are capped. It does not state ordering, pagination beyond the limit, or whether the result is names only, which leaves behavioral gaps for a no-annotation tool.

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

Conciseness5/5

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

Two short sentences with zero filler, and the core purpose is front-loaded before the optional behavior. Every clause maps to either the tool's purpose or a parameter.

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

Completeness4/5

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

For a simple two-optional-parameter read tool with full schema coverage and no output schema, the definition covers what is needed to invoke it correctly. The only shortfall is not indicating the shape of the returned list (names vs. objects), which would help without an output schema.

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 both parameters are already documented, including defaults, min/max for limit, and the substring semantics of query. The description only restates those semantics without adding format examples or edge-case behavior, 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?

States a concrete verb and resource ('List installed Photoshop brush presets'), which is unambiguous against siblings like photoshop_list_fonts or photoshop_list_documents. It does not explicitly name an alternative tool or exclusion, but the resource is distinct enough that confusion is unlikely.

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

Usage Guidelines3/5

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

Usage is implied by the verb 'List' and the mention of optional filters, so an agent can infer this is a read/enumeration call. There is no explicit when-to-use vs. when-not guidance, no mention of prerequisites, and no pointer to a sibling for related tasks.

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