vision-primitives-mcp
Server Quality Checklist
Latest release: v1.11.0
- Disambiguation2/5
Multiple tools overlap significantly in purpose: locate_object, som_locate, cursor_locate, and cv_locate all return coordinates; describe_image, analyze_image, and compare_image/compre_infer all analyze visual content. While each has a distinct method, an agent would struggle to choose the right one without carefully parsing dense descriptions.
Naming Consistency2/5Tool names mix conventions: some use verb_noun (describe_image, crop_image), others use prefix_verb (ui_locate, cv_locate, som_locate), and a few are noun-y (vision_health, reason_graph). Even within the screen_* group, screen_capture vs screen_click are inconsistent in verb placement. This makes the naming unpredictable.
Tool Count2/5With 27 tools, the server exceeds the range where each tool feels essential. Several tools (e.g., cursor_locate vs som_locate, compare_infer vs compare_images) could be merged, and the count feels heavy for a 'vision primitives' server.
Completeness4/5The toolkit covers a broad range: OCR, description, structured analysis, localization, annotation, cropping, UI parsing, multi-image comparison, anomaly scanning, and screen control. There are few obvious gaps for a vision-oriented server, though some overlapping implementations suggest room for consolidation.
Average 3.7/5 across 27 of 27 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 48 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the VISION_ALLOW_SCREEN_CONTROL requirement, which is useful, but it does not describe the drag behavior, button handling, coordinate system, or potential 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief—a single sentence with a necessary prerequisite. There is no waste, but it is under-specified relative to the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the one-line description is far from complete. It lacks coordinate semantics, return values, button details, and behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only duration has a description). The description adds no meaning to x1, y1, x2, y2, or button, leaving these essential parameters undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a mouse drag operation and includes a specific prerequisite. It is distinguishable from siblings like screen_click and screen_move by the action name, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions the required environment variable VISION_ALLOW_SCREEN_CONTROL=1, which is a precondition, but gives no guidance on when to use drag rather than other input tools, nor any exclusions or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does mention the kind of information returned (resolution, DPI, control switch status), but it is vague about what 'control switch status' means, does not explicitly state it is a read-only query, and omits any side effects or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and waste-free, but it is a noun phrase rather than a complete sentence, and it lacks critical details. It is not as well-structured as the highest-conciseness examples, which use full sentences to convey scoping and alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 parameters, no output schema), but the description still leaves ambiguity around terms like 'control switch status' and does not explain the return format or how this tool fits among screen-related siblings. It is not complete enough for an agent to invoke it confidently without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema is empty, so parameter semantics is trivially clear. The description adds useful context about the data returned, which exceeds the baseline for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (screen) and the specific information provided (resolution, DPI, control switch status). It is more informative than just the tool name, but it lacks an explicit verb and does not differentiate it from sibling tools like screen_capture or vision_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as screen_capture or vision_health. The description only states what it does, not when it should be preferred, and provides no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the environment variable requirement, but it does not explain coordinate semantics (absolute vs. relative), the origin of coordinates, potential side effects, or failure modes. Important behavioral details remain ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and the key prerequisite. It is appropriately sized for a simple tool, avoids redundancy, and front-loads the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description and schema together lack essential context such as the coordinate system, whether the move is absolute, and expected error behavior. Given the absence of an output schema and annotations, this is insufficient for an agent to reliably invoke the tool with correct parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two numeric parameters with 0% description coverage, and the description does not clarify what x and y represent. It only indicates that the cursor will be moved, offering no guidance on coordinate interpretation, units, or whether the values are absolute or relative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the operation: 'only move the mouse cursor,' which is a specific verb+resource. The prefix 'only' clearly differentiates it from sibling tools like screen_click and screen_drag, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a required environment variable (VISION_ALLOW_SCREEN_CONTROL=1) but provides no guidance on when to use this tool versus alternatives such as screen_click or screen_drag. No alternative tools are referenced, and no use cases are described, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one key behavioral trait: '找不到会返回 count=0' (returns count=0 if not found), which is useful and goes beyond the schema. It also mentions the coordinates are 'primitives' for LLM output. However, it does not disclose other behaviors such as error handling, performance implications, or whether the operation is read-only/destructive, and with no annotations, the burden is higher.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and includes a key behavioral detail (count=0). It is concise with no wasted words, and the structure is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is underspecified. It does not describe the return structure (e.g., shape of primitives, how count is included), doesn't clarify when to use this tool over many siblings, and doesn't explain the coords/refine options sufficiently. The description is too minimal for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% and the description adds little parameter meaning beyond what's in the schema. It mentions '坐标 primitives' which loosely relates to the coords parameter, but does not explain the refine or target parameters or how they affect behavior. The schema descriptions for coords and refine are already present, so the description does not compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool locates a target object in an image and returns coordinate primitives, with a specific verb-resource pairing ('locate object in image'). However, it does not differentiate from sibling tools like ui_locate or cv_locate, which also locate objects, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for object localization but provides no explicit guidance on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or when another locator (e.g., ui_locate, som_locate) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It states it returns text but does not disclose limitations (e.g., supported formats), whether it is read-only, or potential errors. It is truthful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action and output. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the schema covers parameters. However, with no output schema and many sibling tools, a bit more context about the return format or example use cases would improve completeness. As is, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with descriptions (100% coverage). The description adds no additional meaning about how parameters affect behavior, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uses a vision model to describe image content and returns text. It is a specific verb+resource, but it does not explicitly differentiate from siblings like analyze_image or ocr_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as ocr_image or analyze_image. The description is a single statement with no context on conditions, exclusions, or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output structure (description + visual_primitives with coordinates and labels), which is a key behavioral trait. However, with no annotations available, it does not cover input requirements, limitations, or failure modes, leaving some ambiguity about expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that packs essential output information without any redundancy. It is perfectly concise for the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the concise output summary, the description lacks usage context, input semantics, and any detail about the visual_primitives structure. With no output schema and no annotations, the description carries a heavy burden and falls short of being complete for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'format' and 'question' parameters, but the required 'image' parameter lacks any description, and the tool description doesn't compensate. With 67% schema coverage, the baseline is 3, but the missing image semantics are a noticeable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs structured analysis and returns description plus visual_primitives with box/point coordinates and labels. This clearly identifies the tool's output and distinguishes it from siblings like describe_image or ocr_image, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It only states what it returns, leaving the agent to infer usage context. There is no mention of scenarios, exclusions, or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key behavioral trait that session carries state across rounds, which is valuable. However, it does not mention whether the tool is read-only, what it returns, or any side effects, leaving notable gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a compact arrow notation to summarize the reasoning flow and a separate sentence for session state. Every word earns its place, making it efficient and front-loaded, though the notation might be slightly cryptic for some readers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with a nested step object and multiple action types, yet the description provides only a high-level protocol overview. It lacks operational details such as how to start a session, how to chain steps, expected return values, and error handling. Given no output schema, the description is insufficient for reliable multi-round use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 75% of parameters with descriptions, including a detailed explanation of the step object. The description adds context about the protocol flow and the role of session in carrying state, which helps clarify parameter usage. However, it does not provide significant per-parameter details beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is an interactive graphical reasoning protocol with a multi-round loop from primitives (locate/measure) to semantics (semantic/hypothesis) to annotation (annotate/verify). This distinguishes it from single-step sibling tools like ocr_image or locate_object, though the term 'reasoning protocol' is somewhat abstract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for multi-round iterative reasoning tasks on images, mentioning the loop and session state. However, it does not explicitly state when to use this tool versus simpler alternatives, nor does it provide any exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the output structure (text + bbox with both pixel and normalized coordinates), which is useful. However, it does not mention input constraints, error behavior, or any side effects, leaving gaps in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that immediately states the core function and return format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks guidance on prerequisites or image format. It does describe the return output, which compensates for the missing output schema. However, it doesn't cover usage context or when alternatives should be chosen, making it merely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 50% description coverage, but the tool description adds minimal meaning for the parameters. It identifies the image as the input via context, but does not explain the language parameter or clarify how images are passed (path, URL, base64). The language parameter is only described in the schema, not reinforced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs OCR to extract all text blocks from an image and return text plus bounding boxes. The term 'OCR' and the focus on 'text blocks' distinguishes it from sibling image tools like describe_image or locate_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus other vision tools. It neither mentions alternatives nor specifies exclusions. The context of text extraction is implied by the name, but no direct comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool saves the result and returns a path, which is useful. However, it does not mention side effects (e.g., whether the original image is modified), error conditions, or the exact output format beyond 'path.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action and includes the two most important defaults. Every word earns its place with no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, but the description covers the main behavior (zoom, save, return path). Missing details include coordinate system behavior, out_path handling, and edge cases, though some of this is captured in the schema. Overall, it is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, and the description only rephrases the defaults already present in the schema (e.g., box omitted = whole image, scale default = 2). It adds no new meaning for parameters like coords or out_path, so the value beyond the schema is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: zoom into a specified region of an image, defaulting to the whole image at 2x, then save and return the path. This is a specific verb+resource combination that distinguishes it from similar tools like crop_image or ocr_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or comparison to sibling tools, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses core behavior: multi-image comparison and reasoning, per-image annotations, and relation categories, but it does not describe output format, potential limitations, or how mode/alpha parameters influence behavior, leaving notable uncertainty for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the purpose, then specifies input count, per-image annotations, and reasoning categories. It contains no filler or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, optional mode/alpha parameters, and a nested items_per_image object, so the description needs to cover return behavior and parameter effects. It adequately conveys the core purpose and relation types but omits output format and mode/alpha semantics, making it moderately complete but not fully sufficient for all invocation contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (80%) and the schema already documents items_per_image as an optional per-image mapping, mode defaults, and alpha. The description adds little beyond restating that images can carry independent annotations, so it does not meaningfully expand parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as performing multi-image joint reasoning on 2-4 images, with optional per-image annotations and enumerated relation types (differences, causality, timing, overall conclusion). It is specific enough about scope, though it does not explicitly contrast it with the similarly named sibling tool compare_images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multi-image reasoning scenarios and mentions the supported relationship types, but it provides no explicit guidance on when to prefer this tool over alternatives like compare_images or reason_graph, and no exclusions or conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does state the key behavior: save the annotated image and return the path. However, it does not mention whether the original image is modified, how coordinates are validated, or possible side effects like file overwriting. This is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the action and the result. It is front-loaded with the core function ('在图片上画矩形框/圆点/标签') and ends with the output behavior ('保存标注图并返回路径'). No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (5 parameters, nested objects, no annotations, no output schema), the description provides the essential output (returns path) and mentions the saving behavior. However, it lacks broader context such as when to use the tool, coordinate system handling, or limitations. The schema covers parameter details, but the description alone is thin for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for 4 of 5 parameters (80% coverage), so the baseline is 3. The description does not add any parameter semantics beyond what the schema already offers. It only mentions the types of annotations (boxes/dots/labels) which aligns with the 'items' parameter but adds no new detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: drawing rectangles/dots/labels on an image, saving the annotated image, and returning the path. This distinguishes it from sibling tools like crop_image, ocr_image, and analyze_image, which have different purposes. The verb '画' (draw) and resource '图片' (image) are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The usage is implied from the description: use this tool when you need to add visual markers to an image. However, no alternatives or exclusions are mentioned, so it only meets the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It discloses key behaviors: it saves the cropped image and returns the path and new dimensions, and supports edge expansion. However, it does not describe the return format or what happens if out_path is omitted, and it leaves coordinate system defaults to 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action first ('按坐标裁切图片') and adds supplementary details. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description adequately conveys the main operation and result, but it lacks details on return value structure and parameter semantics for image/out_path. Given the complexity, it is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, and the description adds some meaning beyond the schema by explaining the purpose of coordinates and edge expansion, and mentioning output path. It does not clarify the 'image' parameter or 'out_path' parameter in detail, but it partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool crops an image by coordinates, with optional edge expansion, and saves/returns the result. This is a specific verb+resource combination that is distinct from sibling tools like ocr_image or describe_image, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (crop an image when needed) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. It does not mention scenarios like 'use this instead of zoom_region' 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It conveys the core behavior (checking config and connectivity), and the verb 'check' implies a read-only operation. However, it does not explicitly state whether it modifies anything, what it returns, or any side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that directly conveys the purpose without any wasted words. It is perfectly concise for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple with no parameters, there is no output schema to explain return values. The description does not clarify whether the health check returns a boolean, status details, or an error, making it somewhat incomplete for an agent that needs to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter details, and the empty schema covers all parameters trivially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks visual backend configuration and connectivity, using a specific verb ('check') and resource. It distinguishes itself from sibling vision tools (e.g., OCR, image description) by focusing on health/status rather than image processing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not state that it should be called before other vision tools to verify backend availability, nor does it mention any exclusions or alternative tools for similar health checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It states the return behavior ('返回逐项对比结果') and the scope of 2-4 images, but it does not mention any side effects, permissions, or limitations, which are less critical for a read-only analysis tool but still relevant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Chinese, front-loaded with the core purpose and immediately followed by concrete use cases and return type. Every phrase adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description provides sufficient context: it explains what the tool does, how many images to use, common scenarios, and the nature of the output. It lacks explicit output structure but is adequate for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes all parameters (detail, images, question). The description does not add significant parameter-level detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: '多图对比分析' (multi-image comparison analysis), with concrete use cases (A/B screenshot comparison, design mockup consistency, multi-frame analysis). It distinguishes from sibling tools like describe_image/analyze_image by emphasizing multiple images and comparison-specific tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives example use cases that imply when to use the tool (A/B testing, design consistency, multi-frame analysis), but it does not explicitly state when not to use it or mention alternatives. The usage context is clear but not prescribed with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the core side effect of saving a PNG and returning a path, but omits details such as file location, overwrite behavior, permission requirements, or error handling, which are relevant for a screen capture tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action (截屏) and states the output and usage context. Every part adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 optional parameters and no output schema, the description covers purpose and regional parameter, but leaves out_path semantics and return-path details vague. It lacks enough detail about the second parameter to be fully complete, though it does provide integration context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: region has a description in the schema, but out_path does not. The description mentions 'full screen or specified region' for region, but provides no additional meaning for out_path beyond 'saving PNG and returning path', leaving its role ambiguous. It does not fully compensate for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screenshot (截屏) of the full screen or a specific region, saves it as PNG, and returns the path. It also distinguishes itself from sibling analysis/action tools by noting it provides the visual input for locate_object/describe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a direct usage context: '配合 locate_object/describe 实现「看屏幕」' indicating it is used in conjunction with those tools to see the screen. It does not explicitly contrast with alternatives or provide exclusions, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 iterative process, the final box mode, and the accuracy advantage. However, it does not mention side effects (e.g., saving annotated images via out_path), the number of vision calls per round, or potential limitations, leaving behavioral transparency incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences with zero filler. The first sentence front-loads the tool's purpose and core algorithm; the second adds a usage guideline. Every clause earns its place, making it highly concise and well-structured for a technical tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters and no output schema, yet the description only explains the high-level algorithm. It does not clarify the return format (pixel vs norm, relative to which image), how the 'box' output is expressed, or how to interpret results after multiple rounds. This is a significant gap for a complex tool, leaving the agent without critical operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 89%, so the baseline is 3. The description's mention of final modes (box/number/cv) and grid recursion aligns with schema descriptions but does not add new parameter-level semantics. Parameters like grid, rounds, expand, and coords are already well documented in the schema, and the description does not elaborate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific method: Set-of-Mark numbered grid recursive localization. It details the process (overlay numbers, model answers number, iterative crop/zoom, final box output) and contrasts it with direct coordinate localization, distinguishing it from generic locate tools like locate_object or cv_locate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: it is more accurate than direct coordinate output for general VLMs without grounding training (e.g., MiMo). This implies when to prefer this tool. However, it does not explicitly name alternative sibling tools or provide exclusion conditions ('use this when... not when...'), falling short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无 annotations，描述承担披露责任。它明确说明了 YOLO 检测器在 models/icon_detect.pt 存在时自动启用、输出带 id 的结构化元素列表、out_path 保存半透明叠加层编号图等行为信息，这些都是超出工具名的实际执行细节。但未提及是否只读、失败行为或输出字段细节，因此未到满分。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
一段长句用分号分隔，信息密度高，主要功能前置，每部分都有必要信息。但语句较长，未采用分点或短句组织，可读性略低于极简两句话的示例，属于高效但不够精致。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具较复杂（OCR+控件检测+图标+可选 YOLO+输出文件），且无 output schema。描述说明了输出为带 id 的结构化元素列表、叠加层图保存的核心用途、YOLO 自动启用条件，足以让 agent 理解如何调用。但未提供元素字段结构或错误场景，完整度略低于满分。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema 已覆盖 coords 和 out_path 并提供说明，image 参数无 schema 描述。描述补充了 image 应为全屏 UI 截图，并解释了 out_path 的叠加层编号图用途，但未说明 image 的具体格式或元素列表字段结构。在 67% schema 覆盖基础上，描述增加的语义有限，符合基线 3。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
描述以“全屏 UI 结构化解析”开头，明确动词和资源，并列举 OCR 文本块、button/input 矩形检测、图标候选、可选 YOLO 检测器，输出带 id 的结构化元素列表。这与 ocr_image、locate_object 等兄弟工具形成清晰区分，功能定位具体且明确。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
描述提供了核心适用场景（全屏 UI 解析、输出编号元素供 VLM 选择）以及可选 YOLO 自动启用的条件，但未明确说明何时不使用本工具或与 ui_locate、ui_refine 等替代工具的取舍。使用场景主要是隐含的，缺少显式排除或替代建议。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses a key behavior: '不修改原图' (does not modify the original image), and clarifies how modes work. However, it does not describe the output/return format or any other side effects, which is a gap given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences that convey the core purpose, modes, and key safety behavior. Every phrase adds relevant information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no output schema, no annotations), the description provides a solid overview, covers modes, clarifies non-destructive behavior, and gives examples for items and question. However, it omits explicit return-value semantics, which would improve completeness, but is largely adequate due to strong schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 88% coverage, providing baseline. The description adds value by explaining the modes (virtual vs overlay) and listing annotation types (框/点/连线/箭头/圆) that map to the items parameter, beyond what the schema states. It also gives an example of the question parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '虚拟标注 + 增强图形推理' (virtual annotation + enhanced graphical reasoning), with specific actions like injecting annotations into the vision model to guide spatial reasoning. It distinguishes itself from sibling tools like annotate_image by adding the reasoning component, and details two modes (virtual and overlay).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for spatial relationship reasoning and explains mode selection (virtual vs overlay), but it does not explicitly state when to use this tool over alternatives or mention exclusions. No comparison with siblings like annotate_image or describe_image is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the destructive/transformative operations (deleting, merging, labeling, adding text anchors) and what the tool does NOT do (coordinate fine-tuning). It also discloses the return value (corrected element list and change log). However, it does not discuss side effects on input files, failure modes, or prerequisites beyond the image, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the main purpose, then lists operations, then provides an exclusion, and ends with the return type. Every clause earns its place, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose, operations, and return value, but fails to clarify a critical aspect: how are the UI detection boxes provided as input? The schema only includes an image parameter, yet the tool is supposed to correct detection boxes. This is a significant gap that leaves the agent uncertain whether boxes are drawn in the image, passed via internal state, or expected to be detected by the VLM itself. Given the moderate complexity and lack of output schema, the description should have addressed this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (coords and out_path have descriptions, image does not). The tool description does not add any parameter-specific meaning beyond the schema. The baseline for this coverage is 3, and the description does not improve it, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb: 'VLM 审查并语义修正 UI 检测框' (reviews and semantically corrects UI detection boxes). It lists concrete operations (delete false positives, merge duplicates, semantic labeling, text anchor gap-filling) and explicitly distinguishes itself from coordinate-level correction, which is handled by som/cv. This differentiates it clearly from sibling tools like cv_locate and som_locate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit exclusion: '不做坐标微调（坐标级修正由 som/cv 负责）' (does not do coordinate fine-tuning, coordinate-level correction is handled by som/cv), naming the alternative tool for that use case. It implies usage after initial detection to clean up false positives and duplicates, but does not fully enumerate all possible alternatives like ui_parse or ui_locate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals the multi-step algorithm (overlapping tiles, candidate localization, high-resolution crop verification) and discloses output fields (confidence, angle, silkscreen). This goes beyond a generic 'scan' claim, though it stops short of discussing performance implications or input requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence but remains structured and front-loaded with the primary purpose. It packs substantial detail without excessive verbosity, earning its length through workflow explanation. It could be slightly more scannable, but it is far from bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description provides a comprehensive overview: purpose, algorithm, and key output fields. It does not explicitly detail every parameter (e.g., target, max_tiles) but the schema covers those. The algorithm context helps explain why certain parameters exist, making the tool's behavior well-rounded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%), so baseline is 3. The description adds algorithm context that explains the purpose of region, overlap, tile_size, and verify parameters, linking them to the tiling and verification process. This enriches the semantic meaning beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool scans for abnormal/skewed components in images, using a specific verb ('scan') and resource ('abnormal/skewed components'). It distinguishes itself from sibling tools like analyze_image or locate_object by focusing on anomaly detection and describing a tiled verification workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for detecting anomalies in images but does not explicitly instruct when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. Sibling tool names provide context, but the description itself lacks comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It explains the iterative feedback loop and why it is used, but does not disclose potential side effects (e.g., whether the actual screen cursor is moved), failure behaviors, or what happens if `max_steps` is exceeded. This is moderate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the core mechanism, the second justifies its advantage. No wasted words, front-loaded with the tool's purpose and method.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool with 7 params and no output schema, the description explains the distinct interactive approach. It lacks explicit mention of return format, but the schema's `coords` parameter indirectly covers this. Overall, it is nearly complete for a specialized locator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 86% of parameters, so the baseline is 3. The description adds meaning by explaining the relative-offset mechanism, which helps interpret `max_steps` and `step_ratio`. It does not detail individual parameters, but the core behavior clarifies their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: moving the cursor with a visual feedback loop to iteratively locate a target by estimating relative offsets (dx/dy). This distinguishes it from sibling tools like `locate_object` or `som_locate` by emphasizing the interactive refinement mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear rationale for when this tool is preferred: when relative offset estimation is more accurate than absolute coordinates, citing the GUI-Cursor interactive search paradigm. However, it does not explicitly mention when not to use it or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a permission requirement (VISION_ALLOW_SCREEN_CONTROL=1) and that coordinates are derived from locate_object. However, it doesn't disclose what happens if the permission is missing, whether the mouse pointer moves, or any error behavior, which are relevant for a control action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and prerequisite. Every clause adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple click tool with 4 parameters and no output schema, the description covers the core purpose, a prerequisite, and the coordinate provenance. It lacks details on optional parameters' behavior beyond schema, but that's not needed. Given siblings, it could mention not to use for dragging, but name already conveys that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers button and double with descriptions, but x and y have no schema descriptions. The description adds meaning to x and y by stating they are typically from locate_object's localization result on screenshots, providing a coordinate source. This compensates for the 50% schema coverage. Button and double are already explained in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a mouse click (鼠标点击), which is a specific verb and resource. It distinguishes from sibling tools like screen_move and screen_drag by specifying the click action. The additional context about coordinates from locate_object further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear usage context: coordinates usually come from locate_object, and it requires the VISION_ALLOW_SCREEN_CONTROL=1 environment variable. This implies when to use (after locating objects) and a prerequisite. It doesn't explicitly state exclusions or alternatives, but for a click tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the environment variable prerequisite and example key formats, which adds helpful context. However, it does not describe failure behavior, side effects, or what happens if the environment variable is not set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with examples, efficiently conveying purpose and prerequisite without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers purpose, prerequisite, and examples. There is no output schema, so return behavior is not explained, but this is a minor gap given the tool's simplicity and the descriptive sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'key' parameter, and the description adds concrete examples (enter, ctrl+c, alt+tab) that illustrate expected formats and usage, going beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it presses a key or key combination, with concrete examples (enter, tab, ctrl+c, alt+tab). The verb '按键' (press key) and resource are specific, and it is distinct from sibling tools like screen_click (mouse) and screen_type (typing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear requirement (VISION_ALLOW_SCREEN_CONTROL=1) and provides examples, implying usage for keyboard input scenarios. However, it does not explicitly contrast with alternatives like screen_type or screen_click, so no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the direction convention and an environment variable requirement, which are useful behavioral details not present in the schema. However, it does not mention potential error behavior or whether scrolling targets the active element.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and prerequisite, and contains no unnecessary words. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core behavior, direction, and a key prerequisite. It lacks details on return values or failure modes, but these are likely not critical for a scroll action, and the given context is sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the delta parameter with a description ('滚动格数（正=上，负=下）') that matches the tool description's direction info. Since schema coverage is 100%, the description adds no new parameter-level meaning beyond what is already present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as wheel scrolling ('滚轮滚动') with specific direction semantics (positive up, negative down). This distinguishes it from sibling tools like screen_click or screen_move, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite (VISION_ALLOW_SCREEN_CONTROL=1) that indicates when the tool is permitted to operate. It does not explicitly mention alternatives or exclusions, but the context is clear enough for a simple scroll action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavior disclosure. It reveals important behavioral traits: the environment variable requirement and the clipboard fallback for non-ASCII characters. This goes beyond a simple 'types text' and gives the agent actionable details. It does not cover error cases or focus management, but for a simple input tool this is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the core purpose front-loaded in the first three characters. Every word earns its place: the prerequisite and behavioral split are both critical. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides sufficient context for correct invocation: what it does, when it works (env var), and how it handles different text types. The only gap is lack of details about focus management or post-input behavior, but these are not essential for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It clearly explains the 'text' parameter's role: the text to input, with ASCII characters pressed directly and Chinese (or other non-ASCII) pasted via clipboard. This adds meaningful semantics beyond the bare schema, although it omits details like length limits or format requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '键盘输入文本' (keyboard input text), specifying the verb (input) and resource (text). It also distinguishes from sibling tools like screen_click or screen_scroll by focusing on text entry, and the special ASCII vs clipboard behavior further differentiates it from screen_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit prerequisite: VISION_ALLOW_SCREEN_CONTROL=1, indicating when the tool can be used. It also explains the two input methods (ASCII direct, Chinese via clipboard), which implies when each mode applies. However, it does not explicitly name alternative tools or exclusions, so it lacks a direct 'use this instead of X' comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the OCR-based text-anchoring process, pixel-level bounding box output, and the fact that it returns a candidate list for VLM confirmation. This goes beyond just saying 'locates elements' and provides useful behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by usage context and return information. It uses two sentences without filler, effectively packing method, use case, and output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, the description covers the method, use case, and high-level return (matched + candidate list). It doesn't detail exact output structure or failure modes, but the given information is sufficient for an agent to select and preliminarily invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for 3 of 4 parameters (75% coverage). The description adds meaning to the `target` parameter by explaining the interpretation flow (target description → keywords → OCR text matching), which complements the schema's literal parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool locates UI elements via OCR text matching, with a specific method pipeline (target description → keywords → OCR → bounding box). It also distinguishes itself from siblings like cursor_locate or cv_locate by focusing on clickable UI targets and returning a candidate list for VLM confirmation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that this is an alternative precise localization method for clickable UI targets (buttons, input boxes, icons), giving clear context for when to use it. However, it does not name alternative tools or explicitly state 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses internal mechanisms (color segmentation, centroid, template matching), zero dependencies, and measured accuracy (0-4px). However, it does not mention output format or potential failure modes, leaving a minor transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core function, then use cases and alternatives. No wasted words, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description covers purpose, method, accuracy, use cases, and alternatives. It does not explicitly state the return format, though the schema's coords parameter hints at it. Given moderate complexity and good schema coverage, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), so baseline is 3. The description adds value by clarifying that color and template are alternative modes (matching the schema's 'at least one' requirement) and suggesting template use on VLM coarse-localized local regions, which is not in the schema field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs traditional CV precise localization via color segmentation + connected component centroid or template matching. It explicitly positions itself as an alternative to locate_object/som_locate, distinguishing it from siblings with specific methods and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states suitability for simple targets (solid colors, geometric shapes, fixed templates) and limitations of generalization, then directly instructs to use locate_object/som_locate for general targets. This provides clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zouyuanqing/vision-primitives-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server