doc-cheap
doc.cheap MCP server turns passport, ID card, and driver's licence images into structured JSON via OCR, and manages scans, balance, and documentation lookup.
scan_document: Recognise a passport, national ID card, or driver's licence fromimage_base64,image_path(withinDOC_CHEAP_IMAGE_ROOT), or publicimage_url; returns a structuredScanwith meta, document, holder, fields, MRZ, images, quality, and authenticity; costs one credit ($0.01) only when a document is recognised; supportsexpect_country,return_portrait,retain_hours,reference, andidempotency_key.check_balance: Return remaining credits, free vs. paid balances, current period usage, and scan counters by status; takes no arguments; sandbox key returns null instead of a balance.search_docs: Full-text search the shipped doc.cheap API documentation for endpoints, response fields, error codes, MRZ rules, retention, and pricing; works offline; optionallimit.list_scans,get_scan,delete_scan: List stored scans (paginated), fetch a stored scan by ID, or permanently delete one; only available for live-key accounts with retention; none charge credits.Resources and prompts: Exposes read-only documentation resources and prompts for common tasks such as scanning to JSON, checking document expiry, batch scanning, and explaining error codes.
Deployment: Runs locally over stdio via
npx -y @doc-cheap/mcpor hosted over Streamable HTTP athttps://mcp.doc.cheap/mcp; uses your API key or the public sandbox key.
Click on "Deploy 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., "@doc-cheapscan this passport photo and return the MRZ data as JSON"
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.
doc.cheap MCP server – passport, ID card and MRZ OCR for AI agents
Give your assistant a passport, national ID card or driver's licence and get the printed fields back as structured JSON – $0.01 per recognised document, and free to try before you register. Without a key, the public sandbox key is used. It gives 10 free recognised documents per address in all, and at most 10 requests per address an hour, whatever their answer. Registering gives 100 free documents every month.
An MCP server over stdio, for Claude Desktop,
Claude Code, Cursor, VS Code, Gemini CLI, Windsurf, Kiro and any other MCP
client – and the same server hosted at https://mcp.doc.cheap/mcp for clients
that connect to a URL instead. It is a thin client of the public doc.cheap HTTP
API and a copy of the documentation: it holds no data of its own.
npx -y @doc-cheap/mcpHosted – nothing to install
https://mcp.doc.cheap/mcp serves the same six tools over Streamable HTTP. No
login: send your key as X-Doc-Cheap-Api-Key: sk_live_your_key or
Authorization: Bearer sk_live_your_key – the named header wins when both are
sent, and an Authorization that is not a doc.cheap key is ignored rather than
passed on. Without a key, the public sandbox key is used. It gives 10 free recognised documents per address in all, and at most 10 requests per address an hour, whatever their answer. Registering gives 100 free documents every month. The
hosted server cannot read files on your machine, so scan_document takes the
image as image_base64 or image_url; image_path is for the local server
only.
Claude Code:
claude mcp add --transport http doc-cheap https://mcp.doc.cheap/mcp --header "Authorization: Bearer sk_live_your_key"Claude Desktop and claude.ai: Settings → Connectors → Add custom connector,
URL https://mcp.doc.cheap/mcp (no key: the sandbox key is used).
Cursor, ~/.cursor/mcp.json:
{
"mcpServers": {
"doc-cheap": {
"url": "https://mcp.doc.cheap/mcp",
"headers": { "Authorization": "Bearer sk_live_your_key" }
}
}
}VS Code, .vscode/mcp.json (the key is asked for once and stored by VS Code):
{
"servers": {
"doc-cheap": {
"type": "http",
"url": "https://mcp.doc.cheap/mcp",
"headers": { "Authorization": "Bearer ${input:doc-cheap-key}" }
}
},
"inputs": [
{
"type": "promptString",
"id": "doc-cheap-key",
"description": "doc.cheap API key",
"password": true
}
]
}Related MCP server: document-intelligence-server
Install locally
Set DOC_CHEAP_API_KEY to your key. Without a key, the public sandbox key is used. It gives 10 free recognised documents per address in all, and at most 10 requests per address an hour, whatever their answer. Registering gives 100 free documents every month. The sandbox key has no balance.
Claude Desktop – one-click extension
Download doc-cheap-<version>.mcpb from the
latest release and open it, or
drag it into the Claude Desktop window. The install screen asks for two optional
settings: your API key (stored as a secret; leave it empty for the sandbox key)
and the one folder image_path may read images from (leave it empty and no
local file is read). Node.js ships with Claude Desktop, so nothing else needs
installing.
Claude Desktop – by hand
claude_desktop_config.json:
{
"mcpServers": {
"doc-cheap": {
"command": "npx",
"args": ["-y", "@doc-cheap/mcp"],
"env": { "DOC_CHEAP_API_KEY": "sk_live_your_key" }
}
}
}Claude Code
claude mcp add-json doc-cheap '{"command":"npx","args":["-y","@doc-cheap/mcp"],"env":{"DOC_CHEAP_API_KEY":"sk_live_your_key"}}'Cursor
~/.cursor/mcp.json (or .cursor/mcp.json in a project):
{
"mcpServers": {
"doc-cheap": {
"command": "npx",
"args": ["-y", "@doc-cheap/mcp"],
"env": { "DOC_CHEAP_API_KEY": "sk_live_your_key" }
}
}
}VS Code
code --add-mcp '{"name":"doc-cheap","command":"npx","args":["-y","@doc-cheap/mcp"]}'Or .vscode/mcp.json, which nests servers under servers rather than
mcpServers:
{
"servers": {
"doc-cheap": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@doc-cheap/mcp"],
"env": { "DOC_CHEAP_API_KEY": "sk_live_your_key" }
}
}
}Gemini CLI
~/.gemini/settings.json:
{
"mcpServers": {
"doc-cheap": {
"command": "npx",
"args": ["-y", "@doc-cheap/mcp"],
"env": { "DOC_CHEAP_API_KEY": "$DOC_CHEAP_API_KEY" }
}
}
}The repository also carries gemini-extension.json, so it installs as a Gemini
CLI extension without writing settings by hand.
Windsurf
~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"doc-cheap": {
"command": "npx",
"args": ["-y", "@doc-cheap/mcp"],
"env": { "DOC_CHEAP_API_KEY": "${DOC_CHEAP_API_KEY}" }
}
}
}Kiro
.kiro/settings/mcp.json in the workspace, or ~/.kiro/settings/mcp.json:
{
"mcpServers": {
"doc-cheap": {
"command": "npx",
"args": ["-y", "@doc-cheap/mcp"],
"env": { "DOC_CHEAP_API_KEY": "${DOC_CHEAP_API_KEY}" },
"disabled": false,
"autoApprove": ["check_balance", "search_docs"]
}
}
}Kiro also installs from a one-click link, which writes that block for you – it asks for confirmation first and shows the command and argument list it is about to add:
https://kiro.dev/launch/mcp/add?name=doc-cheap&config=%7B%22command%22%3A%22npx%22%2C%22args%22%3A%5B%22-y%22%2C%22%40doc-cheap%2Fmcp%22%5D%2C%22disabled%22%3Afalse%7D(config is the URL-encoded JSON of
{"command":"npx","args":["-y","@doc-cheap/mcp"],"disabled":false}.)
Claude Code plugin
The repository carries .claude-plugin/plugin.json, so it installs as a Claude
Code plugin rather than as a hand-written server entry.
Every client starts the server as a process, so an edited configuration takes effect on the client's next launch.
Tools
Tool | Title | Read-only | Reaches the network |
| Recognise a passport or ID document | no | yes |
| Check remaining credits | yes | yes |
| Search the doc.cheap API documentation | yes | no |
| List stored scans | yes | yes |
| Fetch a stored scan | yes | yes |
| Delete a stored scan – cannot be undone | no | yes |
scan_document
Recognise a passport, national ID card or driver's licence and return what is
printed on it. Give it the image as image_base64, image_path or image_url,
plus the optional expect_country, return_portrait, retain_hours,
reference and idempotency_key.
{
"image_base64": "/9j/4AAQSkZJRgABAQ…",
"expect_country": "GRC",
"idempotency_key": "order-4711-front"
}It answers with the whole Scan as structured JSON – meta (id, status,
billed, confidence, timing), document (kind, issuing country, number,
series, date of issue, date of expiry, whether it has expired and how many days
are left), holder (given names, surname, date of
birth, sex, nationality), fields (every field read off the printed page, each
with its own confidence), mrz (whether the machine-readable zone checks out,
why not when it does not, and its lines exactly as read), images, quality
and authenticity – and a one-line summary of the same result:
Scan 01a0af18-cd8d-7a61-9f2d-4c7b8e105da3 · recognized · passport (GRC) · PARADEIGMA ELENI SOFIA · billed · 684 msOne recognised document costs one credit, $0.01. An unreadable image, an empty
frame or an unsupported type costs nothing, and meta.billed says which
happened. Sending the same idempotency_key again returns the first result
rather than recognising and charging a second time.
check_balance
No arguments. Returns the balance – this month's free credits (100 every month,
drawn first) and the paid credits, each on its own – the credits spent and this
period's scan counters by status. With the public sandbox key there is no account behind the
call: the balance comes back as null, and the first line says so and how to
get a key, instead of reporting zeros that read like a balance.
Balance: 1840 credits · 42 free credits left this month · 1798 paid credits · 63 scans this period (58 billed, 58 credits spent).search_docs
{ "query": "mrz check digit", "limit": 5 }Full-text search over the documentation – endpoints, response fields, error codes, MRZ rules, retention, pricing – returning the matching sections with titles, snippets and links. It reads a copy shipped inside this package, so it makes no network call.
Stored scans: list_scans, get_scan, delete_scan
A result is stored only when the scan was made with a live key under a
non-zero retention window – retain_hours on the call, or the account's
history-retention setting (one year by default) when the call named none – and
only until that window ends. A key reaches its own account's scans and no
other's. Under a sandbox key nothing is stored, so the list is empty and a
lookup or a deletion finds nothing; with the public sandbox key the server
says so without calling the API. None of the three charges a credit.
list_scans returns the stored scans, newest first, one page at a time:
{ "limit": 20 }Each row carries id, status, billed, duration_ms, reference and
created_at, and the page carries next_cursor – pass it back as cursor for
the next page; it is null on the last one. limit is 1 to 100 and defaults
to 20. A row holds no extracted data.
get_scan takes a scan_id – meta.id of a scan_document result, or id
of a row – and returns the full Scan as it was first returned, except that
the image crops are never stored (every images slot is null) and quality
reads not_checked. It never recognises the image again.
delete_scan takes a scan_id and permanently deletes that stored scan –
the result, its history row and its thumbnail. It cannot be undone: the scan
can no longer be listed, fetched or replayed through its idempotency_key. The
credit it drew is not refunded. It answers { "id": "…", "deleted": true }.
An id that is unknown, belongs to another account, was made with
retain_hours: 0 or has passed its window is not_found for both tools; the
cases are not told apart.
Every tool declares an output schema, and every successful call returns
structuredContent that matches it, beside the text blocks: the API's Scan
for scan_document and get_scan, its Usage for check_balance, a page of
{ "scans": [...], "next_cursor": … } for list_scans, { "id", "deleted" }
for delete_scan, and { "results": [...] } for search_docs. A failed call
is an error block with no structured content.
Resources
Every page of the documentation this package ships is a read-only resource,
text/markdown, with its title and description:
doccheap://docs/reference/fields
doccheap://docs/reference/errors
doccheap://docs/errors/insufficient_creditsresources/list lists them all, and the template doccheap://docs/{+slug}
looks one up by its path. Reading one makes no network call.
Prompts
Prompt | Argument | What it asks for |
|
| Scan one image and present its printed fields, with the JSON underneath |
|
| Scan one image and report the expiry date, whether it has expired and the days left |
|
| Check the balance, scan each address in turn, then tabulate the results and the failures |
|
| Explain an API error code from its documentation page, which is attached |
Configuration
Variable | Default | Meaning |
|
| Your API key. Unset uses the public sandbox key: 10 free recognised documents per address in all, at most 10 requests per address an hour, no balance. |
|
| Base URL of the API. Only set this to reach another deployment. |
|
| Base URL used to build documentation links. |
| the copy inside the package | Override the directory |
| unset ( | The one directory |
| unset (nothing is reported) | Opt in to failure reporting. Without it the tracker library is never loaded. |
| unset | Set it to |
Image sources
The server runs on your machine, with your files and your network, and the
arguments to scan_document are chosen by a model. So the two sources that are
not the image itself are fenced in:
image_pathis disabled until you setDOC_CHEAP_IMAGE_ROOTto a directory of your choosing. With it set, only files inside that directory can be read: both the directory and the requested file are resolved to their real locations first, so..segments and symlinks pointing out of the directory are refused rather than followed. A relativeimage_pathis taken from that directory. Without the variable the tool answers with an error telling the agent to set it or to sendimage_base64.image_urlmust behttps:and must resolve to a public internet address. Loopback, private, link-local (including the cloud metadata address), carrier-grade NAT, multicast, reserved and IPv6 unique-local and link-local addresses are refused, as are the IPv4-mapped IPv6 spellings of them. Redirects are followed by hand, at most three hops, and every hop is re-checked, so a public URL cannot hand off to a private one. The body is capped at 25 MB – the API refuses more anyway.image_base64has no such constraints: the caller already holds the bytes. It is the fallback every refusal above points at.
A guard refusal is a normal tool error with a readable message, so the agent can tell you what to change.
What this server sends about itself
When it calls the doc.cheap API it identifies itself in the request's
User-Agent, the way any HTTP client does:
doc-cheap-mcp/0.3.9 (claude-code/1.4.2)The first half is this package and its version. The second half is the name
and version your MCP client reports over the protocol – the editor or
assistant you launched it from – normalised to a short label, plus the same
label on a baggage header. It is used for one thing: counting how much this
server is used and from which applications, so that the work goes where people
actually are. It is never used to change what the server does, and nothing else
about you, your prompts, your files or your images travels with it.
Switching it off: set DO_NOT_TRACK=1 in the server's environment. The
request then carries doc-cheap-mcp/0.3.9 and nothing more – no client name, no
client version, no baggage header – and everything else works identically.
Your API key already identifies your account to the API; that is what a key is for, and it is unaffected by the setting above.
Privacy Policy
The full policy is https://doc.cheap/privacy. What it says about this server:
What is collected. The image you ask it to read, sent to the doc.cheap API (
https://api.doc.cheap) – nowhere else. Its calls also name this package and version, and the client you run it in (see the section above;DO_NOT_TRACK=1removes the client). Your key identifies your account to the API.How it is used and stored. The image is read and never stored: it lives in memory for the length of the request. The result – the fields read off the document – is kept for the window the call asked for in
retain_hours(0stores nothing) or, when it asked for none, for the account's history-retention setting, which defaults to one year; expiry deletes it, anddelete_scandeletes one result sooner.Who else sees it. Nobody the policy does not name: the hosting provider and the network provider that carry the traffic. Nothing is sold or shared for advertising. Nothing this server does is reported anywhere unless you set
DOC_CHEAP_SENTRY_DSNyourself.On your machine. The server reads no file unless you name a folder for
image_path, and then only images inside it.Contact. admin@doc.cheap.
The hosted server keeps nothing either. Its log records which method and which tool a request called, how long it took and whether a key of your own was used – never the image, the result, the key or your address.
Run it from source
{
"mcpServers": {
"doc-cheap": {
"command": "node",
"args": ["/absolute/path/to/the/checkout/apps/mcp/src/index.ts"],
"env": { "DOC_CHEAP_API_BASE": "http://127.0.0.1:3000" }
}
}
}pnpm --filter @doc-cheap/mcp build bundles the server to build/index.js with
a shebang and copies the documentation content next to it, so the bin
(doc-cheap-mcp) runs standalone.
Licence
MIT – see LICENSE. The monorepo this server is developed in is UNLICENSED; this package alone is published, and it is published under MIT.
Links
Documentation: https://doc.cheap/docs
Get an API key: https://doc.cheap/register
Source and issues: https://gitlab.com/doccheap/ocr-mcp
doc.cheap: https://doc.cheap
In the MCP registry this server is cheap.doc/mcp.
Available Tools
3 toolscheck_balanceCheck remaining creditsARead-only
Return how many credits are left on the account and what the current period has used: the balance, split into this month's free credits (100 every month, drawn first) and the paid credits, the credits spent, and the scan counters broken down by status (recognized, unreadable, no document found, unsupported document, rejected). Takes no arguments and calls GET /v1/usage; under the public sandbox key it answers without calling anything. One recognised document draws one credit, at $0.01; scans that recognised nothing are counted and never charged. Needs a real API key – under the public sandbox key there is no account behind the call, and the answer says so instead of reporting zeros that read like a balance. Use it before working through a batch of documents, or when a scan is refused for lack of credit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| scans | Yes | |
| period | Yes | Bounds of the current usage period (UTC calendar month). |
| credits_spent | Yes | Credits charged within the period. |
| free_allowance | Yes | This month's free credits, drawn before paid credits; null when the account may not draw free credits (its email address is not confirmed, or its free credits were withdrawn) and for a key with no account. |
| balance_credits | Yes | Credits currently available to the account: this month's free credits plus the paid credits; null for a key with no account (the public sandbox key). |
| paid_balance_credits | Yes | Paid credits: bought or granted to the account, drawn once this month's free credits are used up, and never reset; null only for a key with no account (the public sandbox key). |
| credits_spent_by_kind | Yes | Credits charged within the period, by the kind that paid. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint and openWorldHint annotations. It discloses the sandbox behavior (no account, answer says so), the need for a real API key, and the credit/charge logic (one recognized doc costs $0.01, unrecognized scans free), providing rich behavioral context.
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 dense but efficient; every sentence adds value, from the core result to pricing, sandbox notes, and usage guidance. It is front-loaded with the main purpose, though slightly long for a no-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description doesn't need to detail the return structure. It covers the essential semantics: credit split, spending, scan counters, costs, sandbox behavior, and when to call it. Nothing an agent needs to use it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds meaning by explaining what the output represents, but since there are no parameters, there is nothing to elaborate on beyond the schema's empty object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: returning credit balance and usage details. It names the specific resource (GET /v1/usage) and enumerates the data returned, making it unmistakable from siblings like scan_document and search_docs.
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?
Explicitly states when to use it ('before working through a batch of documents, or when a scan is refused for lack of credit') and even covers the sandbox key exception, guiding the agent on appropriate invocation contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_documentRecognise a passport or ID documentAIdempotent
Recognise a passport, national ID card or driver's licence from a photo or scan and return what is printed on it as structured JSON. Inputs: the image as image_base64 (always available), image_path (a local file, and only inside the directory DOC_CHEAP_IMAGE_ROOT names) or image_url (https, on a public address); plus the optional expect_country, return_portrait, retain_hours, reference and idempotency_key. Output: a Scan object – meta (id, status, billed, confidence, timing), document (kind, issuing country, number, series, date of issue, date of expiry, whether it has expired and how many days are left), holder (given names, surname, date of birth, sex, nationality), fields (every field read off the printed page, each with its own confidence), mrz (whether the machine-readable zone checks out, why not when it does not, and its lines exactly as read), images, quality and authenticity – plus a one-line summary of the same result. Calls POST /v1/scans. Cost: it bills one credit ($0.01) only when a document is recognised; an unreadable image, an empty frame or an unsupported type costs nothing, and meta.billed says which happened. Without a key, the public sandbox key is used. It gives 10 free recognised documents per address in all, and at most 10 requests per address an hour, whatever their answer. Registering gives 100 free documents every month. Use it whenever someone hands over an identity document and wants it read, transcribed, or checked against what they claim – a name, a document number, a date of birth or an expiry date.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | No | https: URL of an image on a public internet address, which the server fetches (25 MB maximum). | |
| reference | No | Your own correlation string, echoed back in the result. | |
| image_path | No | Path to a local image file, inside the directory named by DOC_CHEAP_IMAGE_ROOT. Disabled unless that variable is set; send image_base64 instead. | |
| image_base64 | No | The document image as base64 (a data: URL is also accepted). | |
| retain_hours | No | Hours the result stays readable via GET /v1/scans/{id} (0 = store nothing). Omit it to use the account's own history-retention setting. | |
| expect_country | No | ISO 3166-1 alpha-3 country you expect, or omit for any. | |
| idempotency_key | No | Makes a retried scan return the first result instead of charging again. | |
| return_portrait | No | Whether to include the holder photograph crop, images.main_photo (default true). |
Output Schema
| Name | Required | Description |
|---|---|---|
| mrz | Yes | |
| meta | Yes | |
| fields | Yes | Every field the engine extracted off the printed document, re-keyed to our vocabulary – the open set. Always present; empty when nothing was extracted. A field read in more than one language appears once per language, so `name` repeats and only `id` is unique. |
| holder | Yes | |
| images | Yes | |
| quality | Yes | |
| document | Yes | |
| authenticity | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds extensive behavioral context beyond the annotations: billing rules (one credit only when a document is recognised, free for unreadable images), rate limits (10 free per address, 10 requests per address per hour), sandbox key fallback, retention via retain_hours, and idempotency key behaviour. Annotations already declare openWorld and idempotent, but the description makes the practical implications concrete.
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 front-loaded with the core purpose and inputs, then covers output, cost, and rate limits in a logical order. It is lengthy and spends several sentences explaining return values that are already covered by the output schema, but the extra detail is mostly relevant behavioural context rather than pure waste.
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 complex tool with eight parameters, an output schema, and non-trivial billing and rate-limit rules, the description covers everything an agent needs: input options, output shape summary, cost model, authentication fallback, retention, and the core use case. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description lists the input options and frames the optional parameters, but largely repeats what the schema already documents (e.g. image_path directory restriction, https public URL for image_url, retain_hours semantics). It does not add syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (recognise) and resource (passport, national ID card, driver's licence from a photo or scan) and clearly distinguishes itself from the unrelated siblings check_balance and search_docs. An agent can tell exactly what the tool does without opening the schema.
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?
Explicitly says 'Use it whenever someone hands over an identity document and wants it read, transcribed, or checked against what they claim' — a clear usage context. It does not state when not to use it or name alternatives, but for this tool the alternatives are not relevant given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_docsSearch the doc.cheap API documentationARead-only
Full-text search over the doc.cheap API documentation – endpoints, request options, every response field, the error codes and what to do about each, MRZ rules, retention and pricing. Takes a query and an optional limit (1 to 20, default 5), and answers with the matching sections: title, a snippet, and a link to the page. It reads a copy of the documentation shipped beside this server, so it makes no network call and works offline. Use it before guessing at a field name, an error code or a scan option – what it returns is the published contract rather than a recollection of it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (default 5). | |
| query | Yes | What to search the documentation for. |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | Matching sections, best first; empty when nothing matched. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, and the description adds significant behavioral detail: it makes no network call, works offline, and returns matching sections (title, snippet, link). This goes beyond the annotations without contradicting them, fully informing the agent of the tool's 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 about three sentences but is information-dense with no fluff. It front-loads the purpose, then adds usage and behavior details, and every sentence contributes to the agent's understanding. It is well-structured and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return format is covered. The description additionally explains offline operation, usage guidance, and what the search covers. For a two-parameter search tool, everything an agent needs to call it correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description repeats the limit range and default that the schema already documents. It adds the context of what the query searches over (endpoints, errors, etc.), but this is more about tool scope than parameter semantics. The baseline of 3 applies because the schema handles parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: full-text search over the doc.cheap API documentation, listing specific content types (endpoints, request options, response fields, error codes, MRZ rules, retention, pricing). This distinguishes it from siblings like check_balance and scan_document, which are unrelated operations.
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?
Provides explicit when-to-use guidance: 'Use it before guessing at a field name, an error code or a scan option.' It also notes the tool reads a local copy and works offline, giving practical context for its use. While it doesn't explicitly list alternatives, the siblings are clearly different operations, so no confusion arises.
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.
3 tool updates
v0.3.7- First observed
check_balance - First observed
scan_document - First observed
search_docs
TDQS
Scored across 3 tools
The three tools have clearly distinct purposes: scanning a document, checking credit balance, and searching documentation. There is no overlap or realistic risk of an agent choosing the wrong tool.
All names follow a consistent verb_noun snake_case pattern: scan_document, check_balance, search_docs. The convention is predictable throughout the set.
Three tools is well-scoped for a focused document-scanning API wrapper. Each tool earns its place and there are no redundant or trivial additions.
The surface covers the primary actions of scanning, balance inquiry, and documentation search, but lacks retrieval, listing, or deletion of previously created scans. Despite exposing scan IDs, retention settings, and statuses, agents cannot revisit or manage stored scans, which is a notable lifecycle gap.
Maintenance
Related MCP Connectors
Turn documents into verified, structured data: fields, tables, and automatic checks.
Passport, ID and MRZ recognition via doc.cheap – Free: 100 documents every month, then $0.01 each
Verified OCR with per-value coordinates, plus a workspace agents can file documents into and query.
Document conversion and OCR for AI agents: PDF, Office docs, images to text.
Related MCP Servers
- FlicenseCqualityDmaintenanceEnables AI systems to analyze documents and extract form data through Azure Form Recognizer/Document Intelligence, supporting various document types including receipts, invoices, and ID documents.235 npm2-
- AlicenseNot gradedqualityDmaintenanceEnables intelligent document processing by extracting text, classifying document types, and generating structured summaries from PDFs and images using vision LLMs.MIT
- AlicenseNot gradedqualityCmaintenanceEnables ID document validation using IDmission's identity verification API, including ID validation, face matching, and liveness checks.Apache 2.0

eKYC Suite MCP Serverofficial
AlicenseAqualityBmaintenanceProvides 8 financial-grade KYC identity verification tools for AI agents, including face comparison, liveness detection, document OCR, and risk media labeling.856 npm4MIT