cleanshot-mcp

by jdorfman

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.1
Disambiguation4/5
Most tools target distinct actions such as capture modes, history, settings, and annotations. Some overlap exists between capture_area, self_timer, and all_in_one, but descriptions clarify the differences, and toggle vs show/hide is a minor overlap.
Naming Consistency4/5
All tools share the cleanshot_ prefix and mostly follow a verb_noun structure (capture_fullscreen, open_history). A few exceptions like all_in_one and self_timer are mode names, but overall the pattern is predictable.
Tool Count4/5
19 tools is on the higher end but appropriate for a feature-rich screenshot utility, each mapping to a distinct feature. Some consolidation of desktop icon tools could reduce count, but it is not excessive.
Completeness4/5
The tool set covers the main CleanShot capabilities: various capture modes, OCR, annotation, history, settings, and desktop icon management. Minor gaps like direct file saving or sharing exist, but the core workflows are covered.
Average 3.1/5 across 19 of 19 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Open' and reveals nothing about side effects, whether a capture UI appears, whether auto-scroll is triggered, or what happens with the provided parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. But it is so minimal that it reads more as an under-specified label than a helpful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 optional parameters, no annotations, and no output schema, the one-sentence description is completely inadequate. It does not explain return values, prerequisites, how to use the parameters, or what 'Scrolling Capture mode' actually entails.
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 has 100% coverage with individual descriptions for all 7 parameters, so the description does not need to repeat them. However, it adds no value about how parameters interrelate or how x, y, width, height, and autoscroll affect the scrolling capture mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Open') and a specific resource ('CleanShot's Scrolling Capture mode'), which distinguishes it from sibling capture tools by naming the mode. However, it does not explain what the mode does or its scope beyond the name.
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?
No guidance is given about when to use this tool versus alternatives like cleanshot_capture_area or cleanshot_all_in_one. There is no mention of prerequisites, use cases, or exclusions.
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 available, the description alone must disclose behavioral traits. It only says 'Launch' without explaining what happens after launching: whether a UI appears, whether a capture is immediately taken, or whether any side effects occur. The optional position/size parameters hint at customizing the capture area, but the overall user-facing behavior remains opaque.
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 core action and includes the optional parameters without waste. Every word earns its place, and it is appropriately brief for a simple launch operation.
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?
For a tool with no annotations and no output schema, the description is under-specified. It does not explain what 'All-In-One mode' entails, how to invoke it, what the user sees, or what the return value might be. Even with only five optional parameters, the lack of context makes the tool hard to use correctly without additional knowledge.
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 descriptions cover all 5 parameters with clear explanations (e.g., 'X coordinate (0,0 is lower left)'). The description adds only a high-level grouping ('position and size'), which is helpful but not substantive. Since schema coverage is 100%, a baseline of 3 is appropriate, and no additional semantic value is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (Launch) and resource (CleanShot's All-In-One mode), making the primary purpose apparent. However, it does not differentiate this mode from sibling tools like cleanshot_capture_area or cleanshot_capture_fullscreen, and it leaves the exact nature of 'All-In-One mode' undefined, so it falls short of a 5.
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 guidance on when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or prerequisites, which is especially problematic given the large number of sibling capture tools that could overlap. No context is provided to help an agent decide between them.
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 of behavioral disclosure. It fails to explain what happens when parameters are provided, whether the capture is triggered automatically or waits for user interaction, or what the return behavior is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary wording, making it concise and front-loaded. It is slightly under-specified but not verbose or redundant.
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 tool's six optional parameters and no output schema or annotations, the description is far too minimal. It doesn't explain the capture flow, parameter effects, or how it compares to sibling tools, leaving the agent without enough context to invoke it correctly.
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 descriptions for all six parameters, so the baseline is 3. The description itself adds no parameter-specific meaning, but the schema's high coverage makes this acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the action ('Open') and resource ('CleanShot's Capture Area mode'), which clearly distinguishes it from sibling capture modes like fullscreen or window. However, it does not explicitly state that this is for rectangular region captures, relying on the tool name for 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/5
Does 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. It only mentions 'with optional parameters' without any context, exclusions, or mentions of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden for behavioral disclosure. It only states the basic action without covering side effects, output behavior, or how the action parameter affects the capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise, though it omits details that other dimensions require.
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?
The description explains the core function but leaves out crucial context: the effect of the configurable 'action' parameter, expected output, and behavioral implications. Given the tool's parameter and sibling ecosystem, it is incomplete.
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% because the 'action' parameter includes a description. The tool description adds no extra meaning beyond the schema, so it meets the baseline but does not enhance parameter understanding.
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 with a specific verb and resource: 'Take a fullscreen screenshot'. This distinguishes it from sibling tools such as area, window, or scrolling captures.
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?
No guidance is provided on when to use this tool versus alternatives like cleanshot_capture_area or cleanshot_all_in_one. There is no mention of prerequisites, exclusions, or decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it reveals nothing beyond the action itself. It does not mention side effects, prerequisites, file-type constraints, or what 'pinned screenshot' entails.
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, front-loaded sentence with no wasted words. It efficiently communicates the core action for a simple tool.
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 with one well-documented parameter and no output schema, so the description plus schema is minimally sufficient for invocation. However, it lacks any context about when to use the tool or how it differs from related open/pin tools.
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%, and the only parameter, filepath, has a clear description ('Path to the PNG/JPEG file to pin'). The tool description adds no extra semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Open a file as a pinned screenshot', which uses a specific verb and resource. It clearly indicates the tool takes an existing image file and pins it, distinguishing it from capture-focused siblings like cleanshot_capture_area.
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?
No guidance is provided about when to use this tool versus alternatives such as cleanshot_open_from_clipboard or cleanshot_open_history. It only states the action without any context or exclusions.
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 of behavioral disclosure. It only states 'Open CleanShot's Record Screen mode', which is ambiguous—it could mean launching a UI or immediately starting a recording. No mention of side effects, permissions, or whether the recording saves automatically leaves the behavior opaque.
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, front-loaded sentence with no unnecessary words. It is appropriately sized for its purpose, though it could include more contextual detail without becoming verbose.
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?
The tool has 5 optional parameters defining a recording area and no output schema or annotations. The description does not explain how these parameters relate to the recording mode, what happens after opening, or when to use this over sibling tools. This is a significant gap for a potentially complex 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?
The input schema documents all 5 parameters with descriptions (100% coverage), so the baseline of 3 applies. The tool description itself adds no additional parameter semantics beyond the schema, but the schema already provides sufficient meaning for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Open' with the resource 'Record Screen mode', clearly identifying the tool's function and distinguishing it from sibling capture tools like cleanshot_capture_area. However, it is minimal and does not elaborate on the recording behavior, which prevents a perfect score.
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?
No guidance is provided regarding when to use this tool versus alternatives such as cleanshot_capture_area or cleanshot_capture_fullscreen. The description gives no context on use cases, prerequisites, or exclusions, leaving the agent without selection criteria.
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?
No annotations are provided, so the description carries the full burden. It only states that the tool opens a mode, without disclosing what happens after opening, whether it blocks, requires preconditions, or how the 'action' parameter affects behavior. Minimal 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word earns its place, and it is appropriately sized for a tool performing a simple action.
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 tool with one optional parameter and no output schema, the description is minimally viable. However, it lacks context about when to use it and the behavior after opening the mode, leaving some gaps in completeness.
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% for the single 'action' parameter, which includes an enum and description. The description itself adds no parameter information, so the baseline score of 3 applies, as the schema already provides adequate semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open CleanShot's Capture Window mode' uses a specific verb and resource, clearly indicating the tool's function. It distinguishes itself from sibling capture tools by targeting a dedicated window-capture mode, though it could provide more detail on what this mode entails.
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 guidance on when to use this tool versus alternatives like cleanshot_capture_area or cleanshot_capture_fullscreen. It lacks context, exclusions, or mention of alternative tools, offering only implied usage from the name.
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?
No annotations are provided, so the description must disclose behavioral traits, but it only restates the action. It does not mention whether CleanShot is launched, whether the file is modified/read-only, or what happens on invalid paths.
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?
Single sentence, direct, no filler, and front-loaded with the verb. Every word 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 one-parameter tool the description plus schema is minimally sufficient, but it lacks usage context and behavioral details (e.g., when to choose this over open_from_clipboard, app launch behavior). With no annotations or output schema, slightly more context would be needed for full completeness.
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?
Input schema already fully describes the single filepath parameter with coverage 100%, so the description adds no new parameter information. Baseline of 3 is appropriate because schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies verb 'open' and resource 'a file in CleanShot's Annotate tool', making the core function obvious. It does not explicitly contrast with sibling tools like cleanshot_open_from_clipboard or cleanshot_open_history, so it stops short of full 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as cleanshot_open_from_clipboard or capture tools. The statement only describes the action without context, prerequisites, or exclusions.
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?
No annotations are present, so the description carries the full burden. It fails to disclose what happens after text is recognized (e.g., copied to clipboard), how the result is returned, or any side effects like UI launching or clipboard modification. The linebreaks parameter hints at clipboard behavior, but that is in the schema, not the description.
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 communicates the primary functionality without extraneous words. It earns every word, maintaining a clear subject and two direct verbs.
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?
With 7 parameters, no output schema, and no annotations, the description is too brief to fully explain how parameters interact (e.g., screen capture vs file mode), what the output looks like, or any behavioral outcomes. The schema covers parameter descriptions, but the overall context remains incomplete for an agent to confidently invoke the tool.
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% for all 7 parameters, providing clear explanations of coordinates, display, filepath, and linebreaks. The description adds no additional parameter context beyond what the schema already provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as CleanShot's Text Recognition (OCR) feature, with two distinct actions: opening the OCR tool or extracting text from a file. It is specific enough to distinguish from sibling capture tools, though it does not 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for OCR but does not explicitly state when to use it vs. other capture tools, nor does it provide exclusions or prerequisites. The dual nature (open tool or extract from file) gives some context, but no direct guidance on parameter combinations or when to choose one mode over the other.
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?
No annotations exist, so the description carries the full burden. It only repeats the action without disclosing behavioral details such as reversibility, effect on multiple displays, or interaction with the show/toggle siblings. This leaves the agent without important context.
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 wasted words. It is easily scannable and front-loaded with the key action.
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 very simple with no params and no output schema, so the minimal description covers the core action. However, it lacks any context about related tools or state changes, making it only minimally complete for an agent deciding between hide/show/toggle actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty schema). With no parameters to explain, the description does not need to add any parameter semantics, so a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the specific action (hide) and resource (desktop icons). However, it does not differentiate from sibling tools like 'cleanshot_toggle_desktop_icons' or 'cleanshot_show_desktop_icons', so it scores a 4 rather than 5.
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?
No guidance is provided on when to use this tool versus the sibling tools. There is no mention of alternatives or exclusions, so the agent receives no decision-support information.
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 of behavioral disclosure. It only states the action without explaining side effects, prerequisites (e.g., CleanShot must be running), or what the user sees after opening history. This is a minimal description with no additional context.
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, focused sentence with no waste. It conveys the core action and object efficiently, making it exactly as concise as needed for a parameterless tool.
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?
Given the tool's simplicity, the description is adequate but not fully complete. It lacks context about what 'capture history' displays and how it relates to similar siblings like 'restore_recently_closed'. This could lead to ambiguity, so a more contextual explanation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty. According to the rubric, 0 params yields a baseline of 4. The description does not need to explain parameter details since none exist, and no gaps are present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open CleanShot's capture history' uses a specific verb and resource, clearly distinguishing it from sibling tools like 'open_settings' or 'open_annotate'. However, it could more explicitly state what 'capture history' entails (e.g., a list of recent screenshots) to fully avoid ambiguity.
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?
No guidance is provided about when to use this tool versus alternatives. The description does not mention exclusions or compare with siblings such as 'cleanshot_restore_recently_closed', leaving the agent without enough context for tool selection.
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 mentions restoring a file, implying an action that changes state, but does not disclose what happens if there is no history, whether it opens in a new window, or any side effects. The behavior is stated only at a high level.
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?
A single, well-structured sentence that is front-loaded and contains no filler. Every word earns its place, making it easy to parse 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?
Given the simplicity of the tool (no parameters, no output schema, no annotations), the description is adequate but leaves out potential edge cases and side effects. It is useful for a basic understanding but does not fully prepare an agent for all operational nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the baseline for such tools is 4. The description adds context about the specific scope ('most recently closed file from history'), which is helpful even though no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Restore') and a clear resource ('the most recently closed file from history'). It distinguishes itself from sibling tools like 'cleanshot_open_history' by focusing on the most recently closed item rather than a general history view.
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?
No guidance is provided on when to use this tool versus alternatives such as 'cleanshot_open_history' or 'cleanshot_open_from_clipboard'. The description does not mention any exclusions, prerequisites, or scenarios where it would be inappropriate.
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 only says 'Open' and 'with self-timer' without disclosing behavioral traits such as the duration of the timer, what happens after the capture, or any side effects. The action parameter is not mentioned, leaving key behavior undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the action and resource. However, its brevity borders on under-specification, which prevents a perfect score.
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 optional parameter, no output schema), so the description is not grossly inadequate. Still, it omits context about the self-timer's behavior (e.g., configurable delay) and does not reference the action parameter, leaving room for improvement.
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% (the action parameter has a description 'Action to perform after capture'), so baseline is 3. The tool description adds no additional meaning about the parameter, so it neither improves nor degrades the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Open') and resource ('CleanShot's Capture Area mode with self-timer'), clearly distinguishing this tool from siblings like cleanshot_capture_area. However, it does not elaborate on what the self-timer does (e.g., delay before capture), so it is clear but not fully explicit.
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 through the name and phrase 'with self-timer', suggesting it is for delayed area captures. No explicit guidance on when to use it versus alternatives (e.g., immediate capture tools) or when not to use it is provided.
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 of behavioral disclosure. It only states the core action without revealing what happens if there is no previous screenshot, whether the action parameter affects capture, or whether any side effects occur. The minimal text leaves significant behavioral questions unanswered.
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, front-loaded sentence with no filler. It is appropriately concise for the tool's simplicity, with every word earning 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?
The tool is simple, but the description lacks behavioral details such as prerequisites (needing a previous screenshot) and the relevance of the action parameter. The absence of an output schema and annotations means the description should offer more context, but given the low complexity, it is minimally viable.
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 provides 100% coverage for the parameter with a clear description and enum values, so the baseline is 3. The tool description adds no additional parameter information, but the schema is sufficiently descriptive, so no penalty is applied.
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 with a specific verb ('repeat') and resource ('last taken screenshot'), which distinguishes it from sibling tools like capture_area or capture_fullscreen. It is concise 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 Guidelines2/5
Does 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. It does not mention that it should be used when the user wants to retake the same screenshot area, nor does it exclude any scenarios. Sibling tool names provide context, but the description offers no explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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, but it merely repeats the tool name without adding any details about side effects, idempotency, or system state. It provides no information beyond what the name already implies.
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 communicates the purpose directly with no wasted words. Given the tool's simplicity and lack of parameters, this length is appropriate and well-structured.
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 tool with no parameters and no output schema, the description is minimally sufficient, but it lacks context about the sibling tools (toggle/hide) that would help an agent make an appropriate selection. It also does not clarify behavior when desktop icons are already visible, leaving a minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so there is no parameter burden to explain. The baseline for 0 parameters is 4, and the description does not need to elaborate on 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 'Show desktop icons' clearly states the action (show) and the resource (desktop icons), and effectively distinguishes it from sibling tools like 'cleanshot_hide_desktop_icons' and 'cleanshot_toggle_desktop_icons'. It is a specific and unambiguous purpose statement.
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 offers no guidance on when to use this tool versus alternatives. It does not mention the sibling tools that hide or toggle desktop icons, nor does it provide any context for choosing this over them.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, error conditions, whether it opens the overlay, or if the file is moved/copied. For a mutation tool, this is a significant gap in transparency.
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 with zero fluff or redundancy. It clearly and directly conveys the core action without unnecessary words, making it highly efficient for an agent 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 tool has no annotations and no output schema, the description should provide more context about what happens after adding the file, any side effects, or prerequisites. It currently only states the action, leaving important behavioral context undisclosed. The description is not complete for a mutation tool.
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 describes the single parameter 'filepath' with supported formats (PNG/JPEG/MP4), so description-level parameter coverage is not needed. Baseline is 3 because schema coverage is 100%, and the description adds no additional parameter meaning beyond what the schema provides.
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 ('Add') and clearly identifies the resource ('file to CleanShot's Quick Access Overlay'). This distinguishes it from sibling tools like capture, pin, or record actions. The purpose is immediately understandable 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the description: use when wanting to add a file to the Quick Access Overlay. However, there is no explicit guidance on when not to use this tool, any prerequisites, or alternatives. It lacks exclusions or comparative context, so it falls at 'implied usage' level.
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 of behavioral disclosure. It merely says 'toggle' without specifying that it flips the current state, any side effects, or system requirements. This is minimal and leaves the agent guessing about the actual 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that immediately states the action and target. It avoids any unnecessary detail, making it highly concise and efficiently front-loaded.
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 no-parameter tool, the description is minimally adequate. However, given the surrounding sibling tools for explicit show/hide, it lacks the contextual differentiation needed to fully inform the agent. The absence of any mention of return value or state behavior leaves a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The description adds no parameter information, but none is needed; the baseline of 4 is appropriate for a no-parameter tool.
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 toggles desktop icon visibility, using a specific verb and resource. It distinguishes itself from sibling tools like 'cleanshot_show_desktop_icons' and 'cleanshot_hide_desktop_icons' by implying the toggle behavior.
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?
No guidance is given on when to use this toggle tool versus the explicit hide/show siblings. The description offers no context about state-dependent behavior or alternatives, leaving the agent without direction for tool selection.
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 of behavioral disclosure. It only states the primary action and does not mention edge cases such as what happens if the clipboard is empty or whether existing annotations are replaced. This is a significant gap for a tool that depends on system clipboard state.
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 directly conveys the tool's functionality with no filler or redundant information. It is appropriately sized for a tool with no parameters.
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 tool with no parameters, no output schema, and a simple action, the description provides sufficient context to understand the core behavior. However, it could be slightly more complete by noting the prerequisite of having an image in the clipboard and potential error behavior, but the current level is adequate for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. With no parameters to explain, the description does not need to add parameter-level detail, and the baseline score of 4 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 action ('Open') and the resource ('image from clipboard') with the target context ('CleanShot's Annotate tool'). It is specific and distinguishes itself from the sibling tool 'cleanshot_open_annotate' by explicitly mentioning the clipboard source.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., having an image copied) or when to prefer this over 'cleanshot_open_annotate'. The usage context is only implied.
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?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing side effects, prerequisites, or what happens if the app is not running. The behavioral context is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the action and optional parameter. It is appropriately sized for a tool with such a simple purpose, with no redundant content.
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 well-documented optional parameter and no output schema, the description is largely sufficient. It could optionally mention that the app may be brought to the foreground, but this is not essential given the clarity of the action.
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 provides 100% coverage with a clear description and enum for the tab parameter. The description's 'optional tab' adds no new meaning beyond the schema's explicit required parameter count of zero. Baseline 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 identifies the action ('Open CleanShot settings') and the resource (settings), and mentions the optional tab, distinguishing it from sibling tools that capture, record, or pin content.
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 when the user needs to access CleanShot settings, but it provides no explicit when-to-use vs alternatives or exclusions. Given that the tool's purpose is unique among siblings, this is acceptable but not exemplary.
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:

[![cleanshot-mcp MCP server](https://glama.ai/mcp/servers/jdorfman/cleanshot-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jdorfman/cleanshot-mcp)

Score Badge

Copy to your README.md:

[![cleanshot-mcp MCP server](https://glama.ai/mcp/servers/jdorfman/cleanshot-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jdorfman/cleanshot-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/jdorfman/cleanshot-mcp'

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