11 min read
The Model Context Protocol (MCP) is an open standard for connecting AI applications to external tools and data sources through registered servers. In PaperIQ.ai, tenants register MCP servers per tenant scope so agents can call approved tools—query databases, post records, trigger internal APIs—after extraction produces schema-validated JSON. MCP is not a replacement for extraction. It is the automation layer that moves validated records from “JSON file on disk” into systems of record.
Most IDP projects stop at a CSV or API response. Operations still manually paste into Salesforce, NetSuite, Postgres, or custom line-of-business apps. Each new destination historically meant a bespoke integration project. MCP shifts the integration model: register tools once, expose them to tenant-scoped agents, and let orchestration call the right tool with structured payloads. PaperIQ emphasizes tenant isolation—servers registered to one tenant are not visible to others, and tokens are scoped accordingly.
1. Upload PDF batch (invoices, contracts, call-derived forms). 2. Extract with JSON Schema validation during generation. 3. Review exceptions in the job UI (records that failed schema checks). 4. Agent or workflow invokes MCP tools: `create_invoice_draft`, `upsert_vendor`, `attach_document_to_case`. 5. Audit trail ties extracted fields to tool actions. The value is continuity: the same platform that understood the document can act on it—without exporting to a human middleman for every row.
Traditional SaaS connectors ship a fixed catalog (Salesforce, QuickBooks, etc.). That works until you need an internal Postgres stored procedure, a niche ERP module, or a partner API that will never appear on a vendor roadmap. MCP lets engineering register **your** tools with metadata the agent discovers at runtime. PaperIQ’s narrative is “dynamic tool discovery for tenant-scoped automation,” not “we shipped 200 logos on a integrations page.” Trade-off: MCP requires someone to register and secure servers responsibly. PaperIQ supports an export-only path for teams not ready for tool calling.
Security buyers ask three questions: • Who can register MCP servers? Tenant administrators. • Can tenant A call tenant B’s tools? No—registration and JWT audience claims scope access per tenant and server URL. • Can we use our own models and keys? Yes—PaperIQ supports bring-your-own inference paths including local Ollama where policy requires it. Start with read-only tools in staging, then expand to write actions after schema pass rates stabilize.
MCP will not fix bad extraction. If schema pass rates are low, automating writes amplifies errors. Fix field definitions and validation first. MCP is also the wrong framing if you only need batch CSV export to an analyst team. In that case, validated export alone may be sufficient.
Phase 1: Schema-validated extraction + export to spreadsheet or database. Phase 2: Register one read-only MCP tool (e.g., lookup customer by ID). Phase 3: Add write tools for draft records, not production posting. Phase 4: Expand tool catalog as pass rates and approvals mature. PaperIQ’s agent chat and MCP registration live in the same tenant-scoped product surface described on the Features and Security pages.
Do I need MCP to use PaperIQ?
No. Many teams start with schema-validated extraction and export only. MCP is for automation into external systems when you are ready to register tenant-scoped tools.
How does PaperIQ authenticate MCP calls?
Tenant-scoped JWTs include audience claims tied to registered MCP server URLs. Servers validate tokens before executing tools.
Is MCP the same as Zapier or iPaaS?
iPaaS connects apps with predefined recipes. MCP connects AI agents to tools you register, with discovery metadata suited to LLM orchestration—not the same product category, though both can move data.