photoshop-mcp-pro

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there are clear overlaps: ps_export and ps_save_document both save files with overlapping formats, and ps_place_image and ps_smart_object's 'place-file' action both place external images as smart objects. This could cause an agent to misselect.
Naming Consistency3/5
All tools start with 'ps_', but naming conventions vary: many use verb_noun (e.g., ps_create_document), but some are single verbs (ps_batch, ps_resize) or nouns (ps_color, ps_history, ps_mask). This inconsistency makes the set less predictable.
Tool Count3/5
At 32 tools, the set is on the high side for an MCP server. While Photoshop is complex and many tools are justified, several tools overlap (e.g., export/save), suggesting some could be consolidated. The count feels slightly bloated.
Completeness4/5
The tool set covers a wide range of Photoshop operations: document creation, layers, adjustments, filters, text, shapes, selections, masks, guides, transforms, smart objects, color, palettes, typography, history, and export. Missing features like channels or actions are minor, and ps_execute_script acts as an escape hatch.
Average 4.1/5 across 32 of 32 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. Description adds no extra behavioral context like impact on selection or undo stack.
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 concise sentences. No redundant information.
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?
Adequate for a simple creation tool with three parameters and no output schema. Could mention it affects the active document, which is implied.
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 baseline is 3. Description briefly adds context for the 'below' parameter but does not deepen understanding beyond the schema.
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?
Description clearly states it creates a new layer or group in the active document with optional positioning. This distinguishes it from sibling tools like ps_reorder_layer or ps_set_layer_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as ps_reorder_layer or ps_manage_layers. The description does not mention prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive. The description reinforces that the tool applies a transform, which is a mutation. It does not disclose any additional behavioral traits (e.g., side effects, auth requirements) beyond what annotations provide, so it meets the basic bar but adds no extra transparency.
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?
The description is two sentences with zero wasted words. It lists the supported actions succinctly and gives a clear instruction about parameter usage. Front-loaded with purpose and actions, it achieves high information density.
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?
The description explains the tool's capability to combine multiple transforms in one place, which is helpful. No output schema exists, but the description does not elaborate on return values. For a simple transform tool that likely returns nothing or a success indication, this is adequate. It could mention that the layer is modified in place.
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% with clear descriptions for each parameter. The description adds a note about supplying only relevant parameters, which is a usage hint rather than semantic enrichment. It does not meaningfully expand understanding of parameter values or constraints beyond the schema, warranting a baseline of 3.
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 description clearly states that the tool applies transforms to layers and lists supported actions (move, scale, rotate, etc.). It identifies the resource (layer) and the verb (applies transform). However, it does not explicitly differentiate itself from sibling tools like ps_align or ps_resize, which could be confused for specific transform actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to 'supply only the parameters relevant to your action,' which provides some usage guidance. However, it lacks explicit when-to-use or when-not-to-use context, and no alternatives are mentioned. The agent must infer usage from the list of actions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds behavioral context: "convert" is for non-destructive editing. This provides value beyond annotations, though side effects or prerequisites are not fully covered.
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?
The description is concise, two sentences, and front-loaded with the main purpose. It could be better structured (e.g., bullet points) but is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not explain return values or side effects. It omits prerequisites like requiring an open document or active layer, making it incomplete for a mutation tool with many siblings.
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% with clear descriptions for all parameters. The description mentions the filePath parameter's requirement for 'place-file' but does not add significant new information beyond the schema.
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?
The description clearly states the tool manages Smart Objects and provides specific actions: "convert" for active layer to Smart Object and "place-file" for embedding external files. This differentiates it from sibling tools like ps_place_image.
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?
The description implies when to use each action but does not provide explicit guidance on when not to use this tool or alternatives. No comparison with sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-destructive write (readOnlyHint=false, destructiveHint=false). The description confirms it creates a new shape layer, adding context that it does not modify existing layers. No further behavioral details (e.g., layer placement, undo impact) are provided.
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 sentences, front-loaded with the core action and resource. Every word adds value; no redundancy.
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?
Given the complex nested schema and no output schema, the description adequately covers the purpose and param usage. It could mention that the shape is created on a new shape layer or return nothing, but overall it is sufficient for an AI agent to invoke correctly.
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% with detailed parameter descriptions. The description adds high-level grouping ('type and its specific params') but does not elaborate on individual fields beyond what the schema already provides.
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?
The description uses specific verbs ('Draws') and resources ('vector shape on a new shape layer'), lists all supported shape types, and clearly differentiates from sibling tools like ps_create_text or ps_place_image by focusing on vector shapes.
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?
The description states when to use (draw a vector shape) and instructs to supply type and params, but does not explicitly guide when not to use or contrast with alternatives like ps_create_layer for arbitrary layers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description details each action's effect. However, it does not disclose side effects such as the permanent nature of 'remove-all' or requirements for undo. The potential destructiveness of 'remove-all' contradicts the destructiveHint=false annotation, but the description itself does not flag it.
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?
The description is two sentences long, front-loaded with the main purpose, and lists each action succinctly. No redundant phrasing, every sentence carries meaning.
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?
Given the absence of an output schema, the description covers the main use cases (add, add-grid, remove-all, get) but does not explain return format for 'get' or handle potential errors. It is sufficient for basic understanding but could be more thorough for complex workflows.
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?
With 100% schema coverage, the description adds little extra parameter meaning. It restates what each action does but does not clarify parameter constraints, units, or relationships beyond what the schema already provides.
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?
The description clearly states the tool manages document guides and lists all supported actions (add, add-grid, remove-all, get). It distinguishes itself from sibling tools like ps_create_document or ps_align by focusing exclusively on guide operations.
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?
The description explains the available actions but does not provide guidance on when to use this tool versus alternatives (e.g., when to use ps_guide instead of ps_create_document to add guides). No explicit when-not-to-use or feature comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds context about JPEG quality range, but lacks details on overwrite behavior or permissions needed.
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 sentences with no extraneous information, directly stating the purpose, supported formats, and the quality parameter detail.
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 save operation, the description is mostly complete given the schema coverage. It does not explain return values or error handling, but these are often implicit for save actions.
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 the baseline is 3. The description adds marginal value by explaining that quality ranges from 1 (lowest) to 12 (highest), but this is already implicit in the schema's numeric range.
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?
The description clearly states the verb 'saves' and the resource 'active document', and specifies supported formats (PSD, JPEG, PNG), distinguishing it from siblings like ps_export.
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?
The description implies when to use the tool (to save the active document) but does not provide explicit guidance on when not to use it or mention alternatives like ps_export, which may have overlapping functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true. The description adds that results are returned as a combined array and operations execute in sequence. However, it lacks details on error handling (e.g., atomicity, rollback), which is important for a destructive batch 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?
The description is three sentences with no fluff: states purpose, explains structure, and gives usage guidance. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the batch tool's complexity and destructive hint, the description covers basics (purpose, usage, structure) but omits critical context like failure behavior, result format per operation, and prerequisites. Leaves gaps for a high-stakes 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 coverage is 100%, so the description adds no new parameter details beyond the schema. It mentions 'each operation specifies a tool name and its arguments,' which is redundant with the schema's 'ordered list of {tool, args} operations to execute.' Baseline 3 applies.
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?
The description clearly states the tool 'Executes multiple tool operations in sequence within a single call,' with a specific verb and resource. It distinguishes itself from sibling tools (individual operations) by being a batch wrapper.
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 description explicitly advises 'Use this to chain several steps without round-trips,' providing clear context for when to use the batch tool. It implies alternatives are individual calls, though it doesn't list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive, but the description adds specifics about supported filter types and parameter structure, going beyond annotations.
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?
Single sentence, front-loaded with key action and supported filters, no wasted words.
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?
No output schema, but description covers intended action, supported types, and notes destructiveness. Could optionally mention return behavior.
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 covers 100% of parameters. Description adds instruction to supply type and params but no additional meaning beyond schema.
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?
The description clearly states it applies a destructive filter, lists supported types, and distinguishes from siblings that perform adjustments, alignments, etc.
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?
The description mentions destructive nature but does not explicitly compare to alternatives or specify when to use vs not use. Adequate but could be improved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the description adds context about full typographic control in a single call. It does not describe side effects like layer ordering or selection changes, but the safety profile is adequately covered by annotations.
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?
The description is two sentences long, with the first sentence front-loading the purpose and capabilities, and the second sentence providing a clear usage hint. Every sentence earns its place with no wasted words.
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?
Given the complexity of 13 parameters including nested objects and no output schema, the description covers the main purpose and key parameter guidance. It does not mention return values, but for a creation tool, the return is often implicit (e.g., layer ID), so it is nearly complete.
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 baseline is 3. The description adds value by summarizing typographic controls and explaining 'type' usage, but it does not add meaning beyond what the schema already provides for each parameter.
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?
The description clearly states it creates a text layer with full typographic control, listing specific properties like font, size, color, alignment, tracking, leading, and warp. This is a specific verb+resource that distinguishes it from sibling tools like ps_update_text or ps_typography.
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 description provides explicit guidance on using 'point' vs 'area' types, which is a key usage distinction. However, it does not discuss when to use this tool over alternatives like ps_update_text for modifications, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool modifies a file but does not destroy the original. The description adds that it exports the active document without mentioning further behavioral aspects (e.g., whether the file is overwritten, if any dialog appears). It does not contradict annotations.
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?
The description is extremely concise: two sentences with no redundancy. The first sentence states the core purpose, the second provides key details on formats and requirements. Every sentence earns its place.
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?
Given the tool's simplicity (4 parameters, conditional options, no output schema), the description covers the essentials. However, it lacks information on default behavior for omitted optional parameters, overwrite semantics, or whether the export is at full resolution. Still adequate for a standard export function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 each parameter. The description adds value by summarizing that scale is for PNG only and quality for JPEG only, and stresses that the path must be absolute. This enhances understanding beyond the schema.
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?
The description clearly states the verb 'Exports', resource 'active document', and lists supported formats (PNG, JPEG, PSD, TIFF) with additional options like scaling for PNG and quality for JPEG. It is specific and distinguishes from sibling tools like ps_save_document.
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?
The description instructs to provide an absolute file path and mentions conditional parameters, but it does not explicitly state when to use this tool versus alternatives like ps_save_document or ps_batch. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and readOnlyHint=false, which describe the tool's safety profile. The description adds that undo steps backward, redo steps forward, and get-states returns the list of history states. However, it does not elaborate on edge cases like empty history or failure behavior, but given the annotations, the additional value is moderate.
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?
The description is two sentences long, front-loaded with the core action, and every sentence adds necessary information. No verbose or redundant phrasing.
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?
The tool has low complexity, and the description covers the three actions and the steps parameter. Without an output schema, it explains that get-states returns a list of history states. It could mention return value formats or empty history behavior, but overall it is sufficiently complete for the tool's simplicity.
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%; the description's mention of 'default 1 step' for the steps parameter duplicates the schema's default. It does not add new meaning beyond what the schema provides, so baseline score of 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?
The description clearly states 'Manages document history' and enumerates the three actions (undo, redo, get-states) with verbs that indicate what each does. It uniquely identifies the tool among siblings, as no other sibling tool handles history management.
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 description explicitly guides usage with 'Use undo to recover from mistakes.' It implicitly suggests when to use redo and get-states but does not explicitly state when not to use alternatives, though no direct alternatives exist. Overall, usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is not read-only and not destructive. The description confirms mutation ('sets') and specifies it applies to the active layer. However, it does not detail behavior like what happens if no layer is active, or if multiple properties are set simultaneously, which would improve transparency.
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?
The description is a single sentence that is perfectly concise, front-loaded with the action and parameters, and contains no fluff. Every word earns its place.
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?
Given the tool's low complexity (simple property setters), the combination of the description and rich schema covers the essentials. It lacks return value info (no output schema) and preconditions, but these are not critical for such a straightforward 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 coverage is 100% with all parameters described (opacity 0-100, blendMode enum, fillOpacity 0-100). The description adds no additional semantic meaning beyond what the schema provides, so baseline score of 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?
The description clearly states it sets opacity, blend mode, and/or fill opacity on the active layer, using specific verbs and resource. It distinguishes from previous separate tools, and the sibling 'ps_set_layer_style' likely deals with layer styles, so this tool's focus is unambiguous.
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 description implies usage by consolidating three separate tools, indicating this is the unified tool for these properties. It does not explicitly state when to use vs alternatives like ps_set_layer_style, but the context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only and not destructive, so the description's main addition is that it creates a document. It does not disclose side effects, permissions, or what happens if the document name conflicts, but the basic safety profile is covered by annotations.
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 sentences, each containing essential information. The first sentence states the primary action, the second explains key options. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters including nested objects and no output schema, the description covers main use cases but omits important context like return values (e.g., document ID) and error conditions. Some guidance on behavior when presets override dimensions would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 each parameter. The description adds value by grouping parameters into usage patterns: presets vs custom dimensions, and optional background/guides. This contextualizes the parameters beyond individual descriptions.
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?
The description clearly states the tool creates a new Photoshop document, with specific verbs and resource. It distinguishes between using presets for common sizes or custom dimensions, which sets it apart from sibling creation tools like ps_create_layer or ps_create_design.
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 description provides guidance on when to use presets versus custom dimensions, which is helpful. However, it does not explicitly exclude cases where this tool should not be used or mention alternatives like ps_create_design for templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it mentions the default Smart Object placement and non-destructive editing, which aligns with the non-destructive annotation. It does not describe error handling or behavior for missing files, but overall it reveals key traits.
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?
The description is extremely concise—two sentences that front-load the core action and then add a key detail. Every word earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description covers the main purpose but omits potential error cases (e.g., file not found, unsupported format) and does not specify whether it returns the placed layer. It is adequate but not fully comprehensive.
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% with clear individual parameter descriptions. The tool description adds only a summary statement ('Optionally set position and dimensions'), which provides minimal extra meaning beyond the schema. Thus baseline score of 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?
The description states the specific verb 'places', the resource 'external image file', and the context 'into the active document'. It clearly distinguishes from sibling tools like ps_create_layer (creates empty layer) or ps_smart_object (converts existing layers).
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 description explains the default behavior (placed as Smart Object for non-destructive editing) and option to set position and dimensions, providing clear context for when to use this tool. However, it does not explicitly contrast with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds key behavioral detail beyond annotations: 'omitted effects are left unchanged' ensures idempotent-like behavior. Annotations already indicate non-read-only and non-destructive nature. The description could mention what happens if layer has no style or error conditions, but overall it adds value.
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?
The description is two sentences, front-loaded with the tool's action and a comprehensive list of effects, followed by behavioral context. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and effect preservation, but lacks context about which layer the tool operates on (presumably the selected layer) and what the expected return is (e.g., success status). Given the complexity of Photoshop and no output schema, this is a gap.
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% with detailed parameter descriptions. The description adds the semantic insight that omitting an effect leaves it unchanged, which is not in the schema. This is useful but limited; 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?
The description clearly states it is a tool for setting layer effects, lists all nine supported effects, and contrasts with individual effect tools by saying it replaces them. This makes the purpose distinct and specific.
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?
It explains that any combination of effects can be supplied and omitted ones are left unchanged, providing clear guidance on how to use the tool. However, it does not explicitly state when to use alternative tools like individual effect tools, though it implies they are replaced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that the adjustment layer is non-destructive and placed above the active layer, clarifying the behavioral effect. No contradictions.
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 sentences, front-loaded with the key purpose and non-destructive nature. Every word is meaningful with no fluff.
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?
Given the complexity (9 types, many nested params) and full schema coverage, the description is adequate. It lacks an output description, but for an MCP tool that typically returns a confirmation, this is acceptable.
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% with detailed descriptions for each parameter, so the description's guidance to 'Supply the type and its specific params object' adds minimal extra value. It correctly directs the agent to the schema for full details.
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?
The description uses specific verb 'creates' and resource 'adjustment layer', states it's non-destructive, and lists all nine supported types. It clearly distinguishes from sibling tools like ps_apply_filter which likely applies destructive filters.
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 description explains where the layer is placed ('above the active layer') and lists supported types, but does not explicitly state when to use this tool versus alternatives like direct pixel manipulation or filter tools. The non-destructive nature implies preference for reversible edits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive and non-read-only behavior. The description does not add further behavioral context (e.g., layer position changes, no undo details). It does not contradict annotations.
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 concise sentences with no superfluous information. The core purpose and a key usage tip are front-loaded, making it efficient for an agent to parse.
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 tool with two parameters and no output schema, the description covers the essential functionality. It could mention error handling for missing layers, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by explaining 'relative to document bounds' and that layerName defaults to active layer, clarifying the tool's scope beyond the schema.
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?
The description clearly states the action ('Aligns a layer') and the context ('relative to document bounds'), and lists specific alignment options. This distinguishes it from sibling tools which cover other layer operations.
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 description explicitly guides use by recommending 'center-both to perfectly center a layer, or pick an edge alignment'. It does not specify when not to use or prerequisites, but provides sufficient context for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds that it applies to the active layer, combines multiple styles, and offers mood-based auto-selection. It doesn't detail whether existing styles are overwritten, but overall is fairly transparent given annotations.
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?
The description is two concise sentences: first states the core action, second explains the two usage modes. No wasted words, front-loaded with verb and resource.
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 tool with no output schema and 5 optional parameters, the description covers the primary behavior and parameter relationships. It could mention return value or effect on existing layer styles, but overall is adequate given the tool's simplicity and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds value by explaining the relationship between 'recipe' and 'mood' (choose by name or mood for auto-match), and implies that intensity, color, and angle are overrides. This clarifies usage beyond the schema.
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?
The description clearly states the tool applies a pre-built visual effect recipe to the active layer, with options to choose by name or automatically match a mood. It distinguishes from siblings like ps_apply_filter (single filter) by noting recipes combine multiple styles for polished results.
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?
The description implies usage via 'polished results in one call' and 'active layer', but does not explicitly mention when to avoid this tool or suggest alternatives (e.g., ps_set_layer_style for manual adjustments). No explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is not read-only and not destructive, so the description adds value by noting that it generates and executes one script for the whole composition. This provides efficiency context. However, it does not detail side effects like whether it opens a new document or handles errors.
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?
The description is four sentences, each serving a purpose: stating the action, listing components, explaining execution, and giving use cases. It is front-loaded and contains no unnecessary words.
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?
Given the complexity (nested params, no output schema), the description covers the main function and use cases. It does not address error handling, prerequisites, or return value format, but these are partially clarified by context. Reasonably complete for a high-level 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 coverage is 100% and the schema already describes each parameter with nested properties. The description summarizes the parameter categories but does not add new semantic details beyond what the schema provides.
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?
The description clearly identifies the tool as a high-level workflow that creates an entire design in a single call, specifying preset, background, layers, and guides. It distinguishes itself from siblings like ps_create_layer or ps_create_document by being a composite, all-in-one operation.
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 description mentions ideal use cases (social media posts, thumbnails, print layouts) but does not explicitly state when to prefer this over individual layer creation tools. The guidance is implicit through the 'high-level' and 'single call' phrasing, but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a modifying (readOnlyHint=false) but non-destructive (destructiveHint=false) operation. The description adds behavioral detail about absolute vs relative moves and the optional targetLayer, but does not cover error conditions or reversibility beyond what annotations imply.
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 sentences, no wasted words. The purpose is front-loaded in the first sentence, and the second efficiently explains parameter usage patterns. Every sentence earns its place.
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 reorder tool with full schema coverage and annotations, the description covers the main behavioral aspects and parameter usage. It lacks mention of return value (no output schema) and error handling, but these are minor for the operation complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the semantic difference between absolute (top/bottom) and relative (up/down) positions, and clarifies the role of targetLayer for relative placement. This goes slightly beyond the schema definitions.
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?
The description clearly states the action ('moves a layer') and the resource ('layer stack'). It distinguishes the tool's purpose by specifying the concepts of absolute and relative positioning, setting it apart from sibling tools like ps_manage_layers or ps_set_layer_properties.
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 description provides explicit guidance on when to use each positioning type ('top'/'bottom' vs 'up'/'down') and mentions the optional targetLayer for relative placement. However, it does not exclude alternatives or mention prerequisites like layer existence, so it lacks full decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds context that 'image' resamples (alters pixels) and 'canvas' adds/removes space (potentially destructive when removing). It does not discuss undo, reversibility, or permissions, but the annotations cover the destructive nature.
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?
The description is two sentences, extremely concise, and front-loads the main function. Every word earns its place with no redundancy or fluff.
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?
Given 4 parameters and no output schema, the description covers the core functionality adequately. It explains both modes and the main parameters. Minor omission: no mention of constraints on width/height relative to original size, but that is not critical for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the action parameter's two modes and their effects. For width, height, and resampleMethod, the schema already describes them sufficiently; the description does not add extra detail but is not needed.
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?
The description clearly states the tool resizes either the canvas or the image, using precise verbs ('adds/removes space' vs 'resamples all content'). It distinguishes between the two actions and differentiates from siblings like ps_transform (which performs transformations) and ps_apply_filter (which applies filters).
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 description provides explicit guidance on when to use each action: 'Use "canvas" to change document bounds without scaling, or "image" to scale everything.' However, it does not compare to alternative tools like ps_transform for scaling, leaving some room for improvement in excluding alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the three actions' behaviors: 'suggest' generates pairings, 'install' downloads and installs fonts, and 'auto-size' calculates sizes. It also notes that auto-size reads document dimensions if not provided. Annotations provide readOnlyHint=false and destructiveHint=false, which align with the non-destructive nature of font installation. The description adds context beyond annotations.
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?
The description is three sentences: an introduction followed by a bullet-like list of actions. It is concise, front-loaded, and every sentence provides essential information without redundancy.
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?
The description adequately explains the three actions and their associated parameters. While there is no output schema, the description gives enough context for an agent to select the correct action. Minor gaps include lack of details on return values (e.g., what 'suggest' returns beyond a pairing description).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description groups parameters by action (e.g., 'mood' and 'purpose' for suggest, 'fontName' for install, 'documentWidth'/'documentHeight' for auto-size). This adds semantic context beyond the schema's individual parameter descriptions, helping the agent understand which parameters are relevant for each action.
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?
The description clearly states the tool is for 'font pairing, installation, and size recommendations' and lists three specific actions: suggest, install, auto-size. This distinguishes it from sibling tools like ps_color or ps_apply_filter, which handle different design aspects.
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?
The description implies when to use each action (e.g., 'suggest' for font pairing, 'install' for downloading fonts), but it does not explicitly state when not to use the tool or mention alternative tools. For instance, it could clarify that ps_update_text is for text editing rather than typography setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate not read-only or destructive. Description explains that setting colors and swapping modify state, while sample-pixel reads. It adds context beyond annotations by describing each action's effect. No contradictions.
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?
Description is two sentences, front-loaded with purpose, then lists actions. Every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with multiple actions and no output schema, description does not explain return values (e.g., sample-pixel returns a color object). This is a gap. Otherwise, it covers the core functionality adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds meaning by linking actions to required parameters (color for set-foreground/set-background, x,y for sample-pixel, none for swap). It clarifies which parameters are used when.
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?
Description clearly states it manages foreground and background colors, and lists specific actions. This distinguishes it from sibling tools which handle layers, filters, adjustments, etc. The verb 'manages' plus resource 'colors' is specific.
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?
Description implicitly tells when to use by listing actions: set colors, swap, sample pixel. It does not explicitly state when not to use or suggest alternatives, but the context is clear. No exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds context about what data is returned (dimensions, resolution, etc.), which is useful but not required. No contradictions with annotations.
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?
The description is two sentences with no wasted words, front-loaded with the purpose. Every sentence adds value.
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?
The tool is simple, read-only, with no parameters and no output schema. The description enumerates the returned fields adequately. Given the low complexity and good annotations, no further information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully defines the input. The description does not need to add parameter information, and it doesn't. Baseline 4 per rules.
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?
The description clearly states the tool returns the full state of the active document, listing specific attributes (dimensions, resolution, etc.). It uses a specific verb ('returns') and resource ('active document'), and distinguishes from siblings like ps_get_layers which focuses on layers only.
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 description includes explicit usage guidance: 'Use this to orient yourself before making changes.' This tells the agent when to use this tool. While it doesn't mention when not to use it or alternatives, for a simple read-only getter this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, meaning the tool may modify state but is not destructive. The description uses verbs like 'generate', 'pick', 'extract', and 'return', which suggest read operations, but it doesn't clarify whether the tool modifies the document (e.g., by creating a palette layer) or simply returns data. This omission leaves ambiguity about 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the overall purpose, followed by a bullet-like enumeration of actions. Every word serves a purpose with no fluff or redundancy.
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?
The description covers the core functionality and return types for each action, but lacks mention of prerequisites (e.g., an active document for 'from-image') or error conditions. Given the tool's moderate complexity and lack of output schema, the description is nearly complete but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds valuable context beyond the schema, such as noting that baseColor is 'required for generate', harmony can be omitted for all types, and variant can be omitted for random. This significantly enhances parameter understanding.
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?
The description clearly states the tool's purpose: 'Generate and work with color palettes.' It enumerates four specific actions with concise explanations, distinguishing the tool from siblings like ps_color by its focus on palette generation and extraction.
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 description provides clear context for each action (generate, from-mood, from-image, from-brand), guiding when to use each based on user intent. However, it lacks explicit exclusionary guidance or direct comparison to sibling tools, which would make it more robust.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, meaning the tool modifies state non-destructively. The description confirms this by stating 'Creates or modifies selections' and adds behavioral context such as providing bounds for shapes and color sample for color-range. It does not contradict annotations. However, it does not disclose any potential side effects like requiring an active document or affecting layer visibility.
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?
The description is only two sentences, front-loading the core purpose and then providing specific usage examples. Every sentence adds value without redundancy. It is concise yet covers the main selection types and parameter requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should ideally explain what the tool returns (e.g., confirmation or nothing). It does not mention return values. Additionally, prerequisites like having an active document are not stated. For a tool with six selection types, it covers usage well but misses return and prerequisite information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: it explains that 'params' is type-specific and for rectangle/ellipse provide bounds, for color-range provide sample color and fuzziness. This helps the agent understand how to structure the params object depending on the type, which is not fully detailed in the schema's property descriptions.
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?
The description clearly states the tool's purpose: 'Creates or modifies selections.' It lists specific selection types (all, none, inverse, rectangle, ellipse, color-range) which distinguishes it from sibling tools like ps_mask or ps_align. The verb 'creates or modifies' combined with the resource 'selections' is specific and informative.
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 description explicitly tells when to use each selection type: use 'all' for selecting everything, 'none' to deselect, 'inverse' to invert, and provides guidance for geometric and color-range selections. It does not explicitly state when not to use this tool or mention alternatives, but the sibling tools are clearly different operations, so usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is mutating (readOnlyHint=false) but not destructive. The description confirms it updates properties and adds context about targeting the active layer, which is valuable beyond annotations.
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 sentences, front-loaded with the action and resource, every word earns its place. No fluff.
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?
For a simple tool with 2 parameters and no output schema, the description covers purpose, properties, and usage prerequisite. Complete enough for an agent to invoke correctly.
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 covers both parameters with descriptions; the description essentially repeats the value type info from the schema. With 100% schema coverage, the baseline is 3, and no additional semantic value is added.
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?
The description clearly states the verb 'Updates' and the resource 'single property on the active text layer'. It lists all possible properties and distinguishes from sibling tools like ps_typography by emphasizing the active layer requirement.
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 description explicitly says 'select the text layer first', giving a clear usage prerequisite. It implies when to use (to modify a text property) but does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds value by detailing the return content (names, types, visibility, opacity, blend modes, bounds), which goes beyond the annotations.
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?
The description is a single sentence, very concise, and front-loaded with the main action. No wasted words.
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?
Given no parameters and no output schema, the description is sufficient. It tells what it returns and its purpose. It could mention format details or limitations, but for a simple read tool it's complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema description coverage is 100% (since no params, trivially covered). The baseline for 0 parameters is 4, and the description does not need to add parameter info.
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?
The description clearly states it returns the full layer tree as JSON with specific details (names, types, visibility, etc.). It distinguishes itself from sibling tools like ps_create_layer or ps_manage_layers by focusing on reading the structure.
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 description says 'Use this to understand the document structure before editing,' which implies when to use it. While it does not explicitly state when not to use it or list alternatives, the context of sibling tools makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true; description includes destructive actions like delete and flatten. No contradiction. Adds detail about layer targeting not in annotations.
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 concise sentences, front-loaded with action enumeration and key behavior. Every sentence is valuable with no redundancy.
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?
Given high schema coverage and annotations, description adequately covers multi-action tool. No output schema, but behavior is clear. Some actions (e.g., merge-visible) could benefit from brief definition, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% describes both parameters. Description adds value by noting layerName defaults to active layer, which is absent from schema. Thus adds meaning beyond schema.
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?
Description explicitly states it performs 11 different layer operations, enumerates actions, and distinguishes from sibling tools by consolidating many individual tools into one. Clear verb and resource.
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?
Description provides clear context: targets named or active layer, and states it replaces 10+ tools, implying when to use it. Lacks explicit exclusion scenarios but sufficient given sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description adds context: 'apply' merges the mask (destructive), 'delete' removes it. It explains effects beyond what annotations provide, though it could further detail consequences (e.g., reversibility). No contradiction with annotations.
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?
The description is two sentences: first sentence states purpose, second sentence lists actions. No wasted words, front-loaded with key information. Efficient and clear.
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?
Given the simple parameter (one required enum) and the presence of annotations, the description fully covers the tool's behavior. No missing information for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'action' has an enum with 4 values, and the description explains each one (e.g., 'create' adds a reveal-all mask). The schema only says 'Mask action to perform,' so the description adds significant meaning and covers all enum values.
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?
The description clearly states the tool's purpose: 'Creates or manages layer masks.' It lists specific actions (create, create-from-selection, apply, delete) with brief explanations, distinguishing it from sibling tools that deal with other layer operations.
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?
The description implies usage by listing actions, but it does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or context for choosing among actions are given beyond the basic definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it uses ExtendScript, returns base64 image, document state, and a design analysis score with components. This goes beyond the annotations.
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 sentences with no wasted words. The first sentence packs all key information (action, outputs, components of analysis), and the second provides usage guidance. Front-loaded with the action.
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?
Despite no output schema, the description thoroughly explains return values (base64 image, full document state, design analysis score with four components). It also mentions the mechanism (ExtendScript). For a 0-parameter read-only tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. Baseline is high, and the description fully covers the tool's behavior without needing parameter details.
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?
The description uses a specific verb ('Takes a screenshot') and resource ('current document'), and clearly states the outputs (base64 image, full document state, design analysis score). This distinguishes it from sibling tools like ps_get_document_info or ps_history.
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 description explicitly says 'use it after making changes to verify the result looks correct', providing clear when-to-use guidance. While it doesn't explicitly list when not to use or alternatives, the context is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant context beyond annotations: 'no guardrails', script passed as-is, return value mentioned. Consistent with destructiveHint and openWorldHint.
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?
Extremely concise: three sentences, front-loaded with purpose, includes warning and return info. No wasted words.
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?
Given simple schema (one string, no enums, no output schema, no nested objects), description fully covers purpose, behavior, and risks. Sufficient for agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers parameter with decent description; description adds key detail that script is passed as-is, enhancing understanding of execution model.
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?
Clearly states it runs arbitrary ExtendScript code, explicitly positions it as an escape hatch for tasks other tools cannot do, effectively distinguishing it from sibling tools.
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?
Explicitly warns about no guardrails and using with care, implying use when other tools fail. Lacks explicit when-not-to-use or specific alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![photoshop-mcp-pro MCP server](https://glama.ai/mcp/servers/ayushnagvanshi101098-ship-it/photoshop-mcp-pro/badges/card.svg)](https://glama.ai/mcp/servers/ayushnagvanshi101098-ship-it/photoshop-mcp-pro)

Score Badge

Copy to your README.md:

[![photoshop-mcp-pro MCP server](https://glama.ai/mcp/servers/ayushnagvanshi101098-ship-it/photoshop-mcp-pro/badges/score.svg)](https://glama.ai/mcp/servers/ayushnagvanshi101098-ship-it/photoshop-mcp-pro)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ayushnagvanshi101098-ship-it/photoshop-mcp-pro'

If you have feedback or need assistance with the MCP directory API, please join our Discord server