Image toolkit: resize, compress, crop, watermark, convert, rotate, EXIF read/strip.
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.
Average 4/5 across 8 of 8 tools scored.
Most tools are clearly distinct, but img_compress and img_convert both support format changes, and img_info and img_exif both read metadata, creating minor overlap. The descriptions help clarify the primary purposes, so ambiguity is low.
All tools share the img_ prefix and mostly use verb-based names like img_compress and img_resize. However, img_info and img_exif are noun-based, which is a slight deviation from the pattern, though still predictable and readable.
With 8 tools, the server is well-scoped for an image toolbox. Each tool addresses a common operation without unnecessary additions, making the count appropriate for the stated purpose.
The toolset covers the core image lifecycle: inspecting info, reading EXIF, compressing, converting, resizing, cropping, rotating, and watermarking. There are no glaring gaps for a practical image toolbox, so agents can handle typical workflows end-to-end.
img_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 二选一） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses per-call credit cost, output stored in a file transfer station with a download URL, and automatic refund on failure—valuable operational facts beyond the basic action. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the purpose, then mention cost, output, and failure handling. No wasted words; each clause adds distinct 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 5-parameter tool with no output schema, the description provides key context: output is a download URL, there is a credit charge, and failures auto-refund. It does not explicitly mention the required input method, but the schema covers that, making the overall description adequate.
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 the baseline is 3. The description adds no parameter-specific semantics, but the schema already fully explains each parameter, including defaults and mutual exclusivity.
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 compresses images and optionally converts format, naming the resource (image) and the verb (compress). It distinguishes from format-only conversion by emphasizing compression as primary, though it does not explicitly name sibling tools.
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 (when compression with optional format change is needed) and provides cost/output context, but it does not explicitly state when to use this tool versus alternatives like img_convert or img_resize, nor any exclusions.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds useful behavioral context: the output is stored in a file transfer station and a download URL is returned, and each call costs 1 credit. This is beyond what the schema provides, though it does not disclose all side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose and includes essential behavioral details. There is no redundant 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 no output schema and no annotations, the description effectively communicates the output behavior (download URL) and cost. It is complete enough for a relatively simple tool, especially with schema covering parameter constraints.
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 descriptions cover all parameters (100% coverage), so the baseline is 3. The description does not add parameter-specific details beyond what the schema already states, except clarifying the credit cost which is not parameter-related.
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 performs image format conversion among png/jpeg/webp. It is distinct from sibling tools like img_compress or img_resize, as it specifically targets format conversion.
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 should be used when format conversion is needed, but it does not explicitly mention alternatives or when-not-to-use. The context is clear but relies on inference from the purpose.
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 二选一） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the credit cost, that output is stored in a file transfer station returning a download URL, and that failed operations auto-refund. These are meaningful behavioral details beyond the basic crop action, though it does not describe side effects or error cases in depth.
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 three concise sentences, each providing essential information: the action, the prerequisite step, and the output/refund behavior. It is front-loaded and contains no redundant 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?
For a tool with 8 parameters and no output schema, the description covers the key workflow: check size first, perform crop, receive URL, and get refund on failure. It does not explain the return format in detail, but the output URL is mentioned. Overall it is complete enough for most use cases.
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%, providing detailed meaning for every parameter (e.g., left/top as starting point, width/height with auto-convergence). The description itself adds no additional parameter-specific context, so a baseline 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 clearly states the tool performs rectangular cropping on images (矩形裁剪图片), using a specific verb and resource. It distinguishes itself from sibling tools like img_resize, img_rotate, and img_compress by specifying the action and workflow.
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?
It gives explicit guidance to first use img_info to check dimensions before setting coordinates, which is a practical workflow tip. It also mentions cost (1 credit) and output URL, but does not explicitly state when not to use this tool or alternatives for cropping scenarios.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the strip behavior and that it outputs a clean version without modifying the original, adding behavioral context beyond a simple read operation. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the core purpose, using a single sentence with a semicolon to add the strip behavior. 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?
The tool has 4 parameters and no output schema, so the description should explain return values. It does not specify the format of the EXIF metadata output, though it covers the strip behavior. This gap prevents a higher score.
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 meaning for the strip parameter by explaining its purpose, but does not elaborate on file_id or data_base64 beyond what the schema already provides.
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 reads image EXIF metadata and optionally strips it for privacy, using a specific verb and resource. It distinguishes from sibling tools like img_info by focusing on EXIF and the strip feature.
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 provides clear context on using the strip option for privacy-safe output, implying when to use this tool for EXIF tasks. However, it does not explicitly contrast with alternatives like img_info, so it lacks exclusions.
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 二选一） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful behavioral context: the tool is free (0 credit) and lists the output contents (format/size/EXIF summary). However, it does not disclose behavior on invalid input, confirm it is read-only, or clarify that only a partial EXIF summary is returned rather than full EXIF data.
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 with zero waste. The first sentence front-loads the core purpose and cost; the second delivers actionable usage guidance. Every sentence earns its place.
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 simple read-only inspection tool with 100% schema coverage and no output schema, the description is nearly complete: it states what fields are returned, that it is free, and when to call it. The main gap is not clarifying the relationship to the img_exif sibling tool, which could leave the agent unsure which to invoke for EXIF needs.
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% — both file_id and data_base64 have clear descriptions including the mutual-exclusivity rule ('二选一'). Since the schema does the heavy lifting and the tool description adds no extra parameter semantics, the baseline score of 3 applies.
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 uses a specific verb (查看/view) with a clear resource (图片元信息/image metadata) and enumerates exact fields returned (format, dimensions, color mode, transparency, file size, EXIF summary). However, it does not differentiate from the sibling tool img_exif, which likely overlaps on the EXIF portion, so it falls short of a full 5.
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 second sentence gives explicit context: 'Call it before processing to see image dimensions and format, then decide resize/compress/crop parameters.' This clearly communicates when to use the tool, but it does not provide exclusions or name alternatives (e.g., when to use img_exif instead), so it misses the full 5 criteria.
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 拉伸(两者都要给) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It notably adds the per-use credit cost (1 credit), output behavior (stored in file transfer station, returns download URL), and failure handling (auto refund). These details are valuable and not present in 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 extremely concise—two short sentences that deliver the core purpose, cost, output mechanism, and failure policy. Every word adds value, with no redundancy.
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 the essential behavior, return type (URL), and operational caveats (refund on failure). It could mention response structure, but the provided information is sufficient for basic invocation.
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 input schema already describes all 7 parameters with 100% coverage, so the baseline is 3. The description adds only a semantic hint about fit vs. stretch, which relates to keep_aspect and width/height, but does not meaningfully enhance parameter understanding beyond the schema.
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 opens with '缩放图片' (resize image), which clearly states the action and resource. It further specifies '等比 fit 或精确拉伸' (proportional fit or exact stretch), distinguishing it from sibling operations like crop, convert, or rotate.
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 use for image resizing but gives no explicit guidance on when to choose this tool over alternatives such as img_crop or img_compress. There is no mention of exclusions or conditions, leaving usage context implicit.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially carries the transparency burden. It discloses that the result is a download URL and that each use costs 1 credit. However, it doesn't explain failure modes, how angle and flip combine, or any file source prerequisites 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?
A single, front-loaded sentence covers the action, the key constraint, and the cost/output. No unnecessary words, very efficient.
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 five self-described parameters and no output schema, the description covers the essential purpose, usage condition, return type, and cost. Missing details about error handling or response structure, but overall adequate for a simple image operation tool in a sibling context.
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 value by explicitly requiring at least one of 'angle' or 'flip', which prevents a no-op call when both use their default values. This goes beyond the schema.
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 rotates or mirror-flips images, using the specific verb '旋转/镜像翻转' and the resource '图片'. This distinguishes it from sibling image tools like img_resize or img_crop.
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 provides a key usage constraint ('angle 与 flip 至少给一个'), but does not explicitly compare with alternative sibling tools or state when not to use it. The purpose itself implies the use case, but no clear exclusions 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.
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 二选一） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full transparency burden. It discloses pricing (1 credit/call), output storage and URL return, failure refund policy, and a font-system prerequisite for Chinese text. It does not mention whether the source image is modified or if the returned URL expires, but the key side effects are covered.
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?
A single compact sentence conveys purpose, cost, font requirement, output mechanism, and failure handling. Every clause earns its place and nothing redundantly repeats schema content.
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 and annotations, the description provides the essential contract: what the tool does, how output is delivered (download URL), cost, and failure refund. It could explicitly restate the file_id/data_base64 either-or requirement, but the schema already documents that, so the description is adequate for a 9-parameter 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by noting that Chinese watermark text does not require system fonts, which removes a practical concern for the required 'text' parameter. All parameter details are otherwise fully documented in the schema.
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 opens with '给图片加文字水印' (add text watermark to image), a specific verb+resource phrase that unambiguously identifies the tool's function. This distinguishes it clearly from sibling image tools like img_compress, img_convert, and img_crop.
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 does not explicitly contrast this tool with alternatives or state when to prefer it. It does offer operational context—Chinese watermarks don't need system fonts, output goes to a transfer station, and failures auto-refund—but the usage scenario is only implied by the purpose.
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.
No comments yet. Be the first to start the discussion!