Skip to main content
Glama
alisaitteke

Photoshop MCP Server

by alisaitteke
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

photoshop_adjust_vibrance

Create a Vibrance adjustment layer to boost muted colors while protecting skin tones. Adjust vibrance and saturation for safer color enhancement without oversaturating.

Instructions

Create a Vibrance adjustment layer. Vibrance boosts muted colors while protecting skin tones.

Users often say: make colors pop (safely), boost saturation without clown look.

Returns: JSON { ok, summary, details: { layer_name, vibrance, saturation } }. Preconditions: active document. Side effects: adds a Vibrance adjustment layer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vibranceNoVibrance (-100 to 100)
saturationNoSaturation (-100 to 100)
document_idYesPhotoshop document id from photoshop_get_state / photoshop_list_documents. Send null or 0 to use the active document. A positive number activates that document before the tool runs. When no document is open, a stale id does not block the call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.7.33
    • changedInput schema / properties / document_id / description
      Previous value: -"Photoshop document id from photoshop_get_state / photoshop_list_documents. Send null to use the active document. A number activates that document before the tool runs."New value: +"Photoshop document id from photoshop_get_state / photoshop_list_documents. Send null or 0 to use the active document. A positive number activates that document before the tool runs. When no document is open, a stale id does not block the call."
  2. Changed4 schema fields changedv1.7.32
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / document_id / description
      Previous value: -"Optional Photoshop document id from photoshop_get_state / photoshop_list_documents. When set, the tool activates that document before running so a UI tab switch cannot retarget the edit."New value: +"Photoshop document id from photoshop_get_state / photoshop_list_documents. Send null to use the active document. A number activates that document before the tool runs."
    • changedInput schema / properties / document_id / type
      Previous value: -"number"New value: +[
+  "number",
+  "null"
+]
    • addedInput schema / required
      Added value: +[
+  "document_id"
+]
  3. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare this is a non-idempotent write that is not destructive, and the description adds value beyond them: an explicit precondition (active document) and the concrete side effect (adds a layer), which also reinforces the non-idempotent hint. It does not discuss permissions or how repeated calls stack layers, keeping it at a 4.

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 action, then structured into short labeled lines (Returns, Preconditions, Side effects). The informal "Users often say" line is unconventional but earns its place as intent mapping; overall it is tight with little waste.

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 3-param mutation tool with no output schema, the description covers the return shape, precondition, and side effect, matching the complexity well. Only the non-idempotency/stacking behavior of repeated calls goes unstated.

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 vibrance, saturation, and the rich document_id semantics are already fully documented in the schema. The description adds no additional parameter meaning, so the baseline 3 applies.

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 first sentence gives a specific verb + resource ("Create a Vibrance adjustment layer") and adds the semantic distinction from plain saturation ("boosts muted colors while protecting skin tones"). It does not name any sibling such as photoshop_adjust_hue_saturation or photoshop_desaturate, so differentiation is implied rather than explicit.

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

Usage Guidelines4/5

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

The "make colors pop (safely)" / "boost saturation without clown look" line gives clear natural-language context for when this is the right adjustment versus a harsher saturation move. It stops short of naming the alternative tools or an explicit when-not, so it is clear context without exclusions.

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