Skip to main content
Glama
zhixiaoqiang

Desktop Image Manager MCP Server

by zhixiaoqiang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Desktop Image Manager MCP Server

基于 Model Context Protocol (MCP) 开发的桌面图片管理服务器，提供图片文件统计、查看和压缩功能。

操作示例：

示例图片 https://claude.ai/share/0ffbad1e-502e-4188-b008-0bb966acf06d

Related MCP server: MCP File Operations Server

功能特性

  • 统计桌面图片数量：快速获取桌面上的图片文件总数

  • 获取图片列表：列出桌面上所有图片文件的名称

  • 图片压缩：支持压缩 JPG、PNG、WebP 等格式的图片文件，可自定义压缩质量

实现提示

让 Trae 引用 ./demand.md 进行功能代码生成，简化版如下

... （这里是已经引入的 domain knowledge）

打造一个 MCP 服务器，它能够：
- 功能：
  - 统计当前桌面上的图片文件数量
  - 获取对应文件的名称
  - 支持压缩图片

要求：
- 不需要给出 prompt 和 resource 相关代码。
- 你可以假设我的桌面路径为 /Users/{username}/Desktop

支持的图片格式

  • JPG/JPEG

  • PNG

  • GIF

  • BMP

  • WebP

  • TIFF

  • SVG

环境要求

  • Node.js >= 16

  • pnpm >= 8

安装

# 克隆项目
git clone <repository-url>
cd desktop-image-manager

# 安装依赖
pnpm install

开发

# 启动开发服务器
pnpm dev

构建和运行

# 构建项目
pnpm build

# 运行服务器
pnpm start

调试

# 调试 MCP 服务
pnpm inspector

MCP 工具使用说明

1. 统计桌面图片数量

# 构建项目
pnpm build

# 运行服务器
pnpm start

2. 获取图片列表

// 工具名称: list-desktop-images
// 参数: 无
await client.callTool({
  name: "list-desktop-images"
});

3. 压缩图片

// 工具名称: compress-image
// 参数:
// - fileName: 要压缩的图片文件名
// - quality: 压缩质量 (1-100)，默认 80
// - outputName: 输出文件名（可选）
await client.callTool({
  name: "compress-image",
  arguments: {
    fileName: "example.jpg",
    quality: 75,
    outputName: "example-compressed.jpg"
  }
});

开发

# 启动开发服务器
pnpm dev

安装

使用 Claude Desktop 添加如下配置 config:

MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "desktop-image-manager": {
      "command": "npx",
      "args": [
        "-y",
        "@jzone-mcp/desktop-image-manager-mcp"
      ]
    }
}

注意事项

  1. 确保有足够的桌面访问权限

  2. 大文件压缩可能需要较长时间

  3. 压缩后的文件默认保存在桌面，文件名会添加 "-compressed" 后缀

技术栈

  • TypeScript

  • MCP SDK

  • Sharp (图片处理)

  • fs-extra (文件操作)

  • zod (参数验证)

许可证

MIT License

这个 README 文件包含了项目的主要信息、安装说明、使用方法和注意事项。如果您需要添加或修改任何内容，请告诉我。

Available Tools

3 tools
compress-imageC

压缩图片

ParametersJSON Schema
NameRequiredDescriptionDefault
fileNameYes要压缩的图片文件名
outputNameNo输出文件名 (可选)
qualityNo压缩质量 (1-100)

TDQS

C2.7/5.0
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 ('compress image') but doesn't describe key behaviors like whether the original file is modified or replaced, if a new file is created, error handling, or performance considerations. This leaves significant gaps for a mutation tool.

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

Conciseness5/5

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

The description is extremely concise with just two characters ('压缩图片'), which is front-loaded and wastes no words. For a simple tool, this brevity is efficient, though it may sacrifice clarity. Every element earns its place by directly stating the core function.

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 tool's complexity (a mutation operation with 3 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects, usage context, or output details, leaving the agent with insufficient information to invoke the tool correctly without guesswork.

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%, with clear descriptions for fileName, outputName, and quality parameters. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or constraints. Baseline score of 3 is appropriate since the schema adequately documents parameters.

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

Purpose3/5

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

