Skip to main content
Glama
leanzero-srl

MCP Document Processor

Official
by leanzero-srl

fact-check

Extract factual claims from documents or explicit statements, search the live web for supporting evidence, and retrieve source URLs with a keyword-overlap score. Optionally generate a cited PDF verification report.

Instructions

Fact-check a document (or explicit claims) against the LIVE WEB. CROSS-MCP tool: doc-processor extracts the claims, then CALLS the web-search MCP (get-web-search-summaries) to gather sources per claim, and optionally writes a cited PDF report. Provide claims (an array of statements) OR a filePath/content to auto-extract factual claims from. Because this reaches the web-search MCP you MUST pass webSearchBearer (your web-search demo key) and serperKey (your Serper key); webSearchUrl defaults to the hosted web-search endpoint. Returns, per claim, the retrieved evidence + source URLs + a ROUGH keyword-overlap support score — NOT a verdict; read the evidence and decide support/refute yourself. Set generateReport: true for a downloadable cited PDF.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
claimsNoExplicit statements to verify. If omitted, claims are auto-extracted from filePath/content.
contentNoRaw text to extract claims from. Use this OR claims OR filePath.
filePathNoA document (PDF/DOCX/Excel/PPTX) to read and extract claims from. Use this OR claims OR content.
maxClaimsNoMax claims to check (default 8, max 20).
serperKeyNoREQUIRED. Your Serper key — the web-search MCP is keyless and needs it to search.
uploadUrlNoOPTIONAL. HTTPS URL of a receiver that will accept a JSON envelope `{data:base64, filename, mimeType, size}` POSTed with this Bearer auth. If you have NOT been given an uploadUrl in your context, OMIT this field and the tool just writes the file locally. Single-use semantics — do not retry on 4xx. Works with any compliant receiver (CogniRunner attachment-upload web trigger is the reference implementation, but the contract is generic).
clientHintNoHow the response should be shaped. 'interactive' = polished one-line message for end-users (no chatty registry/lineage notes). 'agent' = verbose response with all metadata for AI consumption. 'auto' (default) = detect from input shape or MCP_CLIENT_TYPE env var, falling back to 'agent'.
reportTitleNoOptional title for the generated report.
webSearchUrlNoOptional. The web-search MCP /mcp URL. Defaults to the hosted endpoint (or the WEB_SEARCH_MCP_URL env var).
generateReportNoIf true, also write a cited PDF verification report (returned as a download link).
uploadFilenameNoOPTIONAL. Filename to put in the upload envelope. Defaults to the local file's basename. Useful when the local file got auto-suffixed (e.g. duplicate prevention) and you want a clean name on the receiver side.
webSearchBearerNoREQUIRED. A web-search MCP tenant bearer (your web-search demo key) — this tool calls that MCP.
uploadAuthHeaderNoOPTIONAL. Authorization header value for uploadUrl (e.g. 'Bearer abc123'). REQUIRED when uploadUrl is set; ignored otherwise. Never logged.
Behavior4/5

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

With no annotations provided, the description carries the full burden. It explains the cross-MCP workflow, the need for API keys, the output structure (evidence, source URLs, keyword-overlap score), and the optional PDF report. It doesn't detail error handling or rate limits but covers essential behavioral aspects.

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

Conciseness3/5

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

The description is relatively long but well-structured, starting with the purpose and then detailing usage. Some sentences contain excessive details that could be streamlined, and the inclusion of both a summary and separated parameter descriptions makes it slightly verbose.

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

Completeness4/5

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

Given the tool's complexity (13 parameters, no output schema, no annotations), the description covers the main input mechanisms, dependencies, output format, and optional report generation. It lacks details on error states and limitations but is sufficient for an agent to use the tool correctly.

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?

Although the schema already describes all 13 parameters (100% coverage), the description adds significant context: it explains the relationship between claims, filePath, and content, highlights required keys despite the schema listing them as optional, and clarifies the uploadUrl mechanics. This goes beyond the schema.

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 clearly states the tool's purpose: to fact-check a document or explicit claims against the live web. It uses specific verbs and resources and distinguishes from siblings as no other sibling tool offers fact-checking functionality.

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 provides clear guidance on when to use the tool, including the alternative input methods (claims array or filePath/content) and the requirement for external keys. However, it does not explicitly state when not to use it or compare with specific sibling tools.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/leanzero-srl/leanzero-mcp-doc-processor'

If you have feedback or need assistance with the MCP directory API, please join our Discord server