Loading ToolBench
MCP server for agentic document extraction + stacking over LandingAI ADE: ingest, classify, stack, and extract typed fields with page-level provenance. Bring your own LandingAI key.
idpflow-core has well-structured tool definitions with complete input schemas and clear descriptions. All 5 tools are explicitly registered with @mcp.tool decorators, include parameter type definitions, and have descriptions ranging from 150 - 250 chars. Tool names follow verb_noun convention (extract_document, classify_document_tool, stack_documents, process_documents, render_document_package). However, output schemas are not documented in the source code, return types are inferred from Pydantic models (DocumentExtraction, ClassifyResult, StackResult, DocumentPackage, RenderedPackage) but not explicitly described in tool docstrings. Parameter descriptions are present but lack constraint details (e.g., valid profile values, file format restrictions). Error handling is minimal, no recovery guidance or actionable error messages visible. Tool annotations (readOnlyHint, openWorldHint) are present for 4 of 5 tools, which is good. Overall: solid foundation, but missing output schema documentation and error guidance.
Determine a document's type (for stacking + schema selection). Uses an explicit hint if given, else ADE-parsed markdown keywords, else a filename heuristic. Works offline (filename) and live (markdown).
Extract structured fields from a single document via LandingAI ADE. Returns each field with a confidence score and visual provenance (page + bounding box) so outputs are auditable. Fields below the confidence threshold are flagged needs_review.
End-to-end pipeline: ingest → classify → extract → stack → assemble. Returns a DocumentPackage: documents stacked in the configured order, every field carried with confidence + page provenance, and a review queue of ungrounded / low-confidence values. Source-agnostic. Carries no decision.
Produce a combined review artifact: a cover sheet + source docs merged in stack order, plus a JSON sidecar. Runs the full pipeline, then renders a cover sheet (extracted fields tied to source page, review queue, missing docs) followed by the source documents merged in stack order.
Order a set of documents into a configured stack. Document-source-agnostic: works on any list of docs regardless of how they arrived (upload portal, SFTP/S3, email, or export). Example profiles: mortgage | auto_indirect | auto_direct. Pass custom_order (list of doc_type values) to override the profile order.
Output schemas not documented in tool docstrings. Return types (DocumentExtraction, DocumentPackage, RenderedPackage) are Pydantic models but LLMs cannot infer their structure from code. Agents need explicit field documentation to plan downstream calls.
Parameter constraints not documented. 'profile' parameter accepts 'mortgage', 'auto_indirect', 'auto_direct' but these are not enumerated in descriptions or schemas. 'doc_type' accepts DocType enum values but valid options are not listed in parameter description.
Error handling lacks recovery guidance. ValueError exceptions (e.g., 'Unknown doc_type') are raised but no guidance on how to recover or what valid values are. Agents receive raw errors with no actionable next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2025-06-18+ | v2 |
Tool naming inconsistency: 'classify_document_tool' uses '_tool' suffix, breaking verb_noun convention. Should be 'classify_document' to match 'extract_document', 'stack_documents', etc.
No pagination or result limits documented. 'stack_documents' and 'process_documents' accept arrays of documents but no guidance on maximum size, pagination, or result truncation. Large document sets could exhaust context.