Run Docparser parsers: import documents by URL or upload, check status, read parsed results.
Scored across 9 tools
Each tool targets a distinct action and resource: parser discovery, document ingestion, status polling, single-document results, multi-document results, reparse, parser models, and API-key health. The singular/plural split between get_document_results and list_document_results is clear from the descriptions and endpoint semantics.
Almost all tools use the docparser_ prefix with a readable snake_case verb_noun pattern, e.g. upload_document, get_document_status, list_parsers. The only deviation is docparser_ping, a conventional health-check name that does not follow the verb_noun pattern.
Nine tools is well-scoped for a Docparser integration: discovery, ingestion, polling, results retrieval, reparse, and connectivity check. Each tool has a clear operational purpose and no obvious filler tools are present.
The core parsing lifecycle is covered: discover parsers, upload or fetch documents, poll status, read results, list results, and reparse. Minor gaps remain around document deletion/cancellation and parser-level administration, but these are not central to the parsing workflow.
WRITE: ask Docparser to download a document from a publicly reachable URL and parse it with the given parser. Uses page credits of the account's plan (documents queue when credits run out). Docparser may buy extra credits by itself only if the account owner turned on automatic credit replenishment, or the account is on an annual plan that renews early when credits run out - check the Docparser billing settings first. This server never buys credits or changes the plan. Returns the new document_id: poll docparser_get_document_status, then read docparser_get_document_results. POST /v2/document/fetch/{parser_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL of the file (PDF, image, Word, Excel, CSV, ...). | |
| parser_id | Yes | Docparser parser id (from docparser_list_parsers). | |
| remote_id | No | Your own reference for the document (stored by Docparser; usable as a filter later). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false) by disclosing credit consumption, queueing when credits run out, the conditions under which Docparser auto-replenishes credits, and an explicit guarantee that this server never buys credits or alters the plan. Consistent with the annotations and highly useful for cost-sensitive callers.
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?
Front-loads the action and the write nature, then handles credits and the return contract in order. The billing discussion is somewhat dense, but every claim (credit usage, queueing, auto-replenishment caveat) is decision-relevant rather than filler.
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?
With no output schema, the description compensates by stating the return value (the new document_id) and the two follow-up calls needed to retrieve results. Combined with the credit and authentication-adjacent caveats, an agent has everything required to invoke this correctly.
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 url and parser_id are already fully documented, and the description adds nothing about remote_id or parameter formats. Baseline 3 applies when the schema carries the parameter burden.
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 and resource ('download a document from a publicly reachable URL and parse it with the given parser'), and the 'WRITE' prefix plus URL-based import clearly separates it from the file-based sibling docparser_upload_document. The API endpoint is even named, making the scope unambiguous.
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?
Gives a clear operational context (public URL, parser required) and prescribes the follow-up workflow: poll docparser_get_document_status, then read docparser_get_document_results. It also warns to check billing settings first. It does not explicitly contrast with docparser_upload_document (local file), so the when-not alternative is only inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The parsed data of one document (the fields and tables the parser extracted, plus file name, page count and upload/processing times). Docparser allows 60 of these calls per minute. GET /v1/results/{parser_id}/{document_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | `object` (default): nested data. `flat`: simple key/value pairs. | |
| parser_id | Yes | Docparser parser id (from docparser_list_parsers). | |
| document_id | Yes | Docparser document id (the `id` / `document_id` of an uploaded document). | |
| include_children | No | Also return data of child documents created during preprocessing (for example split documents). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: a rate limit of 60 calls per minute and a summary of the payload contents. It stops short of describing error behavior or partial/failed parses.
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?
Two compact sentences with the core payload description front-loaded, followed by the rate limit and endpoint. Nothing is redundant or padded.
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?
With no output schema, the description carries the burden of conveying return values and does so adequately (extracted fields/tables plus document metadata), and it discloses the rate limit. Gaps remain around failure/empty-parse behavior and the distinction from the list sibling, but the essentials for correct invocation are 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 description coverage is 100%, so parser_id, document_id, format and include_children are all documented in the schema, including the enum semantics for format. The description adds no parameter-level detail, so the baseline of 3 applies.
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 (get/retrieve) and resource (parsed data of one document) and even enumerates what is returned (fields, tables, file name, page count, timestamps). It implicitly contrasts with docparser_list_document_results by scoping to 'one document', but does not name that sibling, so differentiation is inferred rather than explicit.
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?
Usage is implied: fetch results for a single already-uploaded/processed document. However, there is no explicit when-to-use guidance, no mention of prerequisites (e.g. that the document must be finished processing, cf. docparser_get_document_status), and no exclusion pointing to docparser_list_document_results for multi-document retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Processing status of one document: importing/processing flags, page count, timestamps (uploaded, imported, processed), webhook dispatch and failed jobs. Poll this after a fetch/upload: the document is done when importing_in_progress and processing_in_progress are false, processed_at is set and failed_jobs is empty (a non-empty failed_jobs means it failed); then read the results. GET /v2/document/status/{parser_id}/{document_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| parser_id | Yes | Docparser parser id (from docparser_list_parsers). | |
| document_id | Yes | Docparser document id (the `id` / `document_id` of an uploaded document). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare read-only/non-destructive/open-world, so the description carries the real behavioral burden and does so richly: it defines polling semantics, the exact success/failure criteria, and the meaning of a non-empty failed_jobs. That is substantive context an agent cannot get from the annotations.
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?
Front-loads the returned fields, then the polling/completion rule, then the endpoint path. Dense but every clause is functional; the trailing raw endpoint is minor but harmless extra 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?
With no output schema, the description adequately covers what the response contains and how to interpret it (flags, timestamps, failed_jobs) plus the decision rule for completion. An agent has everything needed to call and interpret this tool.
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 both parameters (parser_id, document_id) are already fully documented in the schema. The description adds no format, pattern, or sourcing detail beyond that, so the baseline 3 applies.
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 and resource: retrieving processing status of one document, and enumerates the exact fields returned (importing/processing flags, page count, timestamps, webhook dispatch, failed jobs). This clearly distinguishes it from siblings like docparser_get_document_results and docparser_list_document_results.
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?
Gives explicit usage context: "Poll this after a fetch/upload" plus the precise completion condition (both in-progress flags false, processed_at set, failed_jobs empty) and the failure condition. It only implies rather than names the follow-up sibling ("then read the results" = get_document_results), so routing to alternatives is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parsed data of several documents of one parser: the last uploaded ones (default), or those uploaded/processed after a date. Returns up to 100 documents per call; page with offset (next_offset is null on the last page). Docparser allows 30 of these calls per minute. GET /v1/results/{parser_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ISO 8601 date-time (e.g. 2026-10-01T00:00:00Z) or a Unix timestamp. Required with list=uploaded_after or processed_after. | |
| list | No | Which documents (default last_uploaded). uploaded_after and processed_after need `date`. | |
| limit | No | Documents per call, 1-100 (default 10). | |
| format | No | `object` (default): nested data. `flat`: simple key/value pairs. | |
| offset | No | Skip this many documents (default 0). Pass the previous reply's next_offset. | |
| sort_by | No | Sort field (default: upload order). | |
| parser_id | Yes | Docparser parser id (from docparser_list_parsers). | |
| remote_id | No | Only documents uploaded with this remote_id. | |
| sort_order | No | Default DESC. | |
| include_processing_queue | No | Also include documents that are not fully processed yet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description still adds genuinely useful operational detail: a documented rate limit of 30 calls per minute, a 100-document page ceiling, and the pagination contract (next_offset is null on the last page).
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?
Three dense sentences: what is returned and the default mode first, then pagination, then the rate limit and endpoint. Every sentence carries information an agent needs, with no filler.
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 read-only list endpoint with full schema coverage and no output schema, the description supplies the things the structured fields cannot: pagination termination (next_offset null), the rate limit, and the underlying HTTP route. An agent can call and page through this tool correctly using the description plus schema alone.
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% with 10 documented parameters and 4 enums, so the schema carries the parameter burden. The description restates only the page-size and offset mechanics ('up to 100 documents per call; page with offset'), adding little that the schema does not already say, so baseline 3 applies.
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 and resource ('Parsed data of several documents of one parser') and names the selection modes (last uploaded vs. uploaded/processed after a date). It is clear, though it never names its nearest sibling (e.g. docparser_get_document_results for a single document), so the differentiation is implied by 'several documents' rather than stated.
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?
It explains the default mode ('the last uploaded ones (default)') and the condition that enables the alternatives ('those uploaded/processed after a date'), which is enough to choose the right listing mode. It offers no explicit when-not guidance or sibling comparison, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the model layouts of one parser (id and label). GET /v1/parser/models/{parser_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| parser_id | Yes | Docparser parser id (from docparser_list_parsers). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description does disclose the concrete REST route and that each item carries an id and label, which is modest but real added context; it says nothing about pagination, ordering, or an empty-result case.
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?
Two compact clauses with the purpose front-loaded and no filler. The trailing endpoint restatement ('GET /v1/parser/models/{parser_id}') is mildly redundant with the description body and the readOnly annotation, costing it the top mark.
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?
A single-parameter, read-only list tool with no output schema, and the description compensates by naming the returned shape (id and label) plus the endpoint. For this complexity level that is sufficient, though pagination behavior for the list remains unstated.
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?
Only one parameter with 100% schema description coverage, so the schema fully documents parser_id, including its pattern and its origin from docparser_list_parsers. The description adds no syntax or format meaning beyond the {parser_id} path placeholder, matching the baseline for high-coverage schemas.
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?
Specific verb (List) plus a precisely bounded resource (model layouts of one parser), and it even names the returned fields (id, label). This clearly separates it from docparser_list_parsers, which enumerates parsers rather than one parser's models.
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?
Usage is only implied: the '(one parser)' scoping and the parser_id path parameter signal that a parser context must already exist. There is no explicit when-to-use, when-not-to-use, or named alternative among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Document Parsers on the account (id and label). Start here: the parser id is needed by every other tool. GET /v1/parsers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, covering the safety profile. The description adds that it returns id and label and is account-scoped, which is useful but modest given the annotation coverage.
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?
Two tight sentences, front-loaded with the resource and the returned fields, then the sequencing hint. No waste; the API route is a minor tail 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 parameterless list tool with no output schema, the description supplies the return shape (id and label) and the reason to call it first. Nothing an agent needs to invoke 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?
Zero parameters, so per the baseline the schema carries no semantics and there is nothing for the description to compensate for. No parameter documentation is needed here.
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?
Specific verb+resource: 'List all Document Parsers on the account (id and label)'. It also states the returned fields, so an agent knows exactly what this tool yields, distinct from siblings that operate on documents or results.
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?
'Start here: the parser id is needed by every other tool' gives a clear prerequisite context for when to call this. It stops short of naming alternative listing tools (e.g. docparser_list_parser_models), but the sequencing guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that the connected Docparser API key works. Returns {msg: "pong"} when it does. GET /v1/ping.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description still adds real value by disclosing the endpoint (GET /v1/ping) and the exact success payload, which matters since there is no output schema. It does not describe failure behavior for an invalid key, which keeps this from a 5.
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?
Three short sentences, each earning its place: what it does, what it returns, and the underlying endpoint. Purpose is front-loaded with no filler.
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?
With no output schema, the description appropriately compensates by naming the success response shape. For a trivial ping endpoint with zero parameters this is nearly complete; only error/unauthorized behavior is left unstated.
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 tool takes zero parameters, which is the baseline-4 case. There are no parameter semantics to clarify, and the description does not need to add any.
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 and resource: it verifies that the connected Docparser API key is valid. This is unmistakably different from every sibling tool, which operate on documents, parsers, or results.
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 'Check that the connected API key works' implies the usage context (validating credentials/connectivity), but there is no explicit guidance such as 'call this first before other operations' or 'use this when requests fail with auth errors'. No alternatives or exclusions are named, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: run the parser again over already imported documents (for example after changing parsing rules). Replaces their parsed data. Re-parsing documents already in the account does not use additional credits. 1-50 document ids per call. POST /v1/document/reparse/{parser_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| parser_id | Yes | Docparser parser id (from docparser_list_parsers). | |
| document_ids | Yes | Ids of the documents to re-parse. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the annotations by disclosing what is destroyed ('replaces their parsed data'), that credits are not consumed for already-imported documents, the 1-50 batch constraint, and the underlying POST endpoint. This meaningfully enriches the destructiveHint and idempotentHint flags rather than restating them.
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?
Four short sentences, front-loaded with the operation type and intent, then the side effect and the cost/batch facts. No filler; every sentence carries new information.
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?
Covers purpose, side effect, cost, batch limits, and endpoint, which is sufficient for a 2-parameter write tool with no output schema. It could still note whether re-parsing is synchronous or returns a job/status handle, since parsing is often asynchronous, but the essential call-time information 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 parser_id and document_ids are already documented in the schema, including the min/max item bounds. The description's '1-50 document ids per call' merely repeats the schema constraints and adds no syntax or format detail, so the baseline 3 applies.
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+resource ('run the parser again over already imported documents') and the leading 'WRITE:' label immediately separates it from read-only siblings like get_document_results. The parenthetical 'after changing parsing rules' pins down the intent further. An agent can distinguish this from upload_document and get_document_status 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?
Gives a clear use context: re-run parsing after changing parsing rules. It does not explicitly name an alternative tool or state when not to use it (e.g., versus a fresh upload), so it stops just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: upload one small file as base64 content to a parser and parse it. Uses page credits of the account's plan. Docparser may buy extra credits by itself only if the account owner turned on automatic credit replenishment, or the account is on an annual plan that renews early when credits run out - check the Docparser billing settings first. This server never buys credits or changes the plan. Files up to about 2.3 MB; use docparser_fetch_document_from_url for larger files. Returns the new document id and the remaining quota. POST /v1/document/upload/{parser_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| file_name | No | File name with extension (e.g. invoice.pdf); a time-based name is used if omitted. | |
| parser_id | Yes | Docparser parser id (from docparser_list_parsers). | |
| remote_id | No | Your own reference for the document (stored by Docparser; usable as a filter later). | |
| file_content | Yes | The file, base64 encoded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-read-only, non-idempotent, non-destructive write with open-world behavior. The description adds important context beyond annotations: page-credit consumption, the server never buying credits or changing plans, possible automatic replenishment on annual plans, and returned document id plus remaining quota.
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 purpose and write nature are front-loaded, followed by operational constraints and billing behavior. Every sentence carries useful information for correct invocation, and the size-limit alternative is stated 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?
There is no output schema, so the description appropriately states what is returned: the new document id and remaining quota. Together with the size limit, billing caveat, and sibling reference, it gives an agent enough to call the tool correctly.
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 all four parameters are already documented. The description adds the file-size limit and confirms base64 content, but does not add syntax or meaning for parser_id, file_name, or remote_id 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 (upload), resource (one small file), format (base64), and action (parse it) tied to a parser. It explicitly distinguishes itself from docparser_fetch_document_from_url for larger files, so an agent can select it without opening sibling schemas.
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 a clear condition for using this tool (files up to about 2.3 MB) and names the alternative explicitly for larger files. It also warns to check billing settings before use when credit replenishment could matter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
docparser_upload_document1 field changedInput schema / properties / file_content / maxLengthPrevious value: -8388608New value: +3145728Turn documents into structured data: parse, extract, classify, split, and fill PDF forms.
Parse logistics PDFs (Bills of Lading, customs declarations, invoices) into DCSA JSON.
Invoices and other financial documents to rows: upload, say what to extract, read the rows.
Extract structured data from invoices, receipts, PDFs, scans, photos and emails. Create an inbox for a document type, define the fields and tables to extract (or propose a schema from a sample document), upload a document and get typed JSON back, review past documents, and add an optional Python post-processing step that is tested on a real document before it is enabled. 17 tools. Sign in with OAuth by pasting your Airparser API key (Account page of the Airparser app); the client only sees that account's inboxes and documents.
Add one secure layer between your agents and this server.
