adobe-com-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool targets a distinct app-specific resource and action. Photoshop and Illustrator tools are cleanly separated by prefixes, and save/export/layer/shape operations are clearly differentiated.
Naming Consistency5/5
All tools follow the same lower_snake_case pattern with an app prefix (ps_ or ai_) followed by a verb and noun. Minor differences like ps_save_as_png vs ai_export_png are still semantically clear and predictable.
Tool Count2/5
With 30 tools, the surface is too large for a single MCP server. The count is inflated by duplicating similar document and export operations across Photoshop and Illustrator, making it heavy to navigate.
Completeness3/5
Core workflows are covered: document creation, saving/exporting, basic shapes, text, layers, and filters. However, there are notable gaps such as no Illustrator open-document tool, no layer inspection, and no transform/alignment operations.
Average 3.6/5 across 30 of 30 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it executes an action, but does not describe the effects on the document, whether it is destructive, reversible, or requires specific state. The agent is left unaware of side effects or the nature of the operation beyond the literal execution.
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, compact sentence that front-loads the purpose first and then clarifies the parameters. There is no wasted wording, and it is immediately clear what the tool does. The structure is exemplary for a simple tool.
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?
Given the absence of an output schema and annotations, the description must fully explain the tool's context. It fails to mention that the action is applied to the active document, whether any prerequisites exist, or what the response/return value is. For a tool that likely mutates the document, this is a significant gap, making the description incomplete for an agent to call it 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?
The schema already describes both parameters fully: 'action' is the action name and 'from' is the optional action set name. The description repeats this information verbatim ('action 为动作名，from 为动作集名') without adding additional meaning or examples. Since schema coverage is 100%, the baseline of 3 applies, and the description adds no value beyond the schema.
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 the tool's purpose: '在 Photoshop 中执行一个已安装的动作（Action）' (execute an installed Action in Photoshop), with specific parameters explained. It distinguishes itself from sibling tools by being the only one that executes actions, though it doesn't explicitly name an alternative. The verb 'execute' and resource 'Action' are specific and unambiguous.
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 is provided on when to use this tool versus alternatives, nor any conditions or prerequisites (e.g., a document must be open, the action must exist). The description only states what it does, leaving the agent to infer usage context. No exclusions or sibling references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining side effects. It says only that the filter is applied to the active layer; it does not disclose that the operation mutates pixel data irreversibly, whether undo is possible, or what happens if no active layer exists. This is a meaningful gap for a mutating graphic operation.
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 short sentences with no filler. The core action and target are front-loaded, and the parameter detail is separated into a tight second sentence.
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 single-parameter, no-output-schema tool this is minimally adequate: the action, target layer, and parameter default are present. However, the absence of output/error expectations and any behavioral warnings leaves an agent without several contextual details it might need in a Photoshop automation flow.
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% and the description repeats the same radius semantics and default value rather than adding new meaning. The schema already documents radius as blur radius in pixels with default 5, so the description provides no additional parameter insight beyond the baseline.
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 the verb and resource: 'apply Gaussian blur filter to current active layer.' It also defines the radius parameter and default. It doesn't explicitly distinguish itself from ps_apply_unsharp_mask, but the filter name and target make the purpose unambiguous.
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 is given on when to use Gaussian blur versus the sibling filter ps_apply_unsharp_mask, nor are prerequisites such as a guaranteed active layer mentioned. The only implicit context is that it operates on the current active layer, so the agent gets no help choosing or preparing for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It says the tool saves the current document as .ai, but does not disclose whether it overwrites an existing file, what happens when path is omitted, or whether the save operation modifies the in-memory document state. This is a meaningful gap for a potentially destructive file-writing operation.
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 compact, front-loaded with the core purpose, and every clause earns its place. There is no redundant text or boilerplate.
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 simple one-parameter tool, the description states the operation and the optional path. However, it does not explain the behavior when path is omitted, such as whether it saves to the current document path or triggers a save dialog. This leaves a minor but real ambiguity for an agent invoking the 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?
The schema already covers the only parameter with a clear description: '保存路径（含 .ai 后缀），可选' (save path with .ai extension, optional). The description merely restates that path is optional and adds no further semantic detail, so the baseline of 3 for high schema coverage 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 a specific action ('save'), a specific resource ('current Illustrator document'), and the target format ('.ai'). It is easily distinguished from sibling export tools like ai_export_svg and ai_export_png, which target other formats.
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 gives no guidance about when to use this tool versus alternatives such as ai_export_svg, ai_export_png, or ps_save_as_psd. It does not mention prerequisites, exclusions, or scenarios where a different save/export path should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose side effects, but it only states the basic creation action. It does not mention where the layer is inserted, that it may become the active/selected layer, or any prerequisites/failure conditions beyond 'current document'.
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 one short sentence that front-loads the core action and target. The only extra phrase duplicates the optionality of the schema, but it is minimal and does not create bloat.
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?
This is a very simple one-parameter tool with no output schema, so the description is mostly adequate for invocation. However, because there are no annotations and no output schema, the description leaves open whether the call returns a layer reference and what positional side effects occur.
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 schema already documents name as an optional string. The description merely repeats 'name 可选' and adds no extra semantics such as naming rules, default naming behavior, or character limits.
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 ('新建' / create) and a precise resource ('空白图层' / blank layer), anchored to '当前 Photoshop 文档' (current Photoshop document). The qualifier 'blank' distinguishes it from siblings such as ps_add_text_layer and ps_duplicate_layer even without naming them.
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?
There is no guidance on when to choose this tool over alternatives like ps_add_text_layer or ps_duplicate_layer. The only contextual cue is 'current document', which implies an open document prerequisite but does not state it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action and that path is optional, but it does not explain what happens when path is omitted, whether an existing file is overwritten, or whether a save dialog is shown. This leaves a significant ambiguity for a save/export operation.
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 one short, front-loaded sentence that conveys the core action and parameter status without redundancy. Every word earns its place.
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 one-parameter export tool, the description is mostly adequate, but the optional path behavior is unexplained. A caller cannot tell whether omitting path triggers a dialog, defaults to a location, or fails, which is a meaningful gap. No output schema exists, but the description still should clarify the default 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 description coverage is 100% and both the schema and description document the 'path' parameter and its optionality. The description adds no extra meaning beyond the schema, such as default save location, required extension behavior, or what omitting the path does, so the 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 the action: export the current Photoshop document as a PNG image. It names the specific verb, resource, and output format, which distinguishes it from sibling tools like ps_save_as_psd and ps_save_as_jpg.
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 is given on when to use this tool instead of ps_save_as_psd, ps_save_as_jpg, or ai_export_png. The phrase 'current Photoshop document' implies the tool applies to Photoshop only, but no exclusions, conditions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有任何 annotations，描述需要承担全部行为透明责任，但它只重述了“设置前景色”并给出 RGB 范围。未说明该操作是否影响活动文档、是否需要已打开的文档、是否有副作用或返回值，对写操作而言信息不足。
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?
描述只有一句话，动词和对象前置，取值范围紧跟其后，没有任何冗余信息，结构简洁有效。
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?
工具复杂度较低，三个参数已被 schema 完整覆盖，基本足以让 Agent 调用；但缺少前置条件、副作用和使用场景的说明，完整程度中等。
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?
input schema 对三个参数 r/g/b 均有说明且覆盖度为 100%，因此基线为 3。描述中重复了 0-255 范围，但未增加 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?
描述包含具体动词“设置”和明确资源“Photoshop 前景色”，并限定为 RGB 及取值范围，职责非常清晰。与列表中的图层、文档、滤镜类兄弟工具能明显区分，Agent 无需打开 schema 即可判断其用途。
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?
描述没有说明何时使用此工具、何时不应使用，也未提供任何替代方案或前置条件。在存在大量 Photoshop 相关兄弟工具的情况下，缺少使用场景的引导。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注解提供，描述必须承担行为披露。描述仅声明“新建文档”和单位，但未说明是否覆盖现有文档、是否自动打开新画板、是否需要设置名称或是否要求宽高为正数等行为细节。对于创建操作，这些信息缺失。
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?
描述仅两句，第一句说明目的，第二句明确单位和参数含义，非常简洁。但第二句略显冗余，因为 schema 已有参数描述，不过并未造成冗长，结构合理。
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?
工具复杂度低（2个参数、无输出 schema），描述提供了单位关键信息，但缺少如默认画板尺寸、是否创建新窗口或行为副作用等上下文。考虑到无注解，描述尚不足以让代理完全安全地操作。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema 描述覆盖 100%，两个参数都有中文说明。描述仅补充“单位为点”，但未增加超出 schema 的含义（如默认值、范围或约束）。基线为 3，描述没有额外价值，因此保持 3。
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?
描述明确说明“在 Illustrator 中新建一个文档”，动词“新建”加资源“文档”，单位也明确。与 ps_create_document 等兄弟工具区分明显，因为前缀 ai_ 表明是 Illustrator 的操作。
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?
描述提到了单位（点）和尺寸参数，但未说明何时使用此工具而非其他创建工具（如 ps_create_document），也未提供负面条件或替代方案。仅有隐含的使用场景，缺乏明确的 when/when-not 指导。
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?
No annotations are provided, so the description carries the behavioral burden. It does add meaning by disclosing the transparent background and the current-document scope. However, it omits what happens when path is omitted, whether existing files are overwritten, and any return or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The essential facts—current document, PNG format, transparent background, and optional path—are stated clearly and front-loaded.
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?
With no output schema and no annotations, the description is thinner than it should be. It does not explain the default export location or filename when path is omitted, and it does not help the agent choose between this tool and sibling export/save tools.
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?
The input schema already covers path, noting that it is optional and should include the .png suffix, which is 100% coverage. The description merely repeats that path is optional and adds no additional parameter-level meaning.
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 exact operation: export the current Illustrator document as a PNG bitmap, and adds the useful detail of a transparent background. This clearly distinguishes it from vector export via ai_export_svg and Photoshop-based PNG export via ps_save_as_png.
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?
There is no guidance about when to use this tool instead of ps_save_as_png, ai_export_svg, or ai_save_as_ai. It only scopes the operation to the current Illustrator document, which is more about purpose than usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action of adding a text layer without mentioning side effects (e.g., that it modifies the open document, whether the new layer becomes active, any requirements like an open document, or error conditions). This is insufficient for a tool with no annotation safety hints.
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 a single concise sentence that clearly states the purpose first, then enumerates parameters. It is efficient with no fluff, though the parameter list could be more structured but is still readable and earns its place.
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 simple tool with 7 parameters and no output schema, the description is adequate but incomplete. It doesn't mention any preconditions (e.g., that a document must be open) or what the tool returns after execution. Given the low complexity, this is a minor gap but still present.
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 description essentially paraphrases the schema's parameter descriptions (e.g., x/y as top-left position, r/g/b as RGB color). It adds no new meaning beyond what the schema already provides, so the baseline 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 the verb 'add' and the resource 'text layer' in the current Photoshop document. It distinguishes from siblings like ps_add_layer (generic layer) and ai_add_text (Illustrator) through the explicit mention of 'text layer' and 'Photoshop 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 usage is implied: it adds a text layer to the current document. However, it doesn't explicitly mention when to use it over alternatives (e.g., ps_add_layer for non-text layers, or ai_add_text in Illustrator). No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the export action and quality range; it does not mention side effects like overwriting an existing file, what happens if no path is provided, whether a document must be open, or any error conditions. This is a significant gap for an operation that writes a file.
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 concise sentence that front-loads the core action and target format, then provides the essential quality constraint. There is no wasted wording or redundant elaboration.
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?
For a file-export tool with no annotations and no output schema, the description is too sparse to be fully actionable. It omits crucial context such as default save behavior when path is omitted, whether existing files are overwritten, and required preconditions like having an active document. The schema covers parameters, but the operational context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both path and quality. The description repeats the quality range and default but adds no meaning beyond the schema; path semantics are left entirely to the schema. 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 states a specific action ('export current Photoshop document') and a specific target format ('as JPG'), which clearly distinguishes it from sibling tools like ps_save_as_png and ps_save_as_psd. An agent can immediately tell what resource is affected and what output is produced.
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 when a JPG export of the current Photoshop document is desired, and the 'current document' qualifier gives some context. However, it does not explicitly mention when not to use it or point to alternatives such as ps_save_as_png or ps_save_as_psd.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state what happens when path is omitted, whether an existing file is overwritten, or whether the operation affects the currently open document. These are material gaps for a save operation.
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 appropriately short for a one-parameter tool and front-loads the core action. The second sentence about path is somewhat redundant with the schema, but overall the structure is efficient and free of clutter.
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 simple save-as tool, the description covers the essential operation and the optional path parameter. However, the undefined default save location when path is omitted and lack of overwrite behavior documentation leave the context incomplete for a mutating operation without annotations or an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the description adds no new meaning. The description merely repeats that path is the optional save path, which the schema already documents; nothing is added 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 states the operation precisely: save the current Photoshop document as PSD format. It identifies the verb, resource, and target format, and the format clearly distinguishes it from sibling save tools like ps_save_as_png and ps_save_as_jpg.
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?
Use is implied from the stated purpose, and it correctly scopes the tool to the current Photoshop document. However, it does not explicitly explain when to choose this over the sibling save formats or mention exclusions, leaving usage guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether an Illustrator document must be active, what happens if path is omitted, whether existing files are overwritten, or how errors are reported.
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, front-loaded sentence that conveys the operation and the optionality of the path without any wasted words. It is appropriately concise for the tool's simplicity.
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 simple one-parameter tool, the description is mostly adequate, but it leaves gaps: no default path behavior when path is omitted, no explicit prerequisite of an active document, and no indication of return or success/failure behavior. Given the absence of annotations and output schema, these gaps prevent a higher score.
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 documents path as an optional export path with .svg suffix. The description only repeats that path is optional, adding no new semantic meaning 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 (export), the resource (current Illustrator document), and the output format (SVG vector). It distinguishes itself from sibling tools like ai_export_png by explicitly naming the SVG format, so an agent can tell them apart.
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 context is implied: use this tool when an SVG export of the current Illustrator document is needed. However, there is no explicit mention of alternatives or when not to use it, such as choosing ai_export_png for raster output or ai_save_as_ai for native format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not explain side effects, error behavior if the path is invalid, or whether an already-open document will be affected.
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 short sentences with no redundant information. It front-loads the core action and then states the input requirement, making it easy to parse quickly.
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 simple one-parameter open operation, the description is mostly adequate, but it lacks guidance on error handling, return behavior, and preconditions. These gaps matter because there is no output schema or annotations to fill them.
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% and the single 'path' parameter is already described as '本地文件完整路径'. The description's '传入文件完整路径' adds no additional semantic detail beyond the schema, so 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 uses a specific verb ('打开' / open), identifies the resource ('本地图片/PSD 文件'), and names the file type. This clearly distinguishes it from sibling tools like ps_create_document and ps_close_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 implies the tool is for opening an existing local file, which differentiates it from create/close operations, but it does not explicitly state when to prefer this tool over alternatives or mention any preconditions such as Photoshop already running.
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?
No annotations are provided, so the description carries the full behavioral burden. It states the core side effect (draws a regular polygon in the current document) and that fill colors are optional, but it does not mention selection behavior, the need for an open document, or failure handling. This is adequate for a simple creation tool but lacks richer behavioral context.
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 short, information-dense sentences with no filler. The action is front-loaded, and each sentence earns its place by covering a distinct aspect: purpose, geometry parameters, and optional fill colors.
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?
For a 7-parameter drawing tool with no output schema and no annotations, the description misses important context: it never warns that x/y/radius are necessary for a meaningful call even though the schema lists zero required parameters. It also omits output/failure behavior and any prerequisite like 'an open document must exist.' This is a significant completeness 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 description coverage is 100%, so the baseline is 3 and the description only needs to add marginal value. It usefully groups fr/fg/fb as fill colors and restates the sides default, but does not clarify that x/y/radius are effectively required despite the schema marking no parameters as required.
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 ('画' / draw), a specific resource ('正多边形' / regular polygon), and scopes it to the current Illustrator document. This clearly distinguishes it from sibling shape tools like ai_add_rectangle and ai_add_ellipse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: use this tool when a polygon needs to be drawn. There is no explicit guidance about when to prefer this over ai_add_rectangle, ai_add_ellipse, or the Photoshop shape tools, and no exclusions or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation and target layer but does not disclose whether the change is destructive, whether it modifies the layer permanently, or what happens if no active layer exists. This is a significant gap for a mutating image tool with no annotation safety hints.
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 one succinct sentence, front-loaded with the action and target, followed by a concise parameter summary. Every word earns its place and there is no redundant filler.
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 low complexity of this tool, the description plus full schema coverage is largely sufficient: it identifies the target layer, the operation, and the parameter meanings/ranges. Minor gaps remain around behavioral side effects and failure conditions, but for a simple parameterized filter the definition is reasonably 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?
The schema already documents all three parameters with descriptions and defaults, so baseline is 3. The description adds meaningful value by specifying the amount range (1-500), which is absent from the schema, and by restating the parameters in a compact form. However, radius and threshold semantics are not expanded beyond the schema's 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 a specific verb ('apply') and resource ('USM sharpening to the current active layer'), which distinguishes it from the sibling ps_apply_gaussian_blur by direction (sharpen vs blur). Although it doesn't name the sibling, the resource and effect are specific enough that an agent would not confuse it with other PS tools.
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 provides context that the tool operates on the current active layer but gives no explicit when-to-use guidance or alternatives. It does not state when sharpening is preferable to blur, nor mention prerequisites or exclusions. This leaves the selection decision mostly to inference from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It states the core create behavior but omits material side effects for a mutation tool: whether the new document becomes the active document, whether it is unsaved, and what the call returns or how success is signaled.
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 compact and well-ordered: purpose first, usage triggers second, parameter notes last. Every sentence earns its place, and there is no filler or redundancy.
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?
Because there is no output schema and no annotations, the description should explain what happens after creation, such as the new document being active, its unsaved state, and the expected return value. That context is missing, which leaves an incomplete picture for chaining with sibling tools like ps_add_layer.
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 schema already documents all three parameters. The description adds useful examples and restates the height-equals-width default, but it does not add deeper parameter semantics 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 leads with a specific action and resource: creating a new Photoshop document at given pixel dimensions. It reinforces this with two concrete natural-language examples, making it easy to distinguish from sibling tools like ai_create_document or ps_resize_document.
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 gives explicit trigger conditions with example user utterances ('当用户说…'), so an agent knows when to invoke it. However, it does not explicitly name alternatives or state when not to use it, which keeps it just below the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not state that the fill overwrites existing layer pixels, that an active layer must exist, or whether the operation is destructive/undoable. It only describes the action and the RGB inputs.
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 compact sentence that front-loads the core operation and scope, followed by a short clause explaining the RGB parameters. There is no redundant or extraneous content.
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 three-parameter fill operation, the description provides the essential context: target (current active layer), scope (full canvas), and color inputs. It lacks explicit statements about overwriting behavior and preconditions, but given the tool's simplicity and the fully documented schema, the description is mostly 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 description coverage is 100%: each parameter (r/g/b) is already documented as '红/绿/蓝 0-255'. The description adds only that r/g/b are RGB values, which is already present in the schema, so it provides no significant additional meaning.
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 a specific action: 'fill the current active layer with the specified color (full canvas fill)'. This clearly identifies the target resource (active layer), the operation (fill), and the scope (entire canvas), distinguishing it from siblings like ps_set_foreground_color and ps_add_text_layer.
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 its intended usage: call it when you want to fill the currently active layer across the full canvas. However, it gives no explicit when-to-use or when-not-to-use guidance, and does not compare itself to alternative tools, so the agent must infer the appropriate context from the name and sibling list.
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?
With no annotations, the description carries the burden of explaining behavior. It clearly states that the active layer's opacity is mutated, but it does not address edge cases like a missing active layer, locked layers, or whether the operation is reversible.
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 one short, front-loaded sentence with no filler or redundant detail. Every word 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?
For a single-parameter setter, the description provides the essential information: what property is changed and the valid value range. However, it omits what happens if no layer is active or whether the change affects group layers, so it is not fully 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 description coverage is 100%, and the single 'opacity' parameter is already documented as an integer from 0-100. The tool description only restates this range and adds the active-layer context, which is behavioral context rather than new parameter-level meaning.
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 names a specific verb ('set'), a precise resource ('current active layer'), and a property ('opacity') with a numeric range. This clearly differentiates it from sibling tools like ps_set_foreground_color and ps_add_text_layer.
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 usage context is provided. The description does not mention when to choose this tool over alternatives, nor does it describe prerequisites such as having an active document or layer.
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?
With no annotations, the description carries the disclosure burden and does state that the tool mutates the current document by drawing an ellipse, with x/y interpreted as top-left coordinates. It does not disclose default fill behavior when fr/fg/fb are omitted, layer placement, or behavior when no document is open, leaving moderate uncertainty.
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?
A single compact sentence front-loads the action and then maps the parameters clearly. There is no filler, and the essential information is easy to scan.
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 core invocation (x/y/w/h plus optional fill) is adequately covered by the schema and description, and there is no output schema requiring return-value explanation. However, missing default behavior for omitted fr/fg/fb and no mention of stroke or active-document errors make it minimally viable rather than 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 description coverage is 100%, so the schema already documents every parameter with units and ranges. The description repeats the x/y top-left, w/h, and fr/fg/fb fill-color roles but adds no new constraints, defaults, or relationships beyond the schema, earning the baseline 3.
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 concrete verb ('draw') with a specific resource ('an ellipse in the current Illustrator document'), and the shape type clearly distinguishes it from sibling tools like ai_add_rectangle, ai_add_polygon, and ai_add_text. It also defines the core parameter mapping in the same sentence.
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 clearly implies when to use this tool: when an ellipse should be drawn in the active Illustrator document. However, it does not explicitly state when not to use it or name alternatives, so the routing guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits on its own. It only reveals that text will be added; it does not mention prerequisites like requiring an open document, mutation side effects, response behavior, or what happens if no document is active. This falls short of the behavioral burden.
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 efficient sentence that front-loads the operation and then compactly maps parameters to concepts. There is no filler or repetition of schema content.
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 simple tool and complete schema, the description covers the essential operation. However, it omits the prerequisite of an active Illustrator document and does not explain default color behavior when optional fr/fg/fb are absent. These are minor but relevant gaps for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter, including defaults and optionality. The description simply restates the parameter-to-meaning mapping without adding new semantic nuance, earning the baseline 3.
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 a specific action ('添加文字') on a specific resource ('当前 Illustrator 文档'), which clearly distinguishes it from the Photoshop text tool sibling and from shape-adding Illustrator tools. It also names the focus in the first sentence.
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 phrase '当前 Illustrator 文档' provides clear context for when to use this tool: when text must be added to an active Illustrator document. It does not explicitly state exclusions or alternatives, such as 'use ps_add_text_layer for Photoshop', but the context is clear enough for routine selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but it only states the action and target. It does not disclose that deletion is irreversible, what happens if no layer is active, or whether it changes the active layer afterward.
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 short sentence that states the operation directly with no filler. It is as concise as possible while remaining meaningful.
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 zero-parameter tool this is minimally viable: an agent knows what to invoke and on what target. Still, with no output schema and no annotations, a mention of destructive/irreversible behavior or failure conditions would make it more 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?
The tool has no parameters, and schema coverage is 100% for the empty parameter set, so the description need not document any arguments. Per the 0-parameter baseline, this 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, 'Delete the current active layer,' names a specific verb (delete) and resource (current active layer). It is unambiguous and clearly distinct from sibling tools such as ps_add_layer and ps_duplicate_layer, so an agent can identify this as the removal operation.
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 its use case: when the active layer needs to be deleted. However, it does not explicitly state when to prefer it over alternatives, nor does it provide exclusions or prerequisites, so guidance is only implied.
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?
No annotations are provided, so the description carries the behavioral disclosure burden. It conveys that the operation is a read-only listing scoped to currently open documents, but it does not mention output format, ordering, or behavior when no documents are open. This is minimally viable but not richly transparent.
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?
A single, front-loaded sentence that fully states the operation and target resource. There is no filler, repetition, or unnecessary 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 zero-parameter listing tool with no output schema, the description provides sufficient context: the user will get document names for all open Illustrator documents. It does not specify the exact return shape, but for this simple query that is a minor gap.
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 description does not need to explain parameter meaning. The baseline of 4 applies since the schema already exhaustively documents the empty parameter set.
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 a specific verb ('列出' / list) and a clear resource: the names of all currently open Illustrator documents. This distinguishes it from the sibling ps_list_documents by explicitly naming Illustrator as the host application.
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 gives no guidance on when to use this tool versus alternatives such as ps_list_documents, and does not mention any prerequisites or conditions. Usage context is only implied by the tool name and the mention of Illustrator.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly implies a read-only, side-effect-free operation by saying '获取信息' (get info), and it lists the exact data returned. However, it does not disclose behavior in edge cases such as no active document, nor does it specify the response format.
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 concise sentence that front-loads the operation and resource, then lists all relevant information fields. Every word adds value and there is no redundant or vague content.
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 zero-parameter getter tool, the description adequately covers what the tool does and what information it returns. It could be slightly more complete by noting the return format or behavior when no document is active, but the core context an agent needs to invoke the tool correctly is present.
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, and with a schema coverage of 100%, there is nothing for the description to clarify about parameter meaning. The baseline of 4 applies because no parameter documentation is 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 specifies the verb '获取' (get), the resource '当前活动文档信息' (current active document info), and enumerates exactly what fields are returned: name, pixel dimensions, resolution, color mode, layer count, and active layer name. It also distinguishes itself from siblings like ps_list_documents and ai_get_active_info by explicitly naming Photoshop and the active document scope.
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 does not provide any guidance on when to use this tool versus alternatives. It does not mention situations where the active document might not exist, nor does it contrast with ps_list_documents or ai_get_active_info. The intended usage is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action ('list document names') without mentioning the output format (e.g., array vs. comma-separated), potential error conditions, or the read-only nature (which is not explicitly stated). The description does not go beyond the bare operation, leaving the agent to guess about return structure.
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, concise sentence that immediately states the action and scope. No filler or redundant wording; it is front-loaded and directly serves the agent's decision-making.
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 (no parameters, no output schema), the description is mostly adequate: it clearly specifies what the tool does. However, it does not explicitly state the return format (e.g., a list of strings), which would be helpful since the output schema is absent. Still, the description is sufficient for a straightforward list tool.
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 the schema confirms an empty object. Per the baseline for zero parameters, the description does not need to elaborate on parameters. It correctly communicates that no arguments are required. The description adds no unnecessary detail, and the schema fully covers this aspect.
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 ('list') and resource ('documents currently open in Photoshop'), clearly distinguishing it from the Illustrator sibling `ai_list_documents`. No ambiguity: the name and description together uniquely identify the target tool.
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 phrase 'currently open in Photoshop' implies the use case (when the agent needs to query open Photoshop documents). However, it does not explicitly mention alternatives or when not to use this tool, such as pointing to `ai_list_documents` for Illustrator. Guidance is implied rather than stated.
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?
With no annotations, the description carries the behavioral burden. It discloses that x/y are bottom-left coordinates in points and that fill RGB is optional, defaulting to no fill. It does not mention return value or effects on selection/layers, but for a simple non-destructive add operation the key call-time behavior is stated.
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?
A single sentence front-loads the action and scope, then packs all seven parameters into a compact mapping with the optional fill behavior. Every clause earns its place; no filler or redundant restatement of the schema.
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 7-parameter shape-creation tool with no annotations or output schema, the description plus the rich input schema covers the rectangle geometry, units, and fill defaults. Gaps such as required-parameter clarification and behavior when no active document exists are minor and inferable from '当前 Illustrator 文档'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description restates the existing parameter meanings and adds minimal grouping ('fr/fg/fb' as optional RGB fill, no fill if absent), but it does not clarify whether x/y/w/h are effectively required despite schema declaring zero required parameters.
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 opens with '在当前 Illustrator 文档中画一个矩形' — a specific verb ('画'), resource ('矩形'), and scope ('当前 Illustrator 文档'). This clearly differentiates the tool from sibling add-shape tools such as ai_add_ellipse and ai_add_text.
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?
Use is implied by the shape and app context: choose this when adding a rectangle to the active Illustrator document. However, it does not explicitly state when to prefer it over ai_add_ellipse/ai_add_polygon or mention prerequisites/error conditions, so the guidance is only implicit.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that a copy is generated from the active layer, which implies the original remains intact, but it does not mention side effects such as the position of the copy, whether it becomes the active layer, or naming behavior.
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 short sentence that contains the essential action, target, and outcome. There is no filler, and the key information is front-loaded.
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 parameters, no output schema, and no annotations, the description adequately communicates the core operation and result. It is slightly light on behavioral side effects, but the simple nature of duplicating a layer makes the description largely sufficient.
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 description cannot add parameter meaning beyond the schema. Per the calibration baseline, 0 params earns a 4.
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 a specific action (复制/duplicate), a clear resource (当前活动图层/current active layer), and the result (生成副本/creates a copy). This distinguishes it from sibling operations like ps_add_layer or ps_delete_layer without any ambiguity.
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?
No explicit when-to-use or when-not-to-use guidance is provided, and no alternatives are mentioned. However, the usage is clearly implied: this tool is for duplicating the currently active layer, which a competent agent can infer from the action and resource.
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?
There are no annotations, so the description must carry the read-only signal; '获取...信息' clearly conveys a retrieval operation with no mutation. It also enumerates the observable outputs, giving the agent a good model of behavior, though it doesn't cover edge cases such as no active document or units for dimensions.
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?
A single compact sentence front-loads the operation and then provides a focused list of return fields. There is no filler, tautology, or redundant restating of the input schema.
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 parameterless getter with no output schema, the description is nearly complete: it tells the agent what to retrieve and what data will be available. It stops short of specifying units, data types, or behavior when no document is open, but these are minor for this level of 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?
With zero parameters, the schema leaves nothing ambiguous and the baseline is 4. The description's list of returned information adds semantic context even though no parameter documentation is 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?
Description uses a concrete verb (获取/get) and a specific resource (当前活动文档信息), and enumerates the exact data returned—name, dimensions, path count, text frame count, and open document count. The mention of Illustrator and 'active document' distinguishes it from siblings like ps_get_active_info and ai_list_documents.
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 phrase 当前活动 implies this tool should be chosen when the AI needs the active Illustrator document's properties rather than a list of all documents, but it never explicitly names alternatives or says when not to use it. The when-to-use guidance is therefore implied rather than stated.
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?
No annotations are provided, so the description carries the transparency burden. It discloses a non-obvious behavior: the missing dimension is automatically computed proportionally. However, it does not state what happens when both dimensions are supplied, whether the operation is destructive or resamples pixels, or any constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the operation and target; no filler or repetition of the schema.
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 two-parameter, no-output-schema tool, it provides sufficient context to invoke correctly: target is the current document, dimensions are in pixels, and one parameter can be omitted for proportional scaling. The notable gap is the unspecified behavior when both parameters are provided.
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 schema already describes both parameters as pixel target widths/heights (100% coverage). The description adds meaning beyond the schema by explaining the relationship: only one is required and the other is derived proportionally.
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 ('调整', adjust) and resource ('当前 Photoshop 文档的像素尺寸', current Photoshop document's pixel dimensions), making the action and target unambiguous. It is clearly distinct from sibling tools like create/open/save/add-layer because it is the only one focused on resizing the active document.
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 identifies the active Photoshop document as the target and states the parameter entry pattern ('give either width or height'), which tells the agent how to invoke it. It does not explicitly name alternatives or exclusions, so it falls just short of a 5.
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?
With no annotations provided, the description carries the behavioral disclosure burden. It explicitly states '不保存' (not saving), which is the key behavioral and potentially destructive trait. It does not mention error behavior or confirmation prompts, but for a zero-parameter close operation the critical warning is present.
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 concise sentence that front-loads the verb and target, then adds the essential no-save behavior in parentheses. Every element is necessary and there is no wasted text.
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 zero-parameter, no-output-schema tool, the description sufficiently covers what action is performed, on which document, and with what saving behavior. It is 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so the baseline is 4. There is no parameter information needed; the description does not add parameter semantics but does not need to.
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 a specific verb ('关闭' / close), a precise resource ('当前活动文档' / current active document), and a defining constraint ('不保存' / not saving). It clearly distinguishes this Illustrator tool from the sibling Photoshop close tool by naming the application and scope.
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: when the goal is to close the active Illustrator document without saving. However, it gives no explicit guidance about alternatives, such as saving first with ai_save_as_ai, or 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?
There are no annotations, so the description must carry the behavioral disclosure burden. It explicitly reveals that the close happens without saving, which warns the agent that unsaved changes may be discarded. It does not elaborate on irreversibility or behavior when no document is active, but for a one-line tool this is a meaningful and mostly sufficient disclosure.
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 entire description is a single short sentence that front-loads the action, target, and the critical no-save qualifier. There is no filler or repetition of the tool name beyond what is natural.
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 zero-parameter tool with no output schema, the description is complete: it names the target document and the side-effect (no save). An agent has enough information to invoke ps_close_document correctly without needing return-value or parameter details.
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 input schema has zero parameters, so there is no parameter ambiguity and the description does not need to add parameter semantics. Per the zero-parameter baseline, a score of 4 is appropriate; the description appropriately ignores parameters entirely.
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 ('关闭' / close), names the exact resource ('Photoshop 当前活动文档' / current active Photoshop document), and states the key qualifier '不保存' (without saving). This clearly differentiates it from sibling tools like ai_close_document and from save-then-close workflows.
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 intended use is implied by the wording: close the current active Photoshop document without saving. However, it never explicitly states when to prefer this over alternatives (e.g., ps_save_as_* followed by ps_close_document) or names any sibling tool, so the routing guidance is left to inference.
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:

[![adobe-com-mcp MCP server](https://glama.ai/mcp/servers/freakyglorian-create/adobe-com-mcp/badges/card.svg)](https://glama.ai/mcp/servers/freakyglorian-create/adobe-com-mcp)

Score Badge

Copy to your README.md:

[![adobe-com-mcp MCP server](https://glama.ai/mcp/servers/freakyglorian-create/adobe-com-mcp/badges/score.svg)](https://glama.ai/mcp/servers/freakyglorian-create/adobe-com-mcp)

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/freakyglorian-create/adobe-com-mcp'

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