Skip to main content
Glama
dontpayfull

AInotate

by dontpayfull
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

zoom

Read-onlyIdempotent

Enlarge a selected image region with a fine, labeled source-pixel grid to read exact rectangle coordinates from the preview. The crop is saved to temp, leaving the original image unchanged.

Instructions

Enlarged crop of [x1,y1,x2,y2] with a fine grid labelled in SOURCE image px, so you can read an exact rect straight off the preview (spec scale 1). Use it after grid, or to check a rect from locate. Keep regions under ~500 px wide or the labels get too dense. Writes the crop to the temp folder; the input is not changed. Returns the zoom path, region, size, notes and the preview.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
x1YesLeft edge of the region, source image px.
x2YesRight edge of the region, source image px (greater than x1).
y1YesTop edge of the region, source image px.
y2YesBottom edge of the region, source image px (greater than y1).
stepNoFine grid spacing in source px (> 0).
image_pathYesPath of a PNG, JPEG or WebP image on this machine (~ allowed).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.1
    • addedInput schema / properties / image_path / description
      Added value: +"Path of a PNG, JPEG or WebP image on this machine (~ allowed)."
    • addedInput schema / properties / step / description
      Added value: +"Fine grid spacing in source px (> 0)."
    • addedInput schema / properties / x1 / description
      Added value: +"Left edge of the region, source image px."
    • addedInput schema / properties / x2 / description
      Added value: +"Right edge of the region, source image px (greater than x1)."
    • addedInput schema / properties / y1 / description
      Added value: +"Top edge of the region, source image px."
    • addedInput schema / properties / y2 / description
      Added value: +"Bottom edge of the region, source image px (greater than y1)."
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: the crop is written to the temp folder, the input image is unmodified, and the return payload is enumerated (zoom path, region, size, notes, preview). The only gap is the lifecycle of the temp file (overwritten? unique per call? cleanup?), which matters for an idempotent-hinted writer.

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

Conciseness4/5

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

The core purpose is front-loaded in the first clause, followed by usage routing, a size caveat, and side effects — a logical, information-dense order with no filler. Slightly run-on as a single packed first sentence, but every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by listing the returned fields, and it covers side effects, prerequisites, and size limits — enough for correct invocation. It falls short of 5 only because the temp-file naming/lifetime and whether repeated calls overwrite a prior crop are unstated for a tool that writes output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all six parameters — including the step default and the x1<x2 / y1<y2 constraints — are already documented in the schema; baseline 3 applies. The description reinforces the coordinate semantics ('labelled in SOURCE image px', 'spec scale 1') which is useful disambiguation against scaled previews, but adds no new per-parameter detail.

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

Purpose5/5

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

Opens with a concrete noun phrase — an enlarged crop of a given rect with a fine grid labelled in source-image pixels — and states the concrete outcome (reading an exact rect off the preview). It implicitly separates itself from 'grid' (referenced as a prior step) and 'locate' (whose rect it verifies), so an agent can distinguish it without inspecting schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use it after grid, or to check a rect from locate' explicitly names the two sibling workflows and the ordering condition that selects this tool. It also gives a practical usage constraint ('keep regions under ~500 px wide or the labels get too dense') that prevents a bad call — this is exactly the when/when-not guidance the dimension rewards.

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

Deploy Server

Other Tools