stagenth · 图片工具箱
Server Details
Image toolkit: resize, compress, crop, watermark, convert, rotate, EXIF read/strip.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 5 of 5 tools scored.
Each tool targets a distinct image operation (compress, crop, info, resize, watermark), with clear descriptions that prevent confusion. No overlapping functionality.
All tools follow a consistent 'img_<verb>' pattern, using snake_case with a clear verb indicating the action. No deviations.
Five tools is well-suited for a focused image processing server, covering the most common operations without excess or insufficiency.
Covers core CRUD-like operations: read (img_info), resize, crop, compress, and watermark. Minor gap: no explicit format conversion or rotation tool, but compress handles format change indirectly.
Available Tools
8 toolsimg_compressAInspect
压缩图片、可顺带换格式（1 credit/次）。产物存文件中转站返下载 URL。失败自动退款。
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | 输出格式 png/jpeg/webp；缺省自动（有透明→webp，否则 jpeg） | |
| file_id | No | 已上传的图片 ID（与 data_base64 二选一） | |
| quality | No | 压缩质量 1-95，越低越小；默认 75 | |
| filename | No | 可选输出文件名 | |
| data_base64 | No | 图片内容 base64（与 file_id 二选一） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses credit cost, storage to file transfer station with download URL, and automatic refund on failure. With no annotations, description covers key behavioral traits beyond basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with primary action, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains output as download URL and failure refund, but does not mention the mutual exclusivity of file_id and data_base64 or other input constraints. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters with detailed info. Tool description adds little beyond schema, such as 'can change format', but that's already implied. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'compress images' and optionally change format, distinguishing it from sibling tools for cropping, info, resize, and watermark.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. Implies usage for compression/format change, but lacks when-not or sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
img_convertAInspect
图片格式转换（png/jpeg/webp 互转），产物落文件中转站返下载 URL（1 credit/次）。
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | 目标格式 png / jpeg / webp | |
| file_id | No | 图片文件 ID（与 data_base64 二选一） | |
| quality | No | jpeg/webp 质量 1-100；缺省用推荐值 | |
| filename | No | 输出文件名（可选） | |
| data_base64 | No | 图片内容 base64 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially discloses behavior: it costs 1 credit, and the result is a download URL. However, it does not clearly state whether the tool modifies the original image or is read-only, nor does it mention rate limits, file size limits, or other side effects. The behavior is mostly implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loads the core purpose. However, it could be improved by structuring the cost and output information more clearly, but overall it is efficient and no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does mention the return value (download URL) and cost. For a tool with 5 parameters and no annotations, it is somewhat complete but lacks details on input constraints, file size limits, or error conditions. The description is adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no new information about parameters beyond what the schema provides. For example, it does not explain the choice between file_id and data_base64, or when to use the filename parameter. It adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: format conversion between png/jpeg/webp. It distinguishes from sibling tools (img_compress, img_crop, etc.) by specifying that it converts formats rather than compressing, cropping, or other operations. The output (download URL) and cost (1 credit) are also included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for format conversion, but does not explicitly state when to use it versus alternatives, nor any prerequisites or exclusions. It lacks explicit guidance on when not to use this tool (e.g., if lossless conversion is needed, or if credit cost is a concern).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
img_cropAInspect
矩形裁剪图片（1 credit/次）。先用 img_info 看尺寸再定坐标。产物存文件中转站返下载 URL。失败自动退款。
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | 输出格式 png/jpeg/webp；缺省跟随源格式 | |
| top | Yes | 裁剪起点 Y(px) | |
| left | Yes | 裁剪起点 X(px，左上角为原点) | |
| width | Yes | 裁剪宽(px)，越界自动收敛到图内 | |
| height | Yes | 裁剪高(px) | |
| file_id | No | 已上传的图片 ID（与 data_base64 二选一） | |
| filename | No | 可选输出文件名 | |
| data_base64 | No | 图片内容 base64（与 file_id 二选一） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses cost, storage in file transfer station with download URL, and automatic refund. Does not mention if original is modified or authentication needs, but overall adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and efficient. Each sentence serves a purpose: action+cost, prerequisite, outcome, fallback. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, description covers high-level flow. Could detail output format or how to use download URL, but overall complete for a crop tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. Description adds little beyond schema, only the hint to use img_info, which is helpful but not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (矩形裁剪图片 - rectangular crop image), the resource (图片), and includes cost and prerequisite (先用 img_info 看尺寸再定坐标). It distinguishes from siblings like img_resize and img_compress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use img_info first to check dimensions before setting coordinates. Also mentions cost (1 credit) and automatic refund on failure, providing clear guidance on when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
img_exifAInspect
读取图片 EXIF 元数据（拍摄参数 / 是否含 GPS 定位）；strip=true 时输出抹除元数据的隐私安全版。免费(0)。
| Name | Required | Description | Default |
|---|---|---|---|
| strip | No | true=同时生成去除 EXIF/GPS 元数据的干净图 | |
| file_id | No | 图片文件 ID（与 data_base64 二选一） | |
| filename | No | 输出文件名（strip 时可选） | |
| data_base64 | No | 图片内容 base64 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the strip parameter's effect of removing metadata for privacy, but does not mention read-only behavior, error handling, or any prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and contains no redundant words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool, it lacks output format details (e.g., JSON, text) and does not mention error conditions or return structure, making it somewhat incomplete without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no significant information beyond the parameter descriptions; it does not clarify the mutual exclusivity of file_id and data_base64.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool reads EXIF metadata including shooting parameters and GPS location, distinguishing it from sibling tools which handle image compression, conversion, cropping, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading EXIF data but provides no explicit guidance on when to use this tool over siblings (e.g., img_info for basic attributes) 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.
img_infoAInspect
查看图片元信息：格式/宽高/颜色模式/是否透明/文件大小 + EXIF 摘要。免费(0 credit)。
处理前先调它看清图片尺寸与格式，再决定 resize/compress/crop 参数。
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | No | 已上传到文件中转站的图片 ID（与 data_base64 二选一） | |
| data_base64 | No | 图片内容 base64（与 file_id 二选一） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions it is free (0 credit) but does not disclose any behavioral traits such as auth requirements, rate limits, or whether it is read-only. For a tool with no annotations, the description should add more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences that efficiently convey the tool's purpose and usage guidance. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the metadata fields but does not describe the output format or structure. Since there is no output schema, the description should clarify what the return value looks like. It is adequate for a simple tool but lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described adequately in the schema. The description does not add additional meaning beyond what is already in the schema's parameter descriptions, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly lists all metadata retrieved: format, dimensions, color mode, transparency, file size, and EXIF summary. It clearly distinguishes from sibling tools like resize, compress, crop, and watermark by specifying its role as a metadata inspection tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises calling this tool before other image operations ('处理前先调它') to determine parameters for resize, compress, or crop. It provides clear context but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
img_resizeAInspect
缩放图片（1 credit/次）。等比 fit 或精确拉伸，产物存文件中转站返下载 URL。失败自动退款。
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | 输出格式 png/jpeg/webp；缺省跟随源格式 | |
| width | No | 目标宽(px)；与 height 至少给一个 | |
| height | No | 目标高(px)；与 width 至少给一个 | |
| file_id | No | 已上传的图片 ID（与 data_base64 二选一） | |
| filename | No | 可选输出文件名 | |
| data_base64 | No | 图片内容 base64（与 file_id 二选一） | |
| keep_aspect | No | 等比缩放(默认)。false=按 width×height 拉伸(两者都要给) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses key behaviors: credit consumption, output storage location (file transfer station with download URL), auto-refund on failure, and scaling modes. This provides helpful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates purpose, cost, behavior, and output. No redundant or missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description covers scaling modes, output URL, and refund policy. However, it does not explicitly mention input source options or constraints (though schema does). Mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully described in the schema (100% coverage). The description adds no extra parameter details but sets overall context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resizes images with 'fit' or 'stretch' modes, mentions credit cost, output URL, and refund policy. However, it does not explicitly differentiate from sibling tools like img_crop or img_compress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two scaling modes but provides no guidance on when to use this tool versus alternatives (e.g., when to crop or compress instead). No explicit when-to-use or when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
img_rotateAInspect
旋转 / 镜像翻转图片（angle 与 flip 至少给一个），产物返下载 URL（1 credit/次）。
| Name | Required | Description | Default |
|---|---|---|---|
| flip | No | 翻转：none / h（水平镜像）/ v（垂直镜像） | none |
| angle | No | 顺时针旋转角度：0/90/180/270 | |
| file_id | No | 图片文件 ID（与 data_base64 二选一） | |
| filename | No | 输出文件名（可选） | |
| data_base64 | No | 图片内容 base64 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return of a download URL and the credit cost, but does not specify whether the operation is destructive, error cases (e.g., both params missing), or if both angle and flip can be applied simultaneously.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that conveys the action, prerequisites, and output. Every part is necessary, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately covers what the tool does, required inputs, and output type (download URL) and cost. It could mention more about behavior when both params are provided, but it is sufficient for an agent to understand the tool's core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter description coverage, so the baseline is 3. The description adds value by clarifying the 'at least one' constraint for angle and flip, which is not enforced in the schema (all parameters have defaults). This helps the agent construct valid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'rotate/mirror flip image' and specifies that at least one of angle or flip must be provided. It also indicates that the output is a download URL. This distinguishes it from sibling tools like img_crop, img_resize, etc., which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that at least one of angle or flip is required, and mentions the credit cost. While it doesn't explicitly list alternatives, the sibling tools cover distinct operations, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
img_watermarkAInspect
给图片加文字水印（1 credit/次）。中文水印无需系统字体；产物存文件中转站返下载 URL。失败自动退款。
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | 输出格式 png/jpeg/webp；缺省跟随源格式 | |
| text | Yes | 水印文字（中英文均可，最长 64 字符） | |
| color | No | 文字颜色(#hex 或颜色名)，默认 #888888 | #888888 |
| file_id | No | 已上传的图片 ID（与 data_base64 二选一） | |
| opacity | No | 不透明度 1-100，默认 35 | |
| filename | No | 可选输出文件名 | |
| position | No | 位置：center/top-left/top-right/bottom-left/bottom-right/tile(30°斜排平铺) | bottom-right |
| font_size | No | 字号(px)；缺省按图宽自动 | |
| data_base64 | No | 图片内容 base64（与 file_id 二选一） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: cost per use, output stored with download URL, auto refund on failure, and Chinese text support without system fonts. Does not mention any destructive actions or auth needs, but adequate for a watermark tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of three sentences, front-loaded with purpose and cost, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and no output schema, the description covers purpose, cost, output format, and failure behavior. However, it does not explicitly state that an image must be provided via file_id or data_base64, which is critical. The required parameter is just text, so the source is optional but practically needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds overall context but does not significantly elaborate on individual parameters beyond the schema. The mention of Chinese font support is relevant to the 'text' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a text watermark to images, specifies cost, mentions Chinese font support, describes output via file staging with download URL, and notes auto-refund on failure. It distinguishes from siblings like compress, crop, resize, and info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description only mentions cost but does not compare with sibling tools or provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!