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.
Scored across 17 tools
Most tools target a clearly distinct resource+action, and the descriptions carefully distinguish near-pairs like get_extraction_schema (state) vs get_extraction_schema_format_guide (reference) and get_postprocessing vs get_postprocessing_runtime_rules. The only mild overlap is update_extraction_schema vs update_extraction_schema_from_json_schema, which differ by input format and are adequately clarified.
All 17 tools are snake_case and verb-first (create_, get_, list_, save_, set_, test_, update_, upload_, generate_), following a predictable convention throughout. The verb choice also maps sensibly to intent (get_ for single items, list_ for collections).
17 tools is slightly heavy but justified by the breadth of the domain: inboxes, documents, extraction schemas, and post-processing code. Each tool maps to a concrete operation rather than being redundant, so the count feels earned rather than bloated.
Core workflows (create inbox, upload/parse documents, manage schemas, configure and test post-processing) are covered well, with useful helper tools for format guides and runtime rules. However, there are no delete or update operations for inboxes or documents (no delete_inbox, delete_document, update_inbox settings, or reprocess), leaving lifecycle dead ends.
Create a new Airparser inbox. Uses the vision engine unless told otherwise, as the Airparser app does.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-friendly inbox name. | |
| llm_engine | No | Parsing engine, default 'vision'. 'vision' reads the page as an image (layouts, columns, scans, photos, tables). 'text' reads only the extracted text, which suits plain-text emails, and can mix up fields on multi-column layouts. | vision |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-readonly, non-destructive, non-idempotent creation, so the safety profile is covered. The description adds the useful behavioral note that the vision engine is applied by default to match the Airparser app, but says nothing about duplicate-name handling, failure modes, or what is returned.
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 short sentences, front-loaded with the action, no filler. The trailing clause "as the Airparser app does" is mildly redundant but does justify the default choice.
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 leaves the agent guessing what a successful creation returns (e.g., an inbox identifier) and how to proceed afterward. For a simple two-parameter create tool this is adequate but not 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?
Schema coverage is 100% and the enum values for llm_engine are fully documented with trade-offs in the schema itself. The description's only added meaning is restating the vision default, so schema does the heavy lifting and 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?
"Create a new Airparser inbox" gives a clear verb+resource and is unambiguous against siblings, none of which create inboxes. It stops short of naming how it relates to get_inbox/list_inboxes beyond the obvious create-vs-read split.
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 the tool is used (setting up a new inbox) and pins down a default engine choice, but gives no explicit when-to-use/when-not guidance or reference to alternatives. Usage is inferred from the verb rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an Airparser extraction schema proposal from an existing document in an inbox.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes | Airparser inbox id. | |
| document_id | Yes | Existing document id inside that inbox. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=false, destructiveHint=false, and openWorldHint=false. The description reinforces this by calling the output a 'proposal' (not a saved schema), which is useful context, but says nothing about latency/processing cost (schema generation is typically an LLM-backed operation), whether a document must be processed first, or error conditions.
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?
It's a single focused sentence with no filler, front-loading the action and the artifact. The brevity is efficient, but for a potentially expensive generation call it's also slightly thin on caveats.
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 read-only, two-parameter tool with a fully documented schema is simple, but with no output schema the description should say what a 'proposal' looks like or how it's consumed (e.g., passed to update_extraction_schema_from_json_schema). That link is missing, leaving an agent unsure of the next step after the call.
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% for both required parameters, so the schema already explains inbox_id and document_id. The phrase 'in a document in an inbox' adds only a weak relational hint that document_id must belong to inbox_id, which the schema field text already implies.
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 (generate) plus a specific artifact (an Airparser extraction schema proposal) and names the source (an existing document in an inbox). It's clear what the tool does, though it doesn't distinguish itself from siblings like update_extraction_schema_from_json_schema or get_extraction_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?
The word 'proposal' implies output is not yet persisted, which hints at the difference from update_extraction_schema, but the description never states when to use this versus get_extraction_schema or update_extraction_schema_from_json_schema. Usage must be inferred from the name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Airparser document with parsed JSON for the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | Airparser document id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is fully covered. The description adds that results are scoped to the authenticated user and that the payload includes parsed JSON, which is genuinely useful, but says nothing about error behavior for a missing or unparsed document.
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 front-loaded sentence with zero filler; the response-content note is attached inline rather than padded into a second paragraph.
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 read tool with rich annotations, this is close to sufficient, and mentioning parsed JSON partially compensates for the absent output schema. The only real gap is what happens when the document is not yet parsed or does not exist.
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% and the single document_id parameter is documented there. The description adds no format, sourcing, or lookup hints beyond the schema, 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 ('Get one Airparser document') and adds the notable detail that the response carries parsed JSON. The word 'one' implicitly separates it from list_documents, but no sibling is named explicitly.
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 by the singular 'one document'; nothing says when to prefer this over list_documents or upload_document_sync, and no prerequisites (e.g. document must already be parsed) are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current extraction schema configured for an Airparser inbox.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes | Airparser inbox id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's only added signal is 'current' (i.e., reflects the latest saved configuration), which is useful but thin; it says nothing about what is returned when no schema is configured or about any permissions needed.
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 front-loaded sentence with zero filler; the verb and resource appear immediately. Nothing needs trimming and nothing is 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?
For a simple single-parameter read tool with rich annotations, the definition is close to sufficient. But with no output schema present, the description never says what shape the returned schema takes or how it handles an inbox with no configured schema, leaving the agent to discover that on the first call.
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 (inbox_id) and schema description coverage is 100%, so the schema already carries the full parameter burden and the rubric baseline is 3. The description adds no format, sourcing, or validation detail (e.g., where to obtain an inbox id) beyond what the schema provides.
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 ('Get the current extraction schema') scoped to an Airparser inbox, which clearly separates it from the write-side siblings like update_extraction_schema or generate_schema_from_document. It does not, however, explicitly name any sibling or clarify how it differs from get_extraction_schema_format_guide.
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 when-to-use statement, no prerequisites, and no mention of alternatives — notably the closely named sibling get_extraction_schema_format_guide, which an agent could easily confuse this with. The word 'current' hints at reading the live configuration but that is inference, not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a compact guide to the native Airparser extraction schema format, including field types and examples.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered and the description rightly doesn't repeat it. It adds real value by disclosing the guide's content (field types plus examples) and its 'compact' size, but says nothing about the response shape (text vs. markdown vs. JSON) or any limits.
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 front-loaded sentence with the resource first and the payload description second. No filler, no restatement of the title.
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 input parameters and no output schema, the description carries the return-value burden, and it does name the guide's contents and size. It falls short only on how the guide relates to the schema-mutation siblings that presumably consume this format.
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 (empty object schema, 100% coverage), so there is nothing to explain and the baseline of 4 applies. The description correctly avoids inventing parameter guidance.
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 ('Get') and a specific resource ('native Airparser extraction schema format guide'), plus the contents (field types, examples). This clearly separates it from get_extraction_schema, which returns an actual schema, though the description never names that sibling explicitly.
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: an agent should read this before generating or hand-authoring a schema. There is no explicit 'use this when…' statement and no routing against alternatives such as generate_schema_from_document or update_extraction_schema_from_json_schema, both of which presuppose this format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single Airparser inbox, including extraction schema details.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes | Airparser inbox id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds one useful piece of context beyond that: the response includes extraction schema details. It says nothing about error behavior (e.g., what happens with an invalid inbox_id), but the annotation coverage keeps this at an acceptable 3.
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 short sentence with the resource and the returned payload front-loaded. Nothing is padded or wasted.
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 single-record read protected by rich read-only annotations, the description is close to sufficient, and the note about included schema details clarifies the return payload in the absence of an output schema. However, it omits what identifies the inbox in the response or how a missing inbox is signaled, leaving a modest 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?
Only one parameter, and the schema documents it at 100% coverage ("Airparser inbox id."). The description adds no format or sourcing detail for inbox_id, so it neither helps nor hurts beyond the schema baseline.
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 ("Get a single Airparser inbox") and adds scope detail ("including extraction schema details"). The word "single" implicitly contrasts with the list_inboxes sibling, though it doesn't explicitly address overlap with get_extraction_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?
No explicit when-to-use or when-not-to-use guidance. The reader must infer that a single-inbox fetch is the alternative to list_inboxes, and there is no direction on when to call this versus get_extraction_schema, which the description's mention of schema details could confuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current Airparser post-processing configuration for an inbox, including whether it is enabled and the saved Python code.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes | Airparser inbox id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds useful behavioral detail beyond the annotations by specifying that the response includes whether post-processing is enabled and the saved Python code, which is the main return content an agent needs. It does not describe error behavior when the inbox has no configuration, but the core read behavior is well disclosed.
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 efficient sentence that front-loads the operation and then specifies the key return contents. Every phrase earns its place, with no redundant restatement of the title or extraneous 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 simple single-parameter read operation with rich annotations and full schema coverage, the description is nearly complete. It tells the agent what the tool returns, which is important because there is no output schema. Minor gaps remain around behavior when no configuration exists, but nothing essential for calling the tool 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?
Schema description coverage is 100%, and the single parameter inbox_id is fully documented in the schema. The description only restates that the configuration is 'for an inbox' and adds no new semantics such as format, validation rules, or lookup behavior beyond what the schema already provides. Baseline 3 is appropriate.
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 and resource: 'Get the current Airparser post-processing configuration for an inbox.' It clearly states what is retrieved, including enabled status and saved Python code, so the agent understands the core operation without opening the schema. However, it does not explicitly differentiate itself from related siblings such as get_postprocessing_runtime_rules or save_postprocessing_code.
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 by the wording 'Get the current ... configuration,' suggesting the tool is used to inspect existing post-processing settings before editing or enabling them. There is no explicit guidance on when to choose this tool versus get_postprocessing_runtime_rules or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the runtime constraints and allowed imports for Airparser post-processing Python code.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying that the response contains runtime constraints and allowed imports, though it does not describe formatting or the granularity of those rules.
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 wasted words. It immediately tells the agent what resource is returned.
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 zero-parameter read-only tool whose annotations already cover safety and idempotency, the description is almost complete: it identifies the returned information as runtime constraints and allowed imports. It could be stronger by briefly noting the return shape or intended workflow, but that is a minor gap rather than a blocking omission.
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 has zero parameters, so there are no parameter semantics to explain. The baseline for zero-parameter tools is 4.
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: get the runtime constraints and allowed imports for Airparser post-processing Python code. This distinguishes it from get_postprocessing, which retrieves the post-processing configuration/code itself, but the description does not explicitly name or contrast with sibling tools.
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: an agent would call this when preparing, saving, or testing post-processing Python code and needing to know runtime limits. However, there is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternative such as get_postprocessing or test_postprocessing_code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List documents inside an Airparser inbox, including recent parsed results and pagination metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional end date in YYYY-MM-DD format. | |
| from | No | Optional start date in YYYY-MM-DD format. | |
| page | No | Optional 1-based page number. | |
| inbox_id | Yes | Airparser inbox id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without description help. The description adds only that results include 'recent parsed results and pagination metadata', which hints at return content but says nothing about ordering, page size, or defaults.
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 well-formed sentence with the resource and scope front-loaded and no filler. It is efficient, though it is short enough that no structural layering was attempted.
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 tool with a fully documented 4-parameter schema and complete annotations, the description covers what it does and what comes back (parsed results plus pagination metadata). With no output schema present, that return-value hint is genuinely useful, so the definition is close to 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?
Schema coverage is 100%, with the schema itself documenting inbox_id, from/to date format, and 1-based page numbering, so the baseline of 3 applies. The description contributes no additional semantics for the date filters or pagination behavior beyond what the schema already states.
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 clear verb ('List') and resource ('documents') scoped to 'an Airparser inbox', which distinguishes it from get_document (single-item) and list_inboxes (different resource). It stops short of explicitly naming those siblings, so an agent must infer the boundary from the resource noun alone.
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: listing documents in an inbox is the obvious read operation, but the description never says when to pick this over get_document or when a date range is warranted. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active Airparser inboxes available to the authenticated user. Returns a short summary of each inbox (id, name, email prefix, engine, document counts, number of schema fields), not its full schema or settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: only 'active' inboxes are returned, and the payload is a summary rather than full settings — an agent knows not to expect schema data here.
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 sentences, zero waste, with the scope constraint front-loaded and the return shape immediately after. Every clause earns its place.
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, and the description compensates by enumerating the returned fields (id, name, email prefix, engine, document counts, schema field count). Combined with annotations covering safety and no parameters, nothing needed to call this 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 the baseline is 4. The description correctly adds no parameter noise and instead clarifies what the (nonexistent) inputs do not filter on.
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 ('List active Airparser inboxes') plus a distinct scope ('available to the authenticated user'). The second sentence enumerates exactly what each item contains, which lets an agent tell this apart from get_inbox without opening either 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?
The 'not its full schema or settings' clause implicitly routes the agent to get_inbox / get_extraction_schema when detail is needed. No explicit when-not statement or named alternative, but the boundary is inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save Airparser post-processing Python code for an inbox, overwriting any code saved before, without changing whether it is enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Python function body to save inside the restricted Airparser post-processing wrapper. | |
| inbox_id | Yes | Airparser inbox id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds meaningful specifics: the overwrite is scoped to code only and does not alter the enabled state. It stops short of noting validation behavior or what happens on failure, so a 4 rather than 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?
A single tightly written sentence with the destructive overwrite behavior front-loaded and zero filler. Every clause earns its place.
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 2-parameter mutation with rich annotations and no output schema, the description covers the essential semantics: what is written, what is replaced, and what is preserved. Missing only error/validation expectations, so not quite complete at 5.
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% and the schema already explains both parameters, including the restricted wrapper context for 'code'. The description adds no syntax, format, or constraint detail beyond the schema, 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?
States a specific verb ('Save') and resource ('Airparser post-processing Python code for an inbox'), plus the two key scope qualifiers: it overwrites prior code and leaves the enabled flag untouched. This cleanly separates it from get_postprocessing and set_postprocessing_enabled.
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 clause 'without changing whether it is enabled' implicitly routes the agent away from set_postprocessing_enabled for enable/disable operations, giving clear usage context. It does not explicitly name the alternative tool or state when-not-to-use, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable the saved Airparser post-processing step for an inbox.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes | Airparser inbox id. | |
| is_enabled | Yes | Whether post-processing should be enabled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that the step is 'saved' and inbox-scoped; it does not say what happens if no post-processing exists or whether in-flight runs are affected. With annotations present this modest addition merits a 3.
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 well-formed sentence with the action and resource front-loaded and 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 two-parameter idempotent toggle with full schema coverage and annotations carrying safety semantics, the description says enough to call it correctly. Only the missing failure-mode context keeps it from a 5.
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 (inbox_id, is_enabled) are already documented. The description merely restates the enable/disable and inbox framing without adding format or edge-case detail. Baseline 3 is appropriate.
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 pair ('enable or disable'), the exact resource ('the saved Airparser post-processing step'), and its scope ('for an inbox'). This is enough to distinguish it from save_postprocessing_code or get_postprocessing, though it never names those siblings explicitly.
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: an agent can infer this toggles an existing step rather than creating or editing one. There is no explicit statement of prerequisites (e.g. that post-processing must already be saved) or of when to prefer save_postprocessing_code instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Airparser post-processing Python code against an existing parsed document without saving it.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Python function body to run inside the restricted Airparser post-processing wrapper. | |
| inbox_id | Yes | Airparser inbox id. | |
| document_id | Yes | Parsed Airparser document id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the persistence profile is partially covered. The description usefully reinforces that results are not saved, but it says nothing about what the tool returns (test output vs. errors), which matters for a test harness.
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 well-formed sentence with the operation and the key non-persisting constraint front-loaded. No 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 tool that executes user-supplied Python, an agent would want to know what the response contains (validation result, output values, errors) since there is no output schema. That is missing, though the core operation and non-persistence are covered.
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 three parameters (code, inbox_id, document_id) are documented in the schema, and the description adds no further detail. 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 ('Run') plus resource ('Airparser post-processing Python code') and a clear scope ('against an existing parsed document without saving it'). The 'without saving' clause distinguishes it from save_postprocessing_code and get_postprocessing, so an agent can route correctly.
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 'without saving it' implies a dry-run/test use case before persisting, but the description never explicitly states when to use this versus get_postprocessing_runtime_rules or get_postprocessing, nor names any prerequisite. Usage is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the extraction schema of an Airparser inbox with the given fields, in the native validated schema format. Fields not included are removed from the schema.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Extraction schema fields in Airparser native format as used by the API. | |
| inbox_id | Yes | Airparser inbox id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real value by concretizing the destruction: 'Fields not included are removed from the schema' tells the agent exactly what data loss results from a partial fields array, which the annotations alone do not convey.
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 sentences, front-loaded with the action and immediately followed by the destructive consequence. Nothing is wasted and the most important warning comes before any elaboration.
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 destructive replace operation with no output schema, the description covers the critical behavior (full replacement, omitted fields deleted) and annotations cover idempotency and destructiveness. It could have pointed to get_extraction_schema_format_guide for the exact native format, which is the one remaining gap an agent would face.
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 baseline is 3. The description goes slightly beyond by clarifying that fields is a full-replacement payload in Airparser's native validated format, which explains the semantics of the array rather than just its shape.
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 (replace) and resource (extraction schema of an Airparser inbox) and hints at format differentiation from the sibling update_extraction_schema_from_json_schema via 'native validated schema format'. However, it never names that sibling, so the distinction relies on the reader inferring the format contrast.
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 you should use this when you already have fields in Airparser's native format, but it gives no explicit when-to-use vs get_extraction_schema_format_guide or update_extraction_schema_from_json_schema. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an OpenAI-style schema description into the native Airparser extraction schema format and save it to an inbox, replacing the schema it had.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | OpenAI-style field definitions to convert before saving. | |
| inbox_id | Yes | Airparser inbox id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds the important consequence — the inbox's previous schema is replaced, not merged — which clarifies the blast radius of the destructive write beyond what the annotation flag alone conveys. It still omits validation/error behavior and permissions.
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 sentence, front-loaded with the conversion action and ending with the replacement consequence — no filler, no repetition of the title.
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 and the description never says what is returned (e.g., the saved native schema or an id). For a destructive, idempotent write on a fairly complex nested field structure, it also says nothing about conversion failures or validation errors, leaving meaningful gaps.
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% and both parameters (inbox_id, fields) are documented in the schema itself. The description only reinforces the OpenAI-style versus native format distinction for the fields payload, adding no details beyond the schema baseline.
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 chain ('Convert ... and save') and names the exact resource ('Airparser extraction schema format', saved to an inbox). It implicitly distinguishes itself from update_extraction_schema by stating the conversion from OpenAI-style descriptions, but never names or contrasts the sibling explicitly.
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 conversion step implies when to use it (you have an OpenAI-style schema rather than a native one), but there is no explicit statement of when to prefer this over update_extraction_schema or get_extraction_schema_format_guide. Usage must be inferred from the tool name and schema shape.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable per-document output metadata fields (e.g. confidence, doc_id, credits) for an Airparser inbox. Only the fields you pass are changed; anything omitted keeps its current value.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes | Airparser inbox id. | |
| fields_meta | Yes | Partial set of metadata fields to enable/disable. Omitted keys are left unchanged. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds the genuinely useful patch semantic ('only fields you pass are changed; omitted keys keep current values'), but says nothing about permissions, side effects on existing documents, or error behavior when the inbox or a field is invalid.
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 sentences, zero waste. The core action is front-loaded and the merge/patch caveat follows immediately, so an agent can stop reading after the first clause if it only needs the purpose.
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 two-parameter, non-destructive mutation with full schema coverage and no output schema, the description covers purpose plus update semantics adequately. Minor gaps remain around post-update effects on already-extracted documents and error cases, but 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?
Schema coverage is 100% and the nested fields_meta object already documents each boolean key, so the schema does the heavy lifting. The description contributes only a few illustrative field names and the true/false = enable/disable meaning, which is a marginal add over the schema's own 'Partial set of metadata fields' note.
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 pair (enable/disable), the exact resource (per-document output metadata fields) and the scope (an Airparser inbox), with concrete field examples. It is clearly distinct from schema-editing siblings like update_extraction_schema, though it doesn't 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?
Usage is only implied: an agent can infer this is the tool for toggling output metadata on an existing inbox. There is no explicit statement of when to prefer it over siblings such as update_extraction_schema, nor any prerequisite (e.g. that the inbox must already exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload one document to an Airparser inbox and wait up to 15 seconds for the parsed result. File content must be base64 encoded. If parsing takes longer, the response has parsing_in_progress: true and the document id; the document is accepted and keeps being parsed.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Original filename, including extension. | |
| inbox_id | Yes | Target Airparser inbox id. | |
| metadata | No | Optional metadata object to attach as meta. | |
| content_type | Yes | Mime type such as application/pdf or image/png. | |
| content_base64 | Yes | Base64-encoded file contents. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the mutation profile is covered. The description adds genuinely new behavior: the bounded 15s wait, the exact timeout response shape (parsing_in_progress: true plus document id), and the reassurance that the document is accepted and continues parsing rather than failing — the key fact an agent needs to avoid a duplicate re-upload.
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 sentences, front-loaded with the action, then the blocking behavior, then the failure path. No filler and no restatement of the title.
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, and the description does cover the partial/timeout return shape, which is the most important outcome. It does not describe what a successful parsed response contains, leaving the agent to infer the success payload.
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 every parameter including content_base64 and metadata is already documented. The description's base64 note restates the schema rather than adding format, size, or encoding constraints, 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?
Names a specific verb and resource ('Upload one document to an Airparser inbox') plus the distinguishing mode ('sync' with a bounded wait), which separates it cleanly from get_document and list_documents siblings. An agent knows exactly what the call 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?
The 15-second wait and the parsing_in_progress fallback implicitly tell the agent when this call is appropriate, but the description never states when to prefer it over an alternative or what to do after receiving parsing_in_progress (e.g. poll get_document). No sibling tools are named.
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.
create_inboxgenerate_schema_from_documentget_documentget_extraction_schemaget_extraction_schema_format_guideget_inboxget_postprocessingget_postprocessing_runtime_ruleslist_documentslist_inboxessave_postprocessing_codeset_postprocessing_enabledtest_postprocessing_codeupdate_extraction_schemaupdate_extraction_schema_from_json_schemaupdate_fields_metaupload_document_syncExtract, search and tag any document: invoices, receipts, contracts, templates. OAuth or API key.
Extract PDFs into structured tables, query records, and configure document inbox workflows.
DocForge turns documents into structured data. Upload a PDF, image, or Office file and get fielded JSON back with per-field confidence scores. 95 templates (invoices, receipts, bank statements, ID docs), custom JSON Schema mode, auto-detect, natural-language instructions. Keyless demo tool included. Free 7-day trial.
Convert documents to structured JSON (invoices, receipts, contracts) in 2 seconds
Add one secure layer between your agents and this server.
