screenshot-mcp

by cai-cai-jun

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: full-screen capture, region capture, image viewing for vision, listing, specific deletion, and bulk cleanup. The only potential overlap is delete_image and cleanup, but cleanup is clearly bulk with filters, so boundaries are clear.
Naming Consistency4/5
Most tools follow a verb_noun pattern (view_image, list_images, delete_image), but screenshot, screenshot_region, and cleanup deviate slightly. The naming is still readable and predictable, with only minor inconsistencies.
Tool Count5/5
Six tools is well-scoped for a screenshot server, covering capture, viewing, listing, and deletion without unnecessary bloat. The count feels natural and each tool earns its place.
Completeness5/5
The server covers the full screenshot lifecycle: capture (full and region), view for AI analysis, list, delete specific, and cleanup. No obvious missing operations are apparent for the stated purpose.
Average 3.7/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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.json to 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 must carry the full burden of behavioral disclosure. It only states the action and input format, but does not mention that a file is saved, where it is saved, default filename behavior, or what the tool returns. This is a significant gap for a screenshot tool that likely creates image files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information, front-loading the core purpose and input method. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too thin to fully understand the tool's behavior, such as file output, naming defaults, and error handling. It does not explain what happens after the screenshot is taken or how the 'active_window' option behaves across platforms.
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?
The schema already provides 100% coverage with descriptions for both 'region' and 'filename,' and the description merely restates the region format without adding new details about coordinate systems, units, or default values. The 'filename' parameter is not mentioned in the description, so no added value beyond the schema.
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?
The description clearly states the tool takes a screenshot of a specific screen region, distinguishing it from the sibling 'screenshot' tool by emphasizing 'specific region.' It also mentions the two input modes, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for capturing a defined screen area but does not explicitly contrast it with the sibling 'screenshot' tool, nor does it provide when-to-use/when-not-to-use guidance or exclusions. Users must infer that full-screen captures would use 'screenshot.'
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 only states the action (delete) and the input (path) but does not disclose that deletion is likely permanent and irreversible, whether special permissions are required, or what happens if the path does not exist. This is a significant transparency gap for a destructive 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that contains no filler or irrelevant information. It is front-loaded with the action and resource, making it easy to process quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), so the description is mostly adequate. However, it omits important operational context such as whether the deletion is permanent and whether errors are raised for non-existent paths. Given the lack of annotations, a bit more detail would make it complete.
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?
The input schema already describes 'path' as 'Absolute path to the image file to delete' with 100% coverage, so the description adds no additional semantic meaning. The baseline of 3 applies because the schema handles the parameter documentation adequately.
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?
The description uses a specific verb ('delete'), identifies a precise resource ('image file'), and clearly scopes the action to a single file identified 'by path'. This differentiates it from sibling tools like 'cleanup' which likely handle bulk deletion, and from 'view_image'/'list_images' which are read operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for deleting a specific image when you have its path, but it does not explicitly state when to use this versus alternatives like 'cleanup' for bulk deletion, nor does it mention prerequisites like locating the path via 'list_images'. The guidance is implied rather than explicit.
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 must carry the transparency burden. It discloses the sorting behavior ('newest first') but does not mention other behavioral aspects such as return format, read-only nature, behavior when the directory is empty, or any error conditions. For a simple list tool, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and scope. It contains no filler or redundant information. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple listing operation with one optional parameter and no output schema. The description covers the core behavior but does not specify what fields are returned for each image (e.g., file name, path, timestamp) or how the results are formatted. Given that an output schema is absent, the description falls short of fully documenting the tool's response.
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?
The input schema provides a complete description for the sole parameter 'limit' (100% coverage). The tool description adds no additional meaning or context beyond what the schema already specifies, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all screenshot images in the screenshots directory, sorted by newest first.' It uses a specific verb ('list'), identifies the resource ('screenshot images'), and adds a scope detail ('screenshots directory'). This differentiates it from siblings like view_image or delete_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/5
Does 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 alternatives. It does not mention any exclusions, prerequisites, or refer to sibling tools like view_image or delete_image. The intended use case is implied but not 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?
With no annotations, the description carries the burden of disclosure. It reveals the key side effect: saving to a local screenshots/ directory. However, it omits other behavioral details such as whether it returns a path, behavior on headless environments, or handling of existing files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action, and every word adds value. No fluff or redundancy.
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?
For a simple tool with one optional parameter and no output schema, the description covers the essential purpose and side effect. It is complete enough for an agent to understand what the tool does, though it could benefit from a note on what it returns (or not).
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% for the single optional filename parameter, and the description adds no extra meaning beyond that. The baseline score applies since the schema already documents the parameter fully.
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?
The description clearly states the tool takes a screenshot of the entire screen, using a specific verb ('Take') and resource ('screenshot of the entire screen'). It distinguishes from the sibling tool 'screenshot_region' by explicitly mentioning 'entire screen'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for full-screen captures but does not explicitly mention alternatives or when not to use it. The phrase 'entire screen' indirectly contrasts with screenshot_region, but no direct guidance or exclusions are provided.
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 destructive nature ('Delete') and the risky default (deletes all), but does not mention permanence, reversibility, or side effects such as whether files are moved to trash or permanently removed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action. Every word earns its place, and the default behavior is highlighted effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but without annotations or an output schema, the description should clarify side effects (e.g., permanent deletion) and success/failure behavior. The current description covers basic functionality but leaves out important operational details for a destructive operation.
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 description coverage is 100%, with parameters well-documented in the schema. The description adds a brief paraphrase of filters but does not add significant semantics beyond the schema.
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?
The description clearly states the action ('Delete screenshots') and resource (screenshots). It distinguishes from siblings like delete_image by indicating bulk deletion with filters, while delete_image likely handles individual images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context on when to use: default deletes all, with options to filter by age or filename pattern. It does not explicitly compare to alternatives like delete_image, but the behavior is clear enough for an agent to infer bulk cleanup use.
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 burden of behavioral disclosure. It states that the tool reads a file and returns it, and which formats are supported. However, it does not describe the return format (e.g., base64, binary), error handling for missing/invalid files, or any safety constraints. The basic behavior is disclosed, but important details are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus a short format list. It is front-loaded with the core action and purpose, with no superfluous words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no annotations, the description covers the primary use case. However, with no output schema provided, it does not explain the exact return representation or how the image will be delivered for vision analysis. This is a significant gap for an agent deciding whether the tool will meet its needs.
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?
The input schema already fully documents the single 'path' parameter with the description 'Absolute path to the image file.' The tool description adds no additional parameter-level meaning beyond the schema, so the baseline of 3 applies. Supported formats are a tool-level trait, not parameter semantics.
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?
The description clearly states the tool's function: 'Read an image file and return it for AI vision analysis.' It uses a specific verb ('read') and resource ('image file'), and distinguishes itself from siblings like screenshot (captures new images) and delete_image (removes files). The list of supported formats adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you need to analyze an existing image file with AI vision. It does not explicitly name alternatives or exclusions, but the purpose is distinct enough from sibling tools (screenshot, screenshot_region) that an agent would not confuse them. The description implies it is for reading pre-existing files, not capturing new ones.
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:

[![screenshot-mcp MCP server](https://glama.ai/mcp/servers/cai-cai-jun/screenshot-mcp/badges/card.svg)](https://glama.ai/mcp/servers/cai-cai-jun/screenshot-mcp)

Score Badge

Copy to your README.md:

[![screenshot-mcp MCP server](https://glama.ai/mcp/servers/cai-cai-jun/screenshot-mcp/badges/score.svg)](https://glama.ai/mcp/servers/cai-cai-jun/screenshot-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/cai-cai-jun/screenshot-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server