Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@idin9-doc-ocr-mcp Extract the Thai tax invoice from invoice.pdf and route it"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Standalone Model Context Protocol (MCP) server for document OCR and Thai tax invoice processing, with automated scanner ingestion (SMB/Shared Folder) and SQLite storage.
The server extracts tax invoices from PDFs and scanned images, parses the 13 core Thai tax-invoice fields, applies three-tier routing (success / need-train / failed), and stores results in SQLite. It can also poll an SMB scanner share or watch a local drop folder.
Digital + scanned documents — PyMuPDF for embedded text, Tesseract (tha+eng) with
image pre-processing (grayscale, de-noise, adaptive threshold, de-skew) for scans.
Thai tax invoice parsing — supplier/buyer, 13-digit tax IDs, line items, summary, currency, and capture-rate scoring.
Three-tier routing
success — 100% capture + valid totals + buyer verification → processed/YYYY-MM/
need_train — 80–99% capture → Need-Train/
failed — < 80% capture or non-tax document → failed/
Automated ingestion — SMBv2/v3 scanner share polling and watchdog folder watching.
SQLite storage — WAL mode, tax invoices + canonical contacts tables, full CRUD.
MCP tools — exposed via FastMCP for Hermes / Claude Desktop / any MCP client.
Related MCP server: cockpit-mcp
Python 3.11+
Tesseract OCR with Thai + English language packs (tesseract-ocr-tha, tesseract-ocr-eng)
Access to a scanner SMB share (optional)
sudo apt-get update
sudo apt-get install -y tesseract-ocr tesseract-ocr-tha tesseract-ocr-engpython -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env # then edit valuesCopy .env.example to .env and adjust:
Variable | Description |
| Local/mounted scanner drop folder |
| SMB scanner share (leave blank to disable) |
| SQLite database path |
| OCR engine settings |
| Threshold to decide digital vs scanned extraction |
python -m src.mcp_serverOr with Docker:
docker compose up --build{
"mcpServers": {
"idin9-doc-ocr-mcp": {
"command": "python",
"args": ["-m", "src.mcp_server"],
"cwd": "/path/to/idin9-doc-ocr-mcp",
"env": {
"TESSERACT_CMD": "tesseract",
"OCR_LANGUAGES": "tha+eng"
}
}
}
}{
"mcpServers": {
"idin9-doc-ocr-mcp": {
"command": "python",
"args": ["-m", "src.mcp_server"],
"cwd": "/path/to/idin9-doc-ocr-mcp"
}
}
}Tool | Purpose |
| Extract a single PDF/image invoice |
| Process all pending files in a folder |
| Pull & process new files from the SMB share |
| Retrieve a stored record |
| List records with filters |
| CRUD on contacts |
| List low-confidence ( |
| Confirm (→ success) or reject (→ failed) a review item |
| DB/SMB/queue health report |
Documents that score 80–99% capture (or have valid totals but an unverified
buyer) are routed to Need-Train/ and stored with status need_train. These are
held for human confirmation before they are trusted as final.
Two interfaces are provided, both backed by the same SQLite database:
ocr_review_queue() → returns pending items.
ocr_review_record(invoice_id, action="confirm"|"reject", reviewer, notes?, corrected?)
confirm → status becomes success, file moves to processed/YYYY-MM/,
reviewer identity and optional corrected fields are stored.
reject → status becomes failed, file moves to failed/.
Run the review web server:
python -m src.webui
# or: idin9-doc-ocr-webui
# optional port: WEBUI_PORT=8080 python -m src.webuiOpen http://localhost:8080. The queue lists every pending invoice; opening one
shows an editable form (header, supplier, buyer, summary) plus the raw OCR text.
A reviewer enters their name, then Confirms as correct or Rejects as bad.
The reviewer name is remembered via a cookie and recorded on the record
(reviewer, reviewed_at, review_notes, review_status).
The tax_invoices table gains these review columns: review_status
(pending/confirmed/rejected), reviewer, reviewed_at, review_notes.
data/
drop/ # scanner drop folder (watchdog)
staging/ # temporary download area (SMB)
processed/YYYY-MM/ # successful extractions
Need-Train/ # 80-99% capture, for review/training
failed/ # <80% capture or non-tax documents
idin9_doc_ocr.db # SQLite databasepip install -e ".[dev]"
pytestMIT
Process all pending files in the drop/staging directory.
| Name | Required | Description | Default |
|---|---|---|---|
| folder_path | No |
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.
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.
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.
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.
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.
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.
Extract a single PDF/image invoice and return structured JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
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.
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.
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.
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.
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.
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.
Retrieve a processed invoice record from the database.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_id | No | ||
| invoice_number | No |
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.
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.
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.
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.
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.
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.
List invoice records with optional status filter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Perform CRUD operations on the contacts database.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| tax_id | Yes | ||
| company_name | No |
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.
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.
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.
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.
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.
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.
List low-confidence (need_train) records awaiting human confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Confirm (as success) or reject (as failed) a low-confidence record.
corrected is an optional JSON string of overridden fields (invoiceNumber,
invoiceDate, currency, supplier_name, supplier_taxId, buyer_name,
buyer_taxId, capture_rate).
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| action | Yes | ||
| reviewer | Yes | ||
| corrected | No | ||
| invoice_id | Yes |
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.
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.
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.
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.
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.
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.
Report database status, SMB status, and queue depth.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Turn PDFs, scans and photos into a queryable database. Invoices, CVs, receipts, in bulk.
Thailand Leceipt e-Tax: AI agents create, poll and download e-Tax Invoices, stateless BYO.
PDF tools + invoice extraction, bank statement parsing, GST reconciliation & GSTIN validation.
Generate professional receipt PDFs and structured receipt data with AI-ready MCP tools.
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
