抽取文档中的表格（PDF / .docx / .pptx），转成 headers+rows 的 JSON 可直接计算。
与 doc_parse 的区别：表格不再压平成 markdown 竖线文本，而是结构化行列，
AI 可直接算合计/对比；PDF 用版面识别找表格。
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | No | 已上传到文件中转站的文档 ID（与 data_base64 二选一） | |
| filename | No | 文件名带扩展名；base64 输入时必填以判类型 | |
| max_pages | No | PDF 最多扫描页数（1-100） | |
| data_base64 | No | 文档内容 base64（与 file_id 二选一） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output format (headers+rows JSON, directly computable) and mentions PDF layout recognition, adding behavioral context. However, it does not address potential limitations such as handling of files without tables, failure modes, or processing constraints beyond the schema's max_pages parameter.
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 two sentences, front-loaded with the core purpose and output format. The second sentence efficiently adds sibling differentiation and PDF-specific behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 4 parameters and no output schema. The description covers the return format (headers+rows JSON) and the core use case, making it fairly complete. It lacks details on edge cases (e.g., no tables found, file size limits) but remains adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds marginal parameter-related context by noting PDF uses layout recognition, which relates to max_pages, but does not explain parameter interactions or provide additional syntax/format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts tables from PDF/.docx/.pptx and converts them to structured headers+rows JSON. It distinguishes itself from the sibling doc_parse by explicitly contrasting the structured output with flattened markdown pipe text.
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 provides a clear use case (direct computation) and explicitly contrasts with doc_parse, naming the alternative tool. However, it does not mention when to use doc_tables over doc_chunk or doc_images, nor does it state when not to use it beyond the doc_parse distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct aspect of document processing: parsing to Markdown, extracting images, extracting tables, and chunking for RAG. The descriptions clearly differentiate their purposes, and doc_tables explicitly notes its difference from doc_parse.
All tools follow the consistent pattern 'doc_' + a noun (chunk, images, parse, tables). Naming is uniform, lowercase, and underscore-separated, making the tool surface predictable.
Four tools is a well-scoped number for a document parsing server, covering core parsing, image extraction, table extraction, and chunking without unnecessary redundancy.
The tool surface covers the full document processing pipeline: parse to Markdown, extract structured tables, extract images, and produce RAG-ready chunks. The only noted limitation (OCR) is explicitly disclosed and does not undermine the core workflows.