PdfParse

Analysis Crosscheck

analysis.crosscheck

Read-onlyIdempotent

Analyzes already extracted rows for consistency issues and underwriting risk contradictions, returning findings with row and field references in this call. Does not run or wait for extraction or save changes. Requires mcp:read and sends bounded row evidence to an external model: at most 80 rows from the first 200 matches, with long values shortened. Returns evidence coverage metadata.

Input Schema

Name	Required	Description
`job_id`	No	Positive integer extraction job ID. Restricts rows to that job's document file IDs and must belong to table_id in the selected project. Omitting it adds no job restriction. This selects existing evidence; it does not start or wait for extraction.
`filters`	No	Row conditions combined with AND, also intersected with the job document restriction when job_id is supplied. An omitted or empty array adds no filtering. Each condition contains column, op, and value.
`table_id`	Yes	ID or slug of the table containing already extracted rows in the selected project. Required even with job_id; the job must belong to this table.
`project_slug`	No	Slug of an owned project. Optional only when the account has exactly one visible project; required for accounts with multiple visible projects.

Output Schema

Name	Required	Description	Default
`summary`	Yes
`evidence`	No
`mismatches`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 18, 2026

addedInput schema / properties / filters / description

Added value: +"Row conditions combined with AND, also intersected with the job document restriction when job_id is supplied. An omitted or empty array adds no filtering. Each condition contains column, op, and value."

addedInput schema / properties / filters / items / properties / column / description

Added value: +"Exact column name in the selected table, or document_record_id to select source file IDs. Unknown columns are rejected."

addedInput schema / properties / filters / items / properties / op / description

Added value: +"Comparison operator: eq/ne for equality/inequality, gt/gte/lt/lte for ordered comparisons, like for SQL patterns (% matches any sequence, _ one character), or in for membership."

addedInput schema / properties / filters / items / properties / value / description

Added value: +"Value matching the column type. Use a scalar for comparisons, a string pattern for like (for example Acme%), or an array for in (a scalar is also accepted as one item; an empty array matches no rows)."

addedInput schema / properties / job_id / description

Added value: +"Positive integer extraction job ID. Restricts rows to that job's document file IDs and must belong to table_id in the selected project. Omitting it adds no job restriction. This selects existing evidence; it does not start or wait for extraction."

addedInput schema / properties / project_slug / description

Added value: +"Slug of an owned project. Optional only when the account has exactly one visible project; required for accounts with multiple visible projects."

addedInput schema / properties / table_id / description

Added value: +"ID or slug of the table containing already extracted rows in the selected project. Required even with job_id; the job must belong to this table."

First observedOct 16, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations cover safety (readOnly, idempotent, non-destructive), and the description adds material context beyond them: the mcp:read auth requirement and the external-model data egress boundary (max 80 rows from the first 200 matches, long values shortened). The data-sharing disclosure is exactly the kind of context annotations cannot convey.

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?

Four tight sentences, front-loaded with purpose followed by the negative scope, auth/egress constraints, and return shape. No sentence is redundant or padded.

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?

An output schema exists, so return values need no explanation; the description still covers scope, limits, auth, and external data handling. For a filtered read-only analysis tool, nothing an agent needs to invoke it correctly is missing.

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?

Schema coverage is 100%, so the schema already documents every parameter including filters, operators, and job_id semantics. The description adds no additional parameter meaning beyond the sampled-row limit implied by 'first 200 matches,' so baseline 3 applies.

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?

States a specific verb (analyzes) plus resource (already extracted rows) and the exact output (findings with row and field references), scoped to 'consistency issues and underwriting risk contradictions.' This is distinguishable from siblings like rows.search (retrieval) and analysis.credit_memo (different analysis output) without opening either schema.

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?

Clearly signals when-not: 'Does not run or wait for extraction or save changes,' steering the agent away from extraction/save tools and implying it operates only on already-extracted data. However, it never names an explicit alternative or states a positive trigger condition beyond the implicit 'there is extracted data to check.'

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

All PdfParse tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.