OCR anything on your Mac screen from Claude, Cursor, or any MCP client.
This is the official Model Context Protocol server for FreezeText — a free native macOS app that freezes the screen and extracts text via Apple Vision OCR. Whether running videos, disappearing popups, protected PDFs, or hover tooltips — FreezeText makes any visible text copyable.
You need the FreezeText app installed and running with its HTTP API enabled (Settings → API). This MCP server talks to the app's local API. Get FreezeText (free) at store.juergenkoller.software/apps/freezetext.
"Claude, OCR whatever is on my screen right now and summarize it."
"Cursor, run OCR on this screenshot (base64) and extract the invoice number."
"Search my FreezeText history for everything containing 'tracking number'."
The MCP server exposes 12 tools:
Category | Tools |
Capture & OCR |
|
History |
|
OCR config |
|
All OCR runs locally via Apple Vision Framework — no cloud, no data transmission.
Related MCP server: Vison-MCP
macOS 14 (Sonoma) or later
FreezeText app installed and running — get it free here — with the HTTP API enabled in Settings
Swift 5.9+ (Xcode 15+) if building from source
git clone https://github.com/juergenkoller-software/freezetext-mcp.git
cd freezetext-mcp
swift build -c release
# Binary: .build/release/FreezeTextMCPSee Releases.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"freezetext": {
"command": "/path/to/FreezeTextMCP",
"env": {
"FREEZETEXT_API_PORT": "9876",
"FREEZETEXT_API_TOKEN": "your-token-if-set"
}
}
}
}FREEZETEXT_API_TOKEN is only required if you set an API token in FreezeText's Settings.
claude mcp add freezetext /path/to/FreezeTextMCP \
--env FREEZETEXT_API_PORT=9876Same pattern — stdio MCP server, configured via the two env vars above.
┌────────────────┐ JSON-RPC stdio ┌────────────────┐ HTTP(+Bearer) ┌────────────────┐
│ Claude/Cursor │ ───────────────► │ FreezeTextMCP │ ────────────────► │ FreezeText.app│
│ (MCP client) │ ◄─────────────── │ (this repo) │ ◄──────────────── │ (port 9876) │
└────────────────┘ └────────────────┘ └────────────────┘This is a full MCP server (built on the official modelcontextprotocol/swift-sdk) that maps MCP tool calls to FreezeText's local HTTP API. The OCR engine (Apple Vision), screen capture, and history storage live in the FreezeText app.
Variable | Default | Description |
|
| Port of FreezeText's local HTTP API |
| (none) | Bearer token — only if set in FreezeText Settings |
FreezeText is a free native macOS OCR utility. Highlights:
Free, no subscription, no sign-up
Lightning-fast OCR — Apple Vision Framework, under 0.3 seconds
Freeze the screen — capture text from videos, popups, protected PDFs, hover tooltips
Global hotkey (⌘⇧7)
QR code & barcode detection
Searchable history with color tags + JSON/CSV export
HTTP API (40+ endpoints) — this MCP server is built on it
100% local — no cloud, no data transmission
→ Get FreezeText free at store.juergenkoller.software
MIT — see LICENSE. This MCP server is open source; the FreezeText app is free (proprietary).
MCP server bugs: open an issue
App support: support@juergenkoller.software
Built by Juergen Koller Software GmbH.
Adds a text entry to the capture history.
| Name | Required | Description | Default |
|---|---|---|---|
| displayName | No | Optional display name for the entry | |
| text | Yes | The text to store |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It indicates a write operation but does not mention whether entries are appended, overwritten, or limited in any way. No error conditions, permissions, or other side effects are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that conveys the core purpose without extraneous information. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should include information about return values, side effects, or constraints. It fails to address these, making it incomplete for an AI agent to understand the tool's full impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (text and displayName). The description adds no additional meaning beyond what the schema already states. Baseline score 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a text entry to the capture history, using a specific verb and resource. However, it does not explain what 'capture history' is, which may cause confusion if the concept is not well-known.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (e.g., list_history, search_history). No conditions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Captures a specific screen region and recognizes its text via OCR. Coordinates in screen points.
| Name | Required | Description | Default |
|---|---|---|---|
| height | Yes | Height of the region | |
| width | Yes | Width of the region | |
| x | Yes | X coordinate of the region's top-left corner | |
| y | Yes | Y coordinate of the region's top-left corner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies a read operation but does not confirm non-destructive behavior, side effects, or what 'captures' entails (e.g., screenshot vs. selection).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and result, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 4 required params, the description should hint at return value or effect, but omits any such information, leaving agents uncertain about what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter descriptions, and the description adds 'Coordinates in screen points,' clarifying the unit beyond the schema's coordinate labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screen region and performs OCR, distinguishing it from siblings like capture_screen (full screen) and ocr_image (OCR on existing image).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a hint about coordinate units but does not explicitly state when to use this tool versus alternatives (e.g., capture_screen for full screen, ocr_image for separate OCR).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Freezes the screen and recognizes text via OCR (Apple Vision). Returns the recognized text from the current screen.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses 'freezes the screen' and uses Apple Vision, but lacks details on permissions, potential UI disruption, error handling, or behavior when no text is detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states action, second states return value. No redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and return, but given no output schema, it should clarify return format (e.g., string, empty string if no text). The phrase 'freezes the screen' could be elaborated to indicate it's a single capture. Adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100% by default. The description adds no parameter info, but none is needed. Baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Freezes the screen and recognizes text via OCR (Apple Vision).' It specifies the resource (the active screen) and the output (recognized text). This distinguishes it from siblings like 'capture_region' (region-specific) and 'ocr_image' (image file OCR).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'capture_region' for partial screen, 'ocr_image' for existing images). No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes all history entries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description is straightforward but lacks behavioral details such as irreversibility, confirmation, or side effects. Since no annotations are provided, the description could do more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, one sentence, no fluff. Front-loaded with the action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and simple action, the description is nearly complete. Could mention potential dangers of clearing all history.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is complete. The description adds no parameter info, but none is needed. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes all history entries, using a specific verb and resource. It distinguishes from the sibling tool delete_history_entry, which deletes a single entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like delete_history_entry. Missing context about bulk vs individual deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes a history entry by its UUID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | UUID of the history entry to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry the full burden of behavioral disclosure. It only states the basic function without mentioning side effects (e.g., permanent deletion), error conditions, or idempotency. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of seven words, conveying the essential information without any superfluous content. It is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output, the description is mostly complete. It could be improved by noting that the deletion is permanent or that the entry must exist, but it adequately covers the core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter 'id' is described in the schema). The description does not add additional meaning beyond what the schema provides (it merely restates that the ID is a UUID). Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deletes a history entry by its UUID.' clearly states the action (deletes), the target (history entry), and the identifier method (UUID). It effectively distinguishes from siblings like 'clear_history' (bulk delete) and 'get_history_entry' (retrieve).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'clear_history'. There is no mention of prerequisites, conditions, or exclusions. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exports the full capture history as JSON or CSV.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Export format: json or csv (default json) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the export behavior and format options but lacks details on side effects (e.g., no modification to history), permission requirements, or performance considerations. Adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, front-loading the core action and format. No superfluous information; every word is purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter input, no output schema, and no nested objects, the description is sufficiently complete. It conveys the tool's purpose and primary behavior, though a note on the returned data (e.g., file download) would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description merely restates the schema's parameter description ('json or csv default json'). It adds no additional semantic meaning beyond what the schema already provides, meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Exports' and the resource 'full capture history' with format options (JSON or CSV). It distinguishes from sibling tools like list_history and get_history_entry by specifying it exports the entire history in bulk format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exporting full history but does not provide explicit guidance on when to use this tool versus alternatives like list_history or search_history, nor does it mention when not to use it. Usage context is implied from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a single history entry by its UUID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | UUID of the history entry |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states 'Returns' which implies a read-only operation, but it does not disclose any potential side effects, authentication needs, or rate limits. The transparency is adequate 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.
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 and efficient, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, yet the description does not mention the return value format or structure. For a retrieval tool, this omission could leave an agent uncertain. However, the tool is simple with one parameter, so it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond the input schema. The schema already describes the 'id' parameter as 'UUID of the history entry', and the tool description merely restates that. With 100% schema coverage, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a single history entry by UUID. It uses a specific verb and resource, and the name distinguishes it from siblings like 'list_history' and 'search_history' which handle multiple entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention when-not-to-use, prerequisites, or which sibling tools might be more appropriate for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the currently configured OCR recognition languages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that it returns configured languages, but does not confirm it is read-only, non-destructive, or clarify access requirements. The description fails to add transparency beyond the name and input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is clear and to the point. No extraneous words or filler. The description is optimally concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for a minimal tool, but it lacks detail about the return format (e.g., list of language codes) and does not mention any side effects or state. Given no output schema, slightly more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description does not need to explain parameters. It adds no param info, but the baseline is 4 per the rubric since there are no parameters to describe. The description is adequate in this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns currently configured OCR recognition languages. The verb 'returns' and the specific resource 'OCR recognition languages' make the purpose unambiguous. It is easily distinguished from sibling tools like set_ocr_languages (which sets) and ocr_image (which performs OCR).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While it is implied that it is for reading configurations, the description does not mention prerequisites or suggest pairing with other tools (e.g., check languages before OCR). A score of 2 reflects the lack of practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all captured-text history entries (id, text, displayName, timestamp, colorTag).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states 'lists all' and the fields but omits details like ordering, pagination, limits, or any side effects. Given the simplicity of a zero-parameter list, the description is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that immediately conveys the tool's purpose and output. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists all returned fields, but without an output schema, additional context like sorting order or maximum number of entries would be helpful. However, for a simple list tool, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100% (empty schema). The description adds no parameter info, which is acceptable as there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all captured-text history entries and enumerates the returned fields (id, text, displayName, timestamp, colorTag). It distinguishes from sibling tools like search_history (which likely filters) and get_history_entry (single entry).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With siblings like search_history and get_history_entry, the description should indicate that this tool returns all entries without filtering, but it does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs OCR on a provided base64-encoded image (PNG or JPEG) and returns the recognized text.
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | Base64-encoded PNG or JPEG image data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the basic operation. Important aspects like error handling, image size limits, processing location (local/remote), or required permissions are omitted, leaving the agent without transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It front-loads key information: action, input format, and output. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is mostly complete. It specifies input and output clearly. However, lacking an output schema, it could briefly describe the return format (e.g., string or structured), but the current 'returns the recognized text' is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'image' parameter, with a description matching the tool's description. The tool description reinforces that the image must be base64-encoded and in PNG/JPEG format, but adds minimal new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: runs OCR on a base64-encoded image. It specifies supported formats (PNG or JPEG) and outputs recognized text, distinguishing it from sibling tools like capture_region or set_ocr_languages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. For example, it doesn't mention that the image must already be captured or that this tool complements capture tools. No exclusions or context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the capture history by text. Optional sorting by date or text.
| Name | Required | Description | Default |
|---|---|---|---|
| order | No | Sort order: asc or desc | |
| query | No | Search term (matches text and display name) | |
| sort | No | Sort field: date or text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden but only states basic functionality. It does not disclose read-only nature, performance impacts, or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose without redundant words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional params and no output schema, the description lacks details on default behavior when query is absent, output format, or examples. It is insufficient for inferring behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal value. It reiterates that sorting is optional, but the schema already describes each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'searches', the resource 'capture history', and the method 'by text'. It also mentions optional sorting, distinguishing it from siblings like list_history which likely list all entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., list_history, search engines). No context about prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sets the OCR recognition languages (e.g. en-US, de-DE).
| Name | Required | Description | Default |
|---|---|---|---|
| languages | Yes | List of language codes, e.g. ["en-US", "de-DE"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether languages are appended or replaced, error handling for invalid codes, or required permissions. Minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is efficient and front-loaded. However, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description is minimally adequate but lacks details on effects and idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a good description. The tool description adds an example but does not provide additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Sets' and the resource 'OCR recognition languages' with examples. It distinguishes from sibling get_ocr_languages by the action, but 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.
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 like get_ocr_languages or other settings tools. Lacks context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0add_historycapture_regioncapture_screenclear_historydelete_history_entryexport_historyget_history_entryget_ocr_languageslist_historyocr_imagesearch_historyset_ocr_languagesScored across 12 tools
Each tool has a clearly distinct purpose: capture actions (full screen vs region), history management (add, list, get, search, delete, clear, export), direct OCR on images, and language configuration. No overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., capture_region, clear_history, export_history). There are no deviations or mixed conventions.
With 12 tools covering screen capture, OCR, history management, and language configuration, the count fits the domain well. Each tool serves a necessary function without redundancy.
Core workflows (capture, OCR, history CRUD, export) are covered. The only minor gap is whether capture tools automatically add to history or require explicit add calls, but the set provides all needed operations.
Let ChatGPT, Claude & Cursor use your Mac: email, calendar, iMessage, Teams, files. Local, free.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
