Image header probing, bbox conversion, resize plans and colour maths. 4 of 6 free.
Convert bounding boxes between COCO, Pascal VOC and YOLO. FREE.
The three formats disagree on everything: COCO is [x, y, width, height], VOC is [x1, y1, x2, y2], YOLO is [cx, cy, w, h] normalised to the image. Getting this wrong produces boxes that look plausible and quietly ruin every metric. Typical input {"boxes": [[10, 20, 100, 50]], "from_format": "coco", "to_format": "yolo", "image_width": 640, "image_height": 480} returns {"boxes": [[0.0938, 0.0938, 0.1562, 0.1042]], "converted": 1, "rejected": []}.
Use whenever a dataset and a model disagree about format. Not for scoring predictions (detection_metrics) and not for removing overlaps (nms). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "boxes must contain at least one box"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| clip | No | When true, clamp boxes to the image bounds instead of returning them as they are. Off by default, because a box outside the image is usually a bug worth seeing. | |
| boxes | Yes | Boxes to convert, each a list of exactly four numbers in from_format, e.g. [[10, 20, 100, 50]]. | |
| to_format | Yes | The format to convert to; same three choices. | |
| from_format | Yes | "coco" for [x, y, w, h], "voc" for [x1, y1, x2, y2], or "yolo" for normalised [cx, cy, w, h]. | |
| image_width | No | Pixel width, required whenever yolo is on either side. | |
| image_height | No | Pixel height, required whenever yolo is on either side. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, and the description confirms and augments these with concrete behavioral details: it 'never raises a protocol error' but returns an error object instead, and provides a full typical input/output example. This adds meaningful context beyond the structured 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 compact and front-loaded: purpose first, then formats, example I/O, usage boundaries, error behavior, and idempotence. Every sentence carries distinct useful information with no filler or redundant restatement.
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 conversion tool with full input schema, annotations, and an output schema, the description covers all necessary context: format definitions, coordinate pitfalls, an example transformation, error handling, retry safety, cost, and sibling tool exclusions. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value by explaining the coordinate conventions ('COCO is [x, y, width, height], VOC is [x1, y1, x2, y2], YOLO is [cx, cy, w, h] normalised to the image') and by clarifying when image dimensions are required. The clip parameter's rationale ('a box outside the image is usually a bug worth seeing') also 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 opens with a specific verb and resource: 'Convert bounding boxes between COCO, Pascal VOC and YOLO.' It clearly distinguishes itself from siblings with explicit exclusions: 'Not for scoring predictions (detection_metrics) and not for removing overlaps (nms).'
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 states when to use the tool: 'Use whenever a dataset and a model disagree about format.' It also names alternatives and exclusions, and explains that after correcting errored input it is always safe to retry, giving clear operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a colour pair against the WCAG contrast thresholds. FREE.
Uses the WCAG 2 relative-luminance formula, so the number matches what an accessibility audit will report. Typical input {"foreground": "#767676", "background": "#ffffff"} returns {"contrast_ratio": 4.54, "AA": true, "AAA": false, "required": {"AA": 4.5, "AAA": 7.0}, "verdict": "Passes AA for normal text, fails AAA."}.
Use when generating or auditing an interface. Not for converting colours between spaces and not for palettes. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "foreground must be a hex colour like #767676"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| background | Yes | Background colour in the same notation. | |
| foreground | Yes | Text colour as hex, e.g. "#767676" or "767676" or "#777". | |
| large_text | No | True for text at least 18pt, or 14pt bold, which WCAG allows to pass at a lower ratio. Default false. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds valuable behavioral details: it never raises protocol errors but returns a structured error object, and it explicitly reinforces that every call is read-only and idempotent, making retries safe. It also reveals the underlying WCAG 2 relative-luminance formula, providing transparency about the computation method.
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 structured with clear paragraphs, front-loading the core purpose, then an example, then usage guidance, and error/retry notes. It is slightly verbose but every sentence contributes meaning—no fluff. It uses bullet-like formatting and bold for emphasis, making it scannable.
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 is complete for the tool's complexity. It includes an example output (which is also available via output schema), covers error handling, usage context, and retry safety. Given the output schema exists, there is no need to explain return values further. The tool is simple, and the description addresses all relevant aspects.
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 covers all parameters with 100% coverage, so the baseline is 3. The description adds significant value by providing a concrete example input and output, which clarifies the expected format for foreground and background (hex strings with or without '#'), and implicitly illustrates the large_text parameter via the AA/AAA thresholds. This goes beyond schema basics.
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 function: 'Check a colour pair against the WCAG contrast thresholds.' It specifies the resource (colour pair) and the action (check against WCAG). It also distinguishes from siblings by explicitly saying 'Not for converting colours between spaces and not for palettes.' The example output further clarifies the purpose.
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 explicit guidance: 'Use when generating or auditing an interface. Not for converting colours between spaces and not for palettes.' It also describes error handling behavior and retry safety, giving clear context on when this tool is appropriate. This fully addresses usage scenarios and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score detections against ground truth and show the working. PREMIUM (license).
Greedy matching at the IoU threshold, highest-confidence prediction first, each ground-truth box matched at most once - the standard protocol. Reports per-class precision, recall and F1, and average precision by the all-points interpolation used by Pascal VOC 2010 onward. Typical input {"predictions": [{"box": [0,0,10,10], "label": "cat", "score": 0.9}], "ground_truth": [{"box": [1,1,11,11], "label": "cat"}]} returns {"overall": {"tp": 1, "fp": 0, "fn": 0, "precision": 1.0, "recall": 1.0, "f1": 1.0}, "per_class": {...}, "mAP": 1.0}.
Use to compare two models on the same held-out set. Not for cleaning up a single model's overlapping output first - run nms before this. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "ground_truth must contain at least one box"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| box_format | No | "voc", "coco" or "yolo". Default "voc". | voc |
| image_width | No | Pixel width; required for yolo boxes. | |
| predictions | Yes | Predicted boxes, each {"box": [...], "label": ..., "score": ...}. Score defaults to 1.0 when omitted. | |
| ground_truth | Yes | True boxes, each {"box": [...], "label": ...}. | |
| image_height | No | Pixel height; required for yolo boxes. | |
| iou_threshold | No | Overlap at which a prediction counts as a match. Default 0.5, the usual reporting threshold. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing the matching algorithm (greedy matching at IoU threshold, highest-confidence first, each ground-truth box matched at most once), the interpolation method (all-points interpolation used by Pascal VOC 2010 onward), and the error handling behavior (never raises a protocol error, returns an error object). It also confirms the read-only and idempotent nature, which aligns with the annotations. This adds significant behavioral context beyond what the annotations provide.
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 well-structured and front-loaded. It starts with a clear one-sentence purpose, then explains the algorithm, provides a concrete example, gives usage guidance, and ends with error handling. Every sentence adds value, and the structure is logical. It is concise yet comprehensive, with 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 the tool's complexity (6 parameters, matching algorithm, error handling), the description is remarkably complete. It covers the purpose, algorithm, input format, output format, usage guidance, error behavior, and safety (read-only, idempotent). The output schema exists, so the description doesn't need to explain return values in detail, but it provides a concrete example. This is a fully self-contained description that leaves no major 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?
The schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the typical input format and the default behavior (e.g., score defaults to 1.0 when omitted, iou_threshold default 0.5). It also clarifies the box_format parameter by mentioning the default 'voc' and that image_width/height are required for yolo boxes. However, it doesn't add much beyond what the schema already states, so a 4 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's purpose: 'Score detections against ground truth and show the working.' It specifies the exact operation (scoring detections against ground truth) and the resource (detections and ground truth). It distinguishes itself from siblings by explicitly noting it is not for cleaning up overlapping output (that's nms) and by mentioning the PREMIUM license, which sets it apart from other tools in the set.
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 explicit usage guidance: 'Use to compare two models on the same held-out set. Not for cleaning up a single model's overlapping output first - run nms before this.' This clearly states when to use the tool and when not to, and even names the alternative tool (nms). This is a model example of usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an image's format and pixel size from its header alone. FREE.
Dimensions live in the first few dozen bytes of PNG, JPEG, GIF, BMP and WebP, so a base64 prefix is enough - you do not need to send the whole file, and nothing is decoded. Typical input {"data_base64": "iVBORw0KG..."} returns {"format": "png", "width": 1920, "height": 1080, "aspect_ratio": 1.7778, "aspect_label": "16:9", "megapixels": 2.07, "orientation": "landscape", "bytes_inspected": 512}.
Use to find out what you are dealing with before planning a resize. Not for pixel content - nothing here reads pixels - and not for EXIF. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "data_base64 must not be empty"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| data_base64 | Yes | The image file, base64-encoded. The first few hundred bytes are enough for every supported format; send a prefix rather than a large file. Data-URL prefixes like "data:image/png;base64," are accepted and stripped. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses error behavior: 'never raises a protocol error — it returns {"error": ...}'. It also explains the underlying mechanism ('nothing is decoded', 'bytes_inspected') and retry safety. No contradiction exists with annotations; in fact, the description reinforces them.
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 well structured: a one-line summary, a compact explanation with an example, usage guidance, error behavior, and safety note. Every sentence carries information; there is no fluff or repetition. The length is justified by the richness of the content, and it is front-loaded with the purpose.
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 one parameter, strong annotations, and an output schema, the description is fully complete. It covers input (base64 prefix), output (format, dimensions, derived values), error semantics, limitations (no pixel/EXIF), and retry behavior. There are no unanswered questions an agent would need to resolve before invoking.
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 provides 100% coverage for data_base64, including the prefix strategy and data-URL handling, so the description doesn't need to add much. It does add a concrete example ('{"data_base64": "iVBORw0KG..."}') and restates the prefix guidance in context, which slightly enhances usability without redundancy. A 4 is appropriate given the schema's strength.
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 a specific verb+resource: 'Read an image's format and pixel size from its header alone.' This clearly distinguishes it from sibling tools like resize_plan (planning) and detection_metrics (metrics), and the 'header alone' scoping prevents overreach. The FREE note and supported formats further pin down its exact function.
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 explicitly states when to use: 'Use to find out what you are dealing with before planning a resize.' It also gives clear exclusions: 'Not for pixel content - nothing here reads pixels - and not for EXIF.' This tells the agent precisely when to invoke and when to avoid, and it hints at the resize_plan sibling without needing to name it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove duplicate detections of the same object. PREMIUM (license).
Greedy non-maximum suppression: keep the highest-scoring box, drop everything overlapping it above the threshold, repeat. Ties break on the earlier index, so the result is deterministic rather than dependent on sort stability. Typical input {"boxes": [[0,0,10,10],[1,1,11,11],[50,50,60,60]], "scores": [0.9, 0.8, 0.7]} returns {"keep": [0, 2], "suppressed": [{"index": 1, "by": 0, "iou": 0.6807}], "kept": 2}.
Use after a detector that emits overlapping boxes. Not for scoring against ground truth (detection_metrics) and not for format changes (bbox_convert). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "boxes and scores must be the same length"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| boxes | Yes | Candidate boxes in box_format, e.g. [[0, 0, 10, 10]]. | |
| scores | Yes | One confidence per box, same order and same length as boxes. | |
| box_format | No | "voc", "coco" or "yolo". Default "voc". | voc |
| image_width | No | Pixel width; required for yolo boxes. | |
| image_height | No | Pixel height; required for yolo boxes. | |
| iou_threshold | No | Overlap above which the lower-scoring box is dropped. Default 0.5. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations: it discloses the deterministic tie-breaking behavior ('Ties break on the earlier index'), the exact error contract ('never raises a protocol error — it returns {"error": ...}'), and the idempotency/retry safety. It also reinforces readOnlyHint=true and idempotentHint=true with concrete retry guidance. This adds substantial value beyond what annotations declare.
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 dense but appropriately so: every sentence carries semantic weight (algorithm, determinism, example, error behavior, safety). The example JSON is the only 'bulk' and it earns its space by illustrating input and output simultaneously. Slightly long, but nothing is wasted.
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 6-parameter tool with an output schema and strong annotations, the description covers everything an agent needs: algorithm semantics, determinism, error handling, safety guarantees, and sibling differentiation. The presence of an output schema means return-value documentation is unnecessary here. No gaps identified.
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 provides a worked input/output example that illustrates the boxes/scores relationship but doesn't add syntax or format details beyond the schema's own excellent parameter documentation. The schema remains the primary source for parameter semantics.
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 a specific verb+resource ('Remove duplicate detections of the same object') and then details the exact greedy algorithm (keep highest-scoring box, drop overlaps above threshold). It explicitly differentiates from siblings by naming detection_metrics and bbox_convert as different purposes. This is a model of purpose clarity.
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 explicit when-to-use ('Use after a detector that emits overlapping boxes') and, crucially, when-not-to-use guidance with named alternatives ('Not for scoring against ground truth (detection_metrics) and not for format changes (bbox_convert)'). This satisfies the highest bar for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Work out the exact scale, padding and crop for a model input size. FREE.
Returns the numbers you need to transform boxes alongside the image, which is the step that usually gets skipped. Typical input {"width": 1920, "height": 1080, "target": "yolo_640"} returns {"scale": 0.3333, "resized": [640, 360], "pad": {"left": 0, "top": 140, "right": 0, "bottom": 140}, "box_transform": "x_new = x * 0.3333 + 0; y_new = y * 0.3333 + 140"}.
Use before feeding an image to a fixed-input model. Not for finding out the image's size in the first place - that is image_probe. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "unknown target ; use one of or set"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | "letterbox" scales to fit and pads the remainder, preserving aspect; "cover" scales to fill and crops the overflow; "stretch" distorts to fit exactly. Default "letterbox". | letterbox |
| width | Yes | Source image width in pixels. | |
| height | Yes | Source image height in pixels. | |
| target | No | A named preset: "clip_224", "vit_384", "yolo_640", "sam_1024", "sd_512", "sd_768" or "detr_800". Ignored when target_size is set. | yolo_640 |
| target_size | No | A square side length in pixels, overriding target. Use this for a size the presets do not cover. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds significant behavioral context: it explicitly states the tool never raises protocol errors on invalid input, instead returning a structured error object with guidance. It also confirms read-only and idempotent behavior, which reinforces safety for retries. There's no contradiction with annotations; in fact, the description amplifies the annotation hints with concrete error-handling details.
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 well-structured and front-loaded: it opens with the core purpose, gives a concrete example with a typical input/output, provides direct usage guidance, and closes with error-handling details. Every sentence adds value; there is no fluff or repetition. It is substantial but each part is necessary for correct tool invocation.
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 tool's moderate complexity (5 params, multiple presets, modes) and the presence of a rich output schema and annotations, the description covers everything needed: purpose, example, usage, error behavior, and safety. The error-handling details are particularly valuable for an agent to interpret unexpected responses. The description is complete enough that the agent can use the tool correctly without additional probing.
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 has 100% coverage with rich descriptions for all parameters, including acceptable values and defaults. The description adds value by showing the expected output shape and the box-transform formula, which clarifies how parameters flow into results. However, it doesn't elaborate on each parameter beyond the schema, but since the schema is already thorough, this is sufficient. A 4 is appropriate because the description's example adds meaning beyond the schema without over-explaining.
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 computes scale, padding, and crop for model input sizing, with a concrete example. It explicitly distinguishes itself from image_probe, and its purpose is unambiguous relative to sibling tools like bbox_convert or nms.
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 gives explicit usage guidance: 'Use before feeding an image to a fixed-input model' and even names the alternative for a different need ('Not for finding out the image's size in the first place - that is image_probe'). This tells the agent exactly when to invoke it and when not to, satisfying the when/when-not criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
bbox_convertcolour_checkdetection_metricsimage_probenmsresize_planClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Image toolkit: resize, compress, crop, watermark, convert, rotate, EXIF read/strip.
Image/video analysis: NSFW detection, object detection, thumbnails
Image processing for AI agents: resize, convert, compress, crop, and web-ready AI-generated images.
ImagePay MCP: 40 x402 paid API tools (OCR, PDF, image, QR, tabular, web). Pay per call on Base.
Add one secure layer between your agents and this server.
Each of the six tools addresses a clearly distinct operation: bbox_convert handles format transforms, nms removes duplicate detections, detection_metrics evaluates predictions, image_probe reads headers, resize_plan computes resize parameters, and colour_check checks WCAG contrast. There is no overlap or ambiguity between them.
Most tools follow a noun_verb pattern (bbox_convert, colour_check, image_probe, resize_plan) but two are outliers: detection_metrics is noun_noun and nms is an acronym. Naming is readable but not fully consistent across the set.
Six tools is a well-scoped count for a vision/maths utilities server. Each tool covers a distinct, necessary facet of computer vision workflows (conversion, suppression, metrics, probing, planning, contrast), with no apparent bloat or trivial tools.
The tool surface covers the core calculation needs for bounding-box-based vision tasks: conversion, NMS, evaluation, image metadata, resize planning, and accessibility contrast. Missing features like actual image manipulation or geometric transforms are outside the stated 'maths' scope, so coverage is strong. One could argue for a tool that applies resize to boxes, but resize_plan already returns the transform parameters, which is sufficient.