The description '压缩图片' (compress image) states the basic verb and resource but is vague about scope and implementation details. It doesn't specify what type of compression (e.g., lossy/lossless), supported formats, or how it differs from sibling tools like count-desktop-images and list-desktop-images. The purpose is understandable but lacks specificity and differentiation.

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 or any prerequisites. The description doesn't mention context for usage, such as when compression is needed or what happens to the original file. Without annotations or explicit instructions, the agent must infer usage from the tool name alone.

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

count-desktop-imagesB

统计桌面上的图片文件数量

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
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 what the tool does (counts images) but doesn't describe how it behaves—e.g., whether it's read-only, if it accesses system files, potential errors, or output format. This leaves significant gaps in understanding the tool's operational characteristics.

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 directly states the tool's function with no wasted words. It's front-loaded and appropriately sized for a simple tool with no parameters, making it easy to parse and understand 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?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, or usage context. For a counting tool, this is acceptable but leaves room for improvement in guiding the agent effectively.

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 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for this scenario is 4, as the description appropriately focuses on the tool's purpose without redundant parameter information, though it doesn't add extra 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 with a specific verb ('统计' meaning 'count') and resource ('桌面上的图片文件' meaning 'desktop image files'), making it immediately understandable. However, it doesn't explicitly differentiate from its sibling 'list-desktop-images', which likely lists files rather than counting them, so it misses the highest clarity tier.

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 no guidance on when to use this tool versus alternatives like 'list-desktop-images' or 'compress-image'. It lacks any context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based solely on 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.

list-desktop-imagesB

获取桌面上的图片文件名称列表

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
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 tool retrieves a list of image file names, implying a read-only operation, but doesn't specify whether it requires permissions, how it handles errors, what formats are supported, or if there are rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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 in Chinese that directly states the tool's purpose without any fluff or redundancy. It's front-loaded with the core action and resource, 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?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavior, usage context, or output format. For a basic read operation, this might suffice, but it could benefit from more completeness regarding how the list is structured or returned.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and baseline for 0 parameters is 4. It adds no extra parameter semantics, but that's acceptable here.

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 action ('获取' meaning 'get' or 'retrieve') and resource ('桌面上的图片文件名称列表' meaning 'list of image file names on the desktop'). It's specific about what it returns (file names, not file contents or metadata). However, it doesn't explicitly differentiate from sibling tools like 'count-desktop-images' which might return a count rather than a list.

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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'compress-image' (for processing) or 'count-desktop-images' (for counting), nor does it specify any prerequisites, exclusions, or contextual factors for usage.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedcompress-image
    • First observedcount-desktop-images
    • First observedlist-desktop-images
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: compress-image modifies images, count-desktop-images provides quantitative data, and list-desktop-images provides qualitative data. An agent can easily distinguish between compression, counting, and listing operations.

Naming Consistency4/5

The tools follow a consistent verb_noun pattern (compress-image, count-desktop-images, list-desktop-images), but the use of hyphens instead of underscores is a minor deviation from the typical snake_case convention. The naming is still highly readable and predictable.

Tool Count3/5

With only 3 tools, the server feels thin for a 'Desktop Image Manager' domain, as it lacks operations like viewing, deleting, moving, or converting images. While the tools cover basic tasks, the count is borderline low for managing desktop images comprehensively.

Completeness2/5

There are significant gaps in the tool surface for image management: no tools for viewing images, deleting files, moving/organizing images, converting formats, or editing metadata. The server only covers compression, counting, and listing, which is insufficient for full lifecycle management of desktop images.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Filesystem MCP Server

    bsmi021
    A
    license
    Not graded
    quality
    F
    maintenance
    A Model Context Protocol server that provides file system operations, analysis, and manipulation capabilities through a standardized tool interface.
    6
    MIT

  • MCP File Operations Server

    Kavishankarks
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables Claude Desktop to perform file operations like reading, writing, listing directories, and managing files through natural language commands.
    MIT

  • Enhanced File Operations MCP

    SkippyzNJiff
    F
    license
    Not graded
    quality
    C
    maintenance
    A comprehensive Model Context Protocol server that provides over 50 file and system management tools for AI models, including navigation, file operations, search, compression, and system information capabilities.
    -

  • Windows-MCP

    emilioejus
    A
    license
    B
    quality
    D
    maintenance
    An MCP server designed for managing files and folders specifically on the Windows Desktop. It enables users to perform file operations like deletion while implementing security measures to prevent path traversal outside the Desktop directory.
    1
    MIT