Skip to main content
Glama
dave1362

RCA-MCP Connector

by dave1362
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

rca_guide_ingest_pdf

Parse a PDF equipment manual and ingest it into the RCA knowledge base for root cause analysis. Rejects non-PDFs and oversized files, and enforces a quality threshold so only usable guides are stored.

Instructions

šŸŒŸ Starter+ ā€” Parse a PDF equipment manual and ingest it into the RCA knowledge base. Rejects non-PDF input (checked via file signature, not just the base64 wrapper) and files over 50MB.

A quality gate runs automatically: if the parsed quality score falls below min_quality_threshold (default 0.3), ingestion is refused with suggestions -- set skip_preview_check=true to bypass it, or lower min_quality_threshold, if you've already reviewed the content via rca_guide_pdf_preview and are OK with a rougher parse.

Recommended workflow: 1) rca_guide_pdf_preview to check quality, 2) rca_guide_ingest_pdf if quality >= 0.5, 3) rca_guide_search to verify.

Plan limits: Starter up to 10 guides total, Pro up to 100, Enterprise unlimited. Max PDF size: 50MB.

Args: params (GuidePDFIngestInput): pdf_base64, equipment_id, equipment_type, name, tags, version, strategy, ocr_dpi, ocr_language, max_pages, skip_preview_check, min_quality_threshold

Returns: str: JSON with guide_id, section_count, fault_codes, part_numbers, parse_quality, strategy_used, page_count, word_count

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.1.15
    • addedInput schema / $defs / GuidePDFIngestInput / properties / client_id / description
      Added value: +"Client namespace ID"
    • addedInput schema / $defs / GuidePDFIngestInput / properties / token / description
      Added value: +"API key to authenticate this request"
  2. Changed1 schema field changedv4.1.14
    • addedInput schema / $defs / GuidePDFIngestInput / properties / version / description
      Added value: +"Your own version label for this guide (not validated or auto-incremented)"
  3. First observedv4.1.13

TDQS

A4.6/5.0
Behavior5/5

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

The description discloses several important behaviors beyond the annotations: non-PDF rejection via file signature, 50MB size cap, automatic quality gate, bypass behavior, plan limits, and return fields. This goes well beyond the readOnly/destructive/idempotent hints and gives the agent a realistic model of what will happen.

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?

The description is well organized and front-loaded with the core purpose and constraints, followed by workflow, quality gate, plan limits, and returns. It repeats the 50MB limit twice and includes a minor emoji distraction, but the length is largely justified by the tool's complexity.

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?

The description covers input validation, size limits, quality threshold behavior, plan limits, a recommended workflow, and the expected return payload. Given the annotations and schema, an agent has enough context to understand when and how to invoke the tool successfully.

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 narrative adds useful context for min_quality_threshold and skip_preview_check, and the Args section lists most parameters. However, the schema description coverage signal is 0%, and the description does not fully compensate by explaining each parameter's meaning; it also omits the required token parameter from its parameter list, relying on the schema to fill in those details.

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 and resource: parse a PDF equipment manual and ingest it into the RCA knowledge base. It also distinguishes the tool by its PDF-specific input handling and file-signature validation, which separates it clearly from siblings like rca_guide_ingest and rca_guide_pdf_preview.

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

Usage Guidelines5/5

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

The description gives an explicit recommended workflow: preview first, ingest if quality is adequate, then search to verify. It also explains when to bypass the quality gate with skip_preview_check and names the related sibling tools, giving an agent concrete routing guidance.

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

Install Server

Other Tools