Skip to main content
Glama

Server Quality Checklist

67%
Profile completionA complete profile improves this server's visibility in search results.
  • Latest release: v1.0.0

  • Disambiguation5/5

    Each tool targets a distinct input source: local file path, base64 content, URL, and batch of paths. The descriptions clearly differentiate the tools, and the batch tool's multi-image purpose avoids confusion with single-image processing.

    Naming Consistency4/5

    Three tools follow the 'ocr_by_<source>' pattern clearly, but 'ocr_batch' deviates by omitting 'by'. This is a minor inconsistency that does not harm readability.

    Tool Count5/5

    Four tools are well-scoped for an OCR server, covering the primary input methods (file, content, URL, batch) without unnecessary redundancy. The count feels complete and focused.

    Completeness5/5

    The tool surface covers the core OCR workflows for local files, base64 data, URLs, and batch processing. There are no obvious gaps for a typical OCR use case, making the set comprehensive.

  • Average 4/5 across 4 of 4 tools scored.

    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 is passing
  • 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

  • Behavior3/5

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

    With no annotations provided, the description carries the full burden of disclosing behavior. It does explain the effects of parameters like auto_enhance ('automatically enhance contrast and sharpness'), rotate ('based on EXIF'), and binarize, which adds some behavioral context. However, it does not disclose limitations (e.g., image size, supported formats), error handling, or whether the image is stored or transmitted beyond the operation.

    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 appropriately sized and begins with a clear one-sentence summary. The parameter list is structured and each item is explained concisely. It does repeat parameter names already present in the schema, but adds necessary semantic value, so the length is justified. The Returns section is brief but present.

    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 has 5 parameters, no annotations, and no output schema. The description covers all parameters and states the return type as 'OCR 识别结果', but this is vague. It does not specify the exact structure of the result (especially for output_format=json or structured), nor does it mention input constraints or error scenarios. Given the absence of an output schema, more detail about the return value would be valuable, so completeness is only moderate.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters5/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The input schema has no parameter descriptions (coverage 0%), so the description must compensate. It does so thoroughly: image_base64 is described as Base64 encoded with support for data:image/ prefix, output_format lists the valid values (plain/json/markdown/structured), and auto_enhance, rotate, and binarize each have plain-language meanings. This fully explains the parameters 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 clearly states the tool's function: '对 Base64 编码的图像执行 OCR 识别' (perform OCR on Base64-encoded images). It specifies both the action (OCR) and the resource (Base64 image), and the name 'by_content' distinguishes it from sibling tools like ocr_by_path and ocr_by_url.

    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 the alternatives. The description does not mention ocr_by_path, ocr_by_url, or ocr_batch, nor does it explicitly state that this tool is for Base64 input as opposed to file paths or URLs. The name implies the distinction, but the description itself offers no usage direction.

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

  • Behavior3/5

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

    With no annotations, the description carries the full burden. It discloses behavioral traits like rotation based on EXIF, binarization, and auto-enhancement, which adds value. However, it does not mention potential side effects, error handling, redirect behavior, or details of the return result beyond a vague 'OCR recognition result.'

    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 efficiently organized as an Args list, with each line earning its place. It is front-loaded with the main purpose and avoids redundant filler, maintaining a compact and scannable format.

    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?

    While the parameter details are solid, the absence of an output schema means the description should clarify return value structure or formats. It only states 'OCR recognition result' without explaining differences between output formats or error cases, leaving some contextual gaps for a 6-parameter tool.

    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?

    Schema description coverage is 0%, so the description fully compensates by explaining each parameter's purpose, including enumerating output_format options (plain/json/markdown/structured). This goes well beyond the schema's bare types and defaults, adding meaningful context for correct invocation.

    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 'Perform OCR recognition on URL images' using a specific verb and resource. It distinguishes from sibling tools like ocr_by_path and ocr_by_content by explicitly targeting URL-based images.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines3/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The usage context is implied via the tool name and description (use for images accessible via URL), but there is no explicit guidance on when to prefer this over alternatives or any exclusions. It lacks the explicit alternative naming seen in high-quality examples.

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

  • Behavior3/5

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

    No annotations are provided, so the description carries the full burden. It discloses processing behaviors such as auto_enhance, rotate (based on EXIF), and binarize, and mentions returns, but it doesn't describe limitations, error handling, or performance implications.

    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 well-structured docstring with clear Args and Returns sections, front-loaded purpose, and no unnecessary prose. Every sentence contributes useful information.

    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 description provides a good overview but lacks a detailed return structure (no output schema) and doesn't explain how the returned results are organized. Additionally, it doesn't position the tool relative to its siblings, leaving some usage context unclear.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters5/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The Args section explains all five parameters with meaningful descriptions despite 0% schema description coverage. For example, output_format lists allowed values (plain/json/markdown/structured) and rotate specifies EXIF-based rotation. This fully compensates for the schema's lack of descriptions.

    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 '批量 OCR - 对多张图像执行 OCR 识别' (Batch OCR - perform OCR on multiple images), using a specific verb and resource with batch scope. This distinguishes it from the sibling tools ocr_by_path, ocr_by_content, and ocr_by_url, which are likely for single images.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines3/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description implies usage for multiple images but does not explicitly state when to use this tool vs alternatives. It lacks a clear 'when not to use' or mention of sibling tools for single-image scenarios.

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

  • Behavior3/5

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

    With no annotations provided, the description carries the burden of behavioral disclosure. It explains the operation on local files and details the preprocessing options (auto_enhance, rotate, binarize), but it does not mention error behavior, access requirements, or the nature of the return value beyond 'OCR 识别结果'. This is adequate but not comprehensive.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is well-structured with a concise one-line purpose followed by a bulleted Args list and a Returns line. Every sentence earns its place, and there is no redundancy or fluff.

    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?

    The description covers the essential elements: purpose, all parameters, and the return value. With no output schema and no annotations, it handles complexity reasonably well. It could be improved by mentioning supported image formats or error handling, but the core usage is adequately specified.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters5/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema description coverage is 0%, but the description fully compensates by explaining each parameter: image_path (absolute/relative path), output_format (plain/json/markdown/structured), auto_enhance (enhance contrast/sharpness), rotate (based on EXIF), and binarize. This adds significant meaning beyond the bare schema titles and defaults.

    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: '对本地图像文件执行 OCR 识别' (perform OCR on local image files). This specifies both the verb (perform OCR) and the resource (local image files), and the 'local' qualifier effectively distinguishes it from sibling tools like ocr_by_url and ocr_by_content.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description clearly indicates the tool is for local image files, giving context for when to use it. However, it does not explicitly mention alternatives or state when NOT to use it, so it falls short of a 5.

    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

rapidocr-mcp MCP server

Copy to your README.md:

Score Badge

rapidocr-mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/bitfarer/rapidocr-mcp'

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