Boring API

Extract tables from a PDF

documents_tables

Read-onlyIdempotent

Extracts tables from a text-based PDF (price list, data sheet, report; up to 20 MiB, 60 pages) with page, bounding box and a quality level per table. Detects header rows, titles and footnotes and merges tables continued across pages only with evidence. Scanned pages are reported as OCR_REQUIRED, nothing is guessed. Works with any language embedded in the PDF. The PDF can be passed as upload or URL.

Input Schema

TableJSON Schema

Name	Required	Description
`file`	No	The PDF. A file uploaded in ChatGPT (object with download_url and file_id).
`options`	No	Optional TablesOptions, e.g. {"pages": "1-3,7", "strategy": "auto", "include_cells": false}. Schema: /v1/schemas/documents-tables-options.
`file_url`	No	The PDF. Public URL of the file (http/https). Google Drive, Google Sheets and Dropbox share links are converted to direct downloads. Max 20 MiB.
`filename`	No	Original filename with extension (e.g. prices.xlsx); used to detect the format.
`max_rows`	No	Rows returned per table (counts stay complete).
`file_path`	No	Local file path; only allowed when the server runs locally over stdio.
`file_base64`	No	The PDF. File content as Base64 (standard alphabet). Max 20 MiB decoded.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 6, 2026

changedInput schema / properties / file / description

Previous value: -"The PDF. A file the user uploaded in ChatGPT (filled in by ChatGPT; other clients use the URL)."New value: +"The PDF. A file uploaded in ChatGPT (object with download_url and file_id)."

changedInput schema / properties / file_base64 / description

Previous value: -"The PDF. File content as Base64 (standard alphabet). Max 20 MiB decoded; prefer a URL or upload."New value: +"The PDF. File content as Base64 (standard alphabet). Max 20 MiB decoded."

Changed5 schema fields changedOct 6, 2026

addedInput schema / properties / file

Added value: +{
+  "default": null,
+  "description": "The PDF. A file the user uploaded in ChatGPT (filled in by ChatGPT; other clients use the URL).",
+  "properties": {
+    "download_url": {
+      "description": "Temporary download URL",
+      "type": "string"
+    },
+    "file_id": {
+      "description": "ChatGPT file id",
+      "type": "string"
+    },
+    "file_name": {
+      "description": "Original filename, if known",
+      "type": "string"
+    },
+    "mime_type": {
+      "description": "MIME type, if known",
+      "type": "string"
+    }
+  },
+  "required": [
+    "download_url",
+    "file_id"
+  ],
+  "title": "File",
+  "type": "object"
+}

changedInput schema / properties / file_base64 / description

Previous value: -"The PDF. File content encoded as Base64 (standard alphabet). Max 20 MiB decoded."New value: +"The PDF. File content as Base64 (standard alphabet). Max 20 MiB decoded; prefer a URL or upload."

addedInput schema / properties / file_url

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The PDF. Public URL of the file (http/https). Google Drive, Google Sheets and Dropbox share links are converted to direct downloads. Max 20 MiB.",
+  "title": "File Url"
+}

changedInput schema / properties / filename / description

Previous value: -"Original filename including extension (e.g. prices.xlsx); used to detect the format."New value: +"Original filename with extension (e.g. prices.xlsx); used to detect the format."

addedInput schema / properties / max_rows

Added value: +{
+  "default": 100,
+  "description": "Rows returned per table (counts stay complete).",
+  "maximum": 10000,
+  "minimum": 1,
+  "title": "Max Rows",
+  "type": "integer"
+}

First observedOct 6, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds substantive behavior: a quality level per table, header/title/footnote detection, conservative cross-page merging ('only with evidence'), no-guess policy, and any-language support. That is real operational context beyond the hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and limits, then behavior. Sentences are information-dense with no filler, though the first sentence stacks several facts (formats, size, page cap) and could be split for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with nested objects, rich schema descriptions and an output schema, the description covers the remaining gaps (input modes, quality reporting, merge policy) plus a useful summary of return metadata (page, bounding box, quality level). Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds value by clarifying the accepted input channels ('PDF can be passed as upload or URL'), helping the agent choose between the four file-input parameters. It does not add detail on max_rows or the options object, which the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Extracts tables from a text-based PDF') and immediately bounds scope with formats, size (20 MiB) and page limit (60 pages). Sibling tools (merchant_validate, supplier_compare) are unrelated, so no differentiation is needed; the resource is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear condition for use ('text-based PDF... price list, data sheet, report') and an implicit exclusion: scanned pages return OCR_REQUIRED and 'nothing is guessed,' so the agent knows not to expect OCR. It does not explicitly name an OCR/alternative tool, but none exists among the siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Boring API tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?