idin9-doc-ocr-mcp

by idin9

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes: extraction, batch processing, scanner polling, record retrieval, review, contact management, and health checks. The only slight overlap is between ocr_batch_process and ocr_poll_scanner_share, since both process files from directory-like sources.
Naming Consistency4/5
All tools share the ocr_ prefix and use snake_case, which creates a strong predictable pattern. However, ocr_batch_process and ocr_system_health deviate from the strict verb_noun structure used by most other tools.
Tool Count5/5
Nine tools is well-scoped for an OCR invoice processing server covering ingestion, extraction, retrieval, review, contacts, and system health. Each tool serves a meaningful part of the workflow without redundancy or bloat.
Completeness4/5
The toolset covers the main OCR invoice lifecycle: extract, batch process, poll scanner, retrieve/list records, review low-confidence results, manage contacts, and check health. Minor gaps exist, such as no direct update/delete for processed invoice records outside the review flow or explicit reprocessing of failed items.
Average 3.1/5 across 9 of 9 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. Saying 'CRUD operations' hints at create, read, update, and delete side effects, but it does not clarify destructive behavior, idempotency, required preconditions, or what happens on invalid inputs. This is insufficient for a tool that can mutate data.
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 front-loaded, naming the resource immediately. However, the brevity comes at the cost of substance; the single sentence uses its space only for a broad statement and omits any operational details that would justify its usefulness.
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 three parameters, no annotations, no output schema, no enums, and several sibling tools, this description is incomplete. An agent cannot determine valid action values, how tax_id and company_name relate to CRUD operations, or what result to expect. More context is required for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for the three parameters. The critical 'action' parameter is completely undefined, 'tax_id' is required but unexplained, and 'company_name' is not mentioned at all. The description does nothing to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a clear resource, the contacts database, and the general operation type, CRUD. However, 'CRUD operations' is broad and does not specify which action is being performed; the agent must infer from the undocumented action parameter. It distinguishes from siblings by resource, but not by operation type.
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 ocr_get_record or ocr_list_records. There are no exclusions, prerequisites, or conditions that would help an agent decide between this and a sibling tool.
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 indicates a read operation ('Retrieve') but does not explain what happens when no matching record exists, whether 'processed' implies status filtering, what fields are returned, or whether it is strictly non-destructive.
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 filler words; it states the core purpose immediately. However, it is concise to the point of omitting important context, so it earns only partial credit.
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 retrieval tool with no annotations, no output schema, and 0% parameter coverage, this description is incomplete. An agent cannot confidently determine which identifier to pass, how the two optional parameters interact, or what a successful or failed lookup returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter. Both invoice_id and invoice_number are optional, but the description provides no clue whether one is required, whether they are interchangeable, or what values are expected beyond their schema types.
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 names a specific action ('Retrieve') and a specific resource ('processed invoice record'), so the tool's job is clear. It is not a tautology and is distinguishable from siblings like ocr_list_records or ocr_review_record, though it does not explicitly name them.
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?
There is no guidance about when to use this tool instead of alternatives such as ocr_list_records or ocr_review_record, and no mention of when the two identifier parameters should be used. The context is only implicit: it returns a single processed invoice record.
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, and 'Process all pending files' communicates almost nothing about side effects. It doesn't disclose whether files are deleted, moved, or left in place after processing, whether the operation is long-running or asynchronous, how failures are handled, or what the return/outcome looks like. The only behavioral trait conveyed is the batch scope.
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?
One clean 11-word sentence with no filler; the core scope ('all pending files' + 'drop/staging directory') is front-loaded. It earns its words, though it borders on under-specification — the brevity is achieved partly by omitting behavioral details that the completeness dimension penalizes.
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 mutating batch operation with zero annotations, no output schema, and one optional parameter, the description is incomplete. An agent cannot determine whether invoking it is destructive, how long it will take, whether it runs synchronously, or how to observe results (via ocr_get_record or ocr_review_queue siblings). The vague verb 'process' is the material gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for documenting folder_path, but it never names the parameter or explains it. 'Drop/staging directory' gives an implicit hint that folder_path identifies where pending files live (and that the default is the standard staging directory), but it doesn't clarify what null means, whether a custom path replaces or augments the default, or what kinds of directory paths are accepted.
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 ('process'), resource ('all pending files'), and location ('drop/staging directory'), making it distinguishable from siblings like ocr_extract_invoice (single invoice extraction) and ocr_review_queue (review workflow). However, 'process' is underspecified — it never explicitly says this runs OCR on the files, relying on the tool name for that meaning.
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 on when to use this tool versus alternatives like ocr_extract_invoice or ocr_poll_scanner_share. There are no exclusions, conditions, or references to sibling tools. The only implied usage is 'when there are pending files in staging,' which is weak since it's not stated as a precondition.
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 reveals the core list-and-filter behavior but does not mention pagination, ordering, limit defaults, error behavior, or response 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 front-loaded sentence with no filler. Every word contributes: it names the action, the resource, and the optional filter.
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 output schema and two optional parameters, an agent can safely invoke the tool with no arguments and still get a list of records. However, the description lacks guidance on status value semantics and does not clarify when this tool should be preferred over sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It explains that 'status' acts as a filter, but it does not explain the 'limit' parameter's behavior or the accepted status values and format.
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 ('List') and resource ('invoice records'), and names the optional status filter. It implicitly distinguishes from ocr_get_record by using plural 'records', but it does not explicitly distinguish itself from list-like siblings such as ocr_review_queue.
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 ocr_get_record or ocr_review_queue. The description only states what the tool does and provides no exclusions or alternative routing.
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 must carry the full burden of behavioral disclosure. It says 'pull and process new files' but does not disclose side effects such as whether files are moved, deleted, marked as processed, or whether the operation is idempotent. This is a significant gap for a tool that obviously mutates state on an external share.
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 filler. It communicates the main action efficiently, though the vague 'process' wording could be tightened for greater precision.
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 zero-parameter action with no output schema, the description gives the core action but leaves important context unexplained: what 'process' means, what happens to the files afterward, whether it can be safely re-run, and what the caller should expect. This is minimally viable but not complete.
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 and 100% schema description coverage, so the baseline is 4. The description does not need to explain parameters, and the zero-parameter shape is consistent with an action-style tool that uses preconfigured settings.
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 names a specific action (connect to a configured SMB scanner share, pull and process new files) and the resource (scanner share). It is distinct from sibling tools like ocr_get_record or ocr_review_queue, though the word 'process' is vague and could overlap with ocr_batch_process.
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 implies this is the tool to poll the scanner share, but it gives no explicit when-to-use guidance or contrasts with alternatives such as ocr_batch_process. There is no mention of prerequisites, scheduling, or conditions under which another tool would be preferred.
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 full behavioral burden. It discloses the two decision outcomes and the optional corrected-field mechanism, but it does not state side effects, whether the review is final, or how corrected interacts with the action.
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 compact, front-loaded, and uses two sentences with no filler. The primary operation comes first, followed by the most important parameter detail.
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 mutation-style tool with five parameters, no annotations, and no output schema, the description is under-specified. It omits the relationship between action and corrected, expected return behavior, reviewer requirements, and what happens to the record after confirmation or rejection.
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 0%, so the description is the main source of parameter meaning. It explains corrected as a JSON string with the overridable fields and gives action semantics, but invoice_id, reviewer, and notes are left to inference from their names.
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 action — confirm or reject — on a low-confidence record, and clarifies the meaning of success vs failure. It does not explicitly distinguish itself from sibling tools, but the resource and action are specific enough to infer its role.
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 'low-confidence record' provides a clear context for when this tool is appropriate, but there is no mention of alternatives, workflow ordering, or exclusions. The usage context is implied rather than fully explained relative to sibling tools.
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 mentions returning structured JSON but does not disclose whether the operation is read-only, what happens with unsupported files, file size limits, authentication requirements, or error 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, front-loaded sentence with no filler. Every word earns its place, and it communicates the core function directly.
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 basic purpose is covered. However, with no output schema and no annotations, the description leaves out response shape details and any guidance on when to choose this over sibling tools, making it adequate but 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 description coverage is 0%, so the description must compensate for the undocumented file_path parameter. It adds the useful context that the file should be a PDF/image invoice, but it does not explain path format, accessibility, or accepted file extensions beyond 'PDF/image'.
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 ('Extract') and a clear resource ('a single PDF/image invoice'), and states the outcome ('return structured JSON'). The word 'single' distinguishes it from the sibling ocr_batch_process.
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 a single document and contrasts implicitly with batch processing, but it never explicitly names alternatives or states when not to use this tool. An agent would need to infer routing from the sibling names.
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 behavioral burden. It clearly conveys that this is a read-only-style listing of queued records, but it does not mention ordering, pagination, or whether listing the queue has any side effects. The output schema covers return shape, but behavior beyond listing is undisclosed.
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, focused sentence delivers the core purpose with no filler. The key distinguishing detail (low-confidence/need_train) is front-loaded and every word contributes.
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 list tool with one optional parameter and an output schema, the description is mostly complete: an agent can invoke it and understand what it returns. The main missing context is how it relates to the sibling ocr_list_records and ocr_review_record tools, but that is already partially covered by the purpose clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for the single 'limit' parameter (0% schema description coverage), and the tool description does not mention or explain it either. The parameter name and default make it somewhat self-evident, but the description adds no value beyond what the schema already shows.
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 ('List') and a specific resource ('low-confidence (need_train) records awaiting human confirmation'), making the queue's purpose immediately clear. This also differentiates it from the sibling tools ocr_list_records and ocr_review_record.
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 when to use the tool: when you need records awaiting human confirmation. However, it does not explicitly state when not to use it or mention alternatives such as ocr_list_records for general listing or ocr_review_record for acting on a record.
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?
The verb 'Report' implies a read-only operation, which is a meaningful behavioral clue in the absence of annotations. However, it does not disclose details such as whether this tool performs network calls, requires privileges, has side effects, or what the response structure looks like. The description carries the full burden here but only partially meets it.
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 sentence that front-loads the main verb and lists the three report categories. No redundant words, no filler. Every element contributes to understanding.
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 is compact but sufficient for a zero-parameter tool. It identifies the exact statuses reported. The only gap is that no output schema exists, so the description could have added a hint about the return format, but for a simple health check the provided information is largely complete.
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 is empty. With zero parameters, the description does not need to explain parameter meanings. The baseline for handling 0 params is 4, and the description does not introduce any confusion.
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 ('Report') and names three concrete resources: database status, SMB status, and queue depth. This clearly distinguishes the tool from data-manipulation siblings like ocr_extract_invoice or ocr_get_record, and leaves no ambiguity about its function.
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 on when to use this tool versus alternatives, no exclusions, and no context on when a health check is appropriate. It merely states what the tool reports, leaving the agent to infer when to invoke it.
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:

[![idin9-doc-ocr-mcp MCP server](https://glama.ai/mcp/servers/idin9/idin9-doc-ocr-mcp/badges/card.svg)](https://glama.ai/mcp/servers/idin9/idin9-doc-ocr-mcp)

Score Badge

Copy to your README.md:

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

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