COBie MCP

Overview Schema Source Related Servers Discussions Admin

extract_from_submittal

Extracts text, structured fields, and tables from PDF submittals, returning confident, sourced data. Handles failures with actionable errors and partial results with warnings.

Instructions

Extract text, structured fields, and tables from a PDF submittal.

Returns consistent structured output with confidence and provenance.
On failure returns actionable error message; on partial failure (e.g. table
extraction fails) returns best-effort text and warnings. Output is kept
minimal: text_summary is provided when text is long; use full text when needed.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No		both
`pdf_path`	Yes

Output Schema

TableJSON Schema

Name	Required	Description
`text`	No
`error`	No	Actionable error message when extraction fails. Null on success.
`fields`	No
`tables`	No	Extracted tables (if any). Empty or None when table extraction fails (fallback: text).
`metadata`	Yes
`warnings`	No	Actionable warnings (e.g. table extraction failed, using text fallback).
`confidence`	No	Overall extraction confidence (0.0-1.0). Lower when fallbacks or warnings apply.
`provenance`	Yes
`executed_at`	Yes
`text_summary`	No	Truncated text preview (~500 chars) when full text is large; avoids dumping huge content into chat.
`text_truncated`	No	True if full text was truncated; use expand_text option to get full content.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Sep 7, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations provided, the description fully carries the behavioral burden. It explicitly describes the return format (consistent structured output with confidence and provenance), failure handling (actionable error messages, best-effort text with warnings for partial failures), and output minimization (text_summary).

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

Conciseness5/5

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

The description is concise (four sentences), front-loads the main purpose, and provides additional behavioral details without redundancy. It is well-structured and free of fluff.

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?

Given the simple parameter set (two basic types) and the presence of an output schema, the description covers the core behavior, error modes, and output minimization. No critical information appears missing for correct invocation.

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

Parameters3/5

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

The schema has no parameter descriptions, and the description does not explain the 'mode' parameter or 'pdf_path' beyond the general purpose. The enum values (text, fields, both) are self-explanatory but not explicitly linked to output behavior, leaving some ambiguity for agents.

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?

The description states a specific verb ('extract') and resource ('PDF submittal'), and lists the extracted contents (text, structured fields, tables), which clearly distinguishes it from sibling tools like extract_from_text and extract_from_excel_attachment.

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?

The description clearly implies when to use the tool (for PDF submittals) and describes behavior on failure and partial failure, but it does not explicitly mention alternatives or state when not to use it. The sibling tool names and the explicit 'PDF' make the usage clear enough, though not fully explicit.

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

Deploy Server