Skip to main content
Glama
ymeng98

ddddocr Smithery MCP Server

by ymeng98
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

ddddocr Smithery MCP Server

A Model Context Protocol (MCP) server for ddddocr that can be deployed on Smithery, providing OCR and CAPTCHA recognition capabilities to AI agents.

Features

  • OCR Recognition: Extract text from images with high accuracy

  • Text Detection: Identify and locate text regions in images

  • Slide CAPTCHA Solving: Match sliding puzzle pieces and find positions

  • Color Filtering: Process images with specific color filters

  • Probability Output: Get confidence scores for OCR results

Related MCP server: Crawl4AI MCP Server

Quick Start

Deploy on Smithery

  1. Fork this repository to your GitHub account

  2. Visit Smithery and connect your GitHub account

  3. Deploy from your forked repository

  4. Use the provided Smithery URL in your Claude Desktop configuration

Local Development

# Install dependencies
npm install

# Build the project
npm run build

# Run in development mode
npm run dev

# Run tests
npm test

Usage

This MCP server provides the following tools:

ocr_recognize

Extract text content from images.

Parameters:

  • image (required): Base64 encoded image data

  • probability (optional): Return confidence scores

  • charset_range (optional): Limit character set (e.g., "0123456789")

  • color_filter (optional): Apply color filters

  • png_fix (optional): Fix transparent PNG images

text_detection

Detect text regions and bounding boxes in images.

Parameters:

  • image (required): Base64 encoded image data

slide_match

Match sliding CAPTCHA pieces to find correct positions.

Parameters:

  • target_image (required): Base64 encoded puzzle piece

  • background_image (required): Base64 encoded background with gap

  • simple_target (optional): Whether target has transparency

slide_comparison

Compare images to find sliding distance for CAPTCHA solving.

Parameters:

  • target_image (required): Base64 encoded image with gap

  • background_image (required): Base64 encoded complete image

Configuration

Add this server to your Claude Desktop configuration:

{
  "mcpServers": {
    "ddddocr": {
      "command": "npx",
      "args": ["-y", "@smithery/ddddocr-mcp@latest"]
    }
  }
}

Or if deployed on Smithery:

{
  "mcpServers": {
    "ddddocr": {
      "command": "npx",
      "args": ["-y", "@smithery/cli", "run", "your-deployment-url"]
    }
  }
}

Architecture

This server acts as a bridge between MCP clients and the ddddocr service:

  1. MCP Layer: Handles protocol communication with AI agents

  2. Service Layer: Manages ddddocr process lifecycle

  3. API Layer: Communicates with ddddocr HTTP endpoints

  4. Processing Layer: Handles image processing and result formatting

Requirements

  • Node.js 18+

  • ddddocr executable (automatically downloaded in Docker)

  • Sufficient memory for image processing (recommend 512MB+)

Security

  • Uses non-root user in Docker container

  • Validates all input parameters

  • Implements proper error handling

  • No persistent storage of user images

License

MIT - See LICENSE file for details

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Add tests if applicable

  5. Submit a pull request

Support

For issues and questions:

Available Tools

4 tools
ocr_recognizeC

Perform OCR recognition on an image to extract text content

ParametersJSON Schema
NameRequiredDescriptionDefault
imageYesBase64 encoded image data
png_fixNoFix transparent PNG images
probabilityNoWhether to return confidence probability
color_filterNoColor filters to apply (e.g., ["red", "blue"])
charset_rangeNoCharacter set range for recognition (e.g., "0123456789" for digits only)

TDQS

C2.8/5.0
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 behavioral disclosure burden. It only states the basic function and does not describe output format, failure modes, image requirements, or side effects, leaving important behavior unspecified.

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 short and easy to read, but the phrase 'OCR recognition' is redundant and the sentence provides only a minimal summary. It is concise without being structured or informative enough to guide effective use.

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 five parameters, no output schema, no annotations, and related sibling tools, this description is too thin. It does not explain what the returned text looks like, how base64 input should be prepared, or how this tool relates to text_detection.

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% description coverage, so the baseline is 3. The tool description adds no parameter-level meaning, but the schema already documents each parameter clearly, including defaults and examples.

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 action (perform OCR) on a specific resource (an image) with a clear outcome (extract text content). However, it does not distinguish this tool from the sibling text_detection, and 'OCR recognition' is slightly redundant.

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 compared to text_detection, slide_match, or slide_comparison. There are no exclusions, prerequisites, or alternative-selection hints, so the agent must infer usage from the name alone.

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

slide_comparisonA

Compare two images to find the sliding distance for captcha solving

ParametersJSON Schema
NameRequiredDescriptionDefault
target_imageYesBase64 encoded image with gap
background_imageYesBase64 encoded complete background image

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations and no output schema, the description must carry the behavioral burden. It conveys that the tool performs a comparison and returns a sliding distance, but it does not disclose output units, return format, error behavior, or edge-case limitations. The behavior is minimally transparent but not detailed.

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 no wasted words. It front-loads the action and immediately states the tool's purpose.

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 two-parameter tool with fully described inputs, the description is mostly adequate. However, the lack of an output schema makes the absence of an explicit return-value description noticeable, and the lack of differentiation from `slide_match` leaves some selection ambiguity.

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 parameter descriptions already explain which image is the target and which is the background. The tool description adds no parameter-level meaning beyond restating that two images are involved.

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 the action ('Compare two images') and the goal ('find the sliding distance'), and the captcha-solving context gives it a specific purpose. However, it does not differentiate from the sibling tool `slide_match`, whose name suggests a nearly identical operation.

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 phrase 'for captcha solving' implies a use context, so an agent gets some situational signal. But the description gives no explicit guidance about when to use this tool instead of alternatives like `slide_match`, nor any exclusions or prerequisites.

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

slide_matchC

Match sliding captcha pieces to find the correct position

ParametersJSON Schema
NameRequiredDescriptionDefault
target_imageYesBase64 encoded target piece image
simple_targetNoWhether the target is a simple image without transparency
background_imageYesBase64 encoded background image with gap

TDQS

C2.9/5.0
Behavior2/5

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It only states the intended action without revealing expected outputs, limitations, or side effects. There is no mention of what the tool returns (e.g., position coordinates) or any other behavioral characteristics.

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 immediately communicates the core purpose. It is well-structured and front-loaded, with no unnecessary words.

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 is too minimal for a tool with no annotations and no output schema. It fails to explain what 'correct position' means, what the tool returns, or how the input images should be interpreted. An agent would need more context to invoke this correctly beyond the parameter names and types.

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%, so the input schema already documents each parameter. The description adds no extra meaning beyond the schema, which meets the baseline for this dimension.

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 ('Match') and a specific resource ('sliding captcha pieces'), clearly indicating the tool's function. It does not, however, distinguish this from the sibling 'slide_comparison', leaving potential ambiguity about which tool to choose.

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 tool versus alternatives like 'slide_comparison' or 'ocr_recognize'. The description states only what the tool does, not when it should be selected or any exclusions.

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

text_detectionA

Detect text regions and bounding boxes in an image

ParametersJSON Schema
NameRequiredDescriptionDefault
imageYesBase64 encoded image data

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly states the core behavior, but does not disclose the return format, coordinate conventions, confidence scores, or failure modes. For a simple non-mutating detection tool this is acceptable but not rich.

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?

One clean, front-loaded sentence that states the verb and output object with zero filler. Every word contributes to understanding the tool's purpose.

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 one-parameter detection tool with no output schema, the description conveys the essential outcome: text regions and bounding boxes. It is complete enough for basic invocation, though it would benefit from a brief note about returning coordinates and when to use ocr_recognize instead.

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 single parameter 'image' is already fully documented by the schema as 'Base64 encoded image data' (100% coverage). The description adds no additional semantic detail about format requirements, size limits, or accepted encodings, so it stays at the baseline.

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 ('Detect'), names a clear resource ('text regions and bounding boxes in an image'), and implicitly distinguishes this from sibling ocr_recognize by focusing on geometry rather than text extraction. An agent can immediately understand what the tool does.

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 gives no guidance about when to choose text_detection over ocr_recognize or the other siblings. There is no explicit 'use this when detection is needed' or 'use ocr_recognize when text extraction is needed', leaving the agent to infer selection criteria.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv1.0.0
    • First observedocr_recognize
    • First observedslide_comparison
    • First observedslide_match
    • First observedtext_detection
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored across 4 tools

Disambiguation2/5

ocr_recognize and text_detection are fairly distinguishable, but slide_match and slide_comparison both target sliding captcha solving with descriptions that seem to describe the same task. The boundary between matching pieces and comparing images for a sliding distance is unclear.

Naming Consistency3/5

All names use snake_case and have recognizable prefixes, but verb/noun forms are inconsistent: ocr_recognize uses a verb while text_detection and slide_comparison use nouns. slide_match and slide_comparison follow a common slide_ pattern, yet the overall set is not uniformly structured.

Tool Count4/5

Four tools is a reasonable size for an OCR and captcha-focused server. However, slide_match and slide_comparison appear redundant, so the count is acceptable but not perfectly lean.

Completeness4/5

The core OCR recognition, text detection, and sliding captcha workflows are covered. Minor gaps include lack of a dedicated captcha classification tool or preprocessing utilities, but they are likely workarounds given the stated scope.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches