Skip to main content
Glama
parserelay

@parserelay/mcp

Official
by parserelay
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

@parserelay/mcp

ParseRelay's scan operation as an MCP tool — so any MCP host (Claude Desktop, Cursor, …) can parse a document into structured, confidence-scored fields. Same contract as the REST API and the <DeadSimpleMicroScanner> component; one tool, scan.

The scan tool

Input mirrors the sync ScanRequest — image (required), plus schema, doc_type, engine, ocr, dry_run, model, model_key. (relay webhooks are omitted: a tool call is synchronous, so you get the envelope back inline.) The result is the full ScanEnvelope as JSON: fields, per-field confidence, needs_review, field_source, and meta (engine, credits, tokens).

Set dry_run: true to preview which fields would trigger a paid rescue — and the estimated credits — without spending anything.

Related MCP server: Cognify MCP Server

Run it

stdio (Claude Desktop, Cursor)

{
  "mcpServers": {
    "parserelay": {
      "command": "npx",
      "args": ["-y", "@parserelay/mcp"],
      "env": {
        "PARSERELAY_API_KEY": "your-key",
        "PARSERELAY_BASE_URL": "https://api.parserelay.app" // optional
      }
    }
  }
}

streamable-HTTP (remote / hosted)

PARSERELAY_API_KEY=your-key PORT=8080 node node_modules/@parserelay/mcp/dist/http.js
# → POST http://localhost:8080/mcp

Stateless: a fresh server per request, so it scales horizontally. Auth per request via Authorization: Bearer <key>, falling back to PARSERELAY_API_KEY for single-tenant setups.

Programmatic

import { createMcpServer } from "@parserelay/mcp";
import { ParseRelayClient } from "@parserelay/client";

const server = createMcpServer(new ParseRelayClient({ apiKey }));
// then wire your own transport: await server.connect(transport)

Config

Env var

Required

Default

Notes

PARSERELAY_API_KEY

stdio: yes

—

HTTP can override per request via Authorization: Bearer.

PARSERELAY_BASE_URL

no

https://api.parserelay.app

Point at a local worker for testing.

PORT

no

8080

HTTP transport only.

Available Tools

1 tool
scanScan a documentA

Parse a document (receipt, invoice, form, ID) into structured, confidence-scored fields. Returns the ParseRelay envelope: fields, per-field confidence, needs_review, field_source provenance, and meta (engine, credits, tokens). Set dry_run: true to preview cost without spending.

ParametersJSON Schema
NameRequiredDescriptionDefault
ocrNoOCR backend selection. Use backend `passthrough` with `text` to skip OCR.
imageYesThe document to scan: an https URL or a base64 data URI (data:image/...;base64,...).
modelNoPin a specific model, e.g. "claude-haiku-4-5".
engineNoExtraction mode. Default `auto` (deterministic-first, LLM rescues only flagged fields).
schemaNoWhat to extract, in ONE of two forms: a field-name array, OR a JSON Schema object with a `properties` map. Do NOT pass a flat {"field":"type"} object. Omit for a generic document.
dry_runNoPreview only: returns which fields WOULD trigger a paid rescue + estimated credits, spends nothing.
doc_typeNoOptional document-type hint.
model_keyNoBring your own provider key — you're billed plumbing only; the model bill is on your key.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries full behavioral burden. It discloses the return structure (fields, confidence, needs_review, field_source, meta), indicates that dry_run previews cost without spending, and implies confidence scoring. It doesn't cover rate limits or errors, but the core behavior is transparent.

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 three sentences: purpose, return envelope, and cost preview tip. It is front-loaded and every sentence adds value without redundancy.

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?

For a complex 8-parameter tool, the description covers purpose, output shape, and an important usage tip (dry_run). It doesn't explain all parameters, but the schema is rich and self-documenting. Missing error-handling or prerequisites, but overall adequate for selecting and invoking the tool.

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 baseline is 3. The description mentions dry_run for cost preview, which is also in the schema, and does not add any additional parameter semantics beyond the schema. It doesn't need to compensate, so a baseline score is appropriate.

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 function: parse documents (receipt, invoice, form, ID) into structured, confidence-scored fields, and it names the exact output envelope. It is specific and distinct from any plausible sibling, with no tautology.

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?

It gives clear use context by listing document types and explaining the dry_run option for cost preview. While it doesn't mention alternatives (no siblings), it provides practical guidance on when to use dry_run and implies usage via the output format.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.1
    • First observedscan
Deploy Server
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

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion between overlapping tools. The tool's purpose is clearly defined and distinct.

Naming Consistency5/5

The single tool name 'scan' is simple, descriptive, and follows a consistent verb-based naming style. There are no mixed conventions or conflicting patterns.

Tool Count4/5

The server has only one tool, which is appropriate for its narrow scope as a document parser. While the count is lower than the typical 3-15 range, the tool covers the core functionality without feeling overly thin.

Completeness5/5

The 'scan' tool fully addresses the apparent domain of document parsing, including dry-run support for cost preview. No obvious missing operations are evident from the description.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • flexorch-mcp by flexorch

    flexorch-mcpofficial

    flexorch
    A
    license
    A
    quality
    A
    maintenance
    Enables Claude and other MCP-compatible agents to process documents, extract structured data, detect PII, and export LLM-ready datasets through natural language tool calls.
    8
    1
    MIT

  • Cognify MCP Server

    S3YED
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables document ingestion and typed knowledge graph queries through Claude MCP tools, allowing agents to extract, store, and retrieve typed entities and relations from documents.
    2
    MIT

  • Kynth Core MCP

    kyisaiah47
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables document parsing, field extraction, PII redaction, contract analysis, chargeback handling, and company enrichment via the Kynth Core API. Provides tools for Claude and any MCP client to process documents and extract structured data.
    21 npm
    MIT