What Is an MCP Server for Due Diligence?

Updated October 2026 · 6 min read · Anweshna

What MCP is

The Model Context Protocol is an open standard for connecting AI applications to external systems: data sources, tools and workflows.^[1] Its own documentation compares it to a USB-C port for AI applications: one standard connector instead of a custom integration for every pair of systems. Claude, ChatGPT, Visual Studio Code and Cursor are among the clients that support it.^[1]

In practice, an MCP server publishes a short list of named tools, each with a description and typed inputs. The AI client reads that list, decides when a tool fits the user's request, calls it, and works with the result.

What a due diligence MCP server does

A diligence-focused server exposes the steps a reviewer would otherwise do by hand. Anweshna's server at https://anweshna.com/mcp/ exposes four tools:

A typical agent flow looks like this. A deal lead asks their assistant to screen the documents a seller just shared and summarise anything in a deal-blocking category. The agent calls bulk_screen, polls get_bulk_status, reads the findings, and writes a summary that cites the findings it relied on. The reviewer then opens the full report for anything that matters.

Why not just give the agent the PDF?

An agent can read documents itself, so why route them through a screening tool? For the same reasons a person would:

• A fixed ruleset. The tool scores against a fixed industry ruleset (15 categories for M&A), so two runs on two deals are comparable.
• Checked findings. Each finding is checked against the source text before it is returned, so the agent receives evidence rather than a paraphrase.
• Length handling. A filing too long for one pass goes to a chunked Deep Scan on plans that include it, or comes back as an explicit error, never as a quietly truncated result.
• A record. The screening is stored against the account, so a person can open the same report the agent summarised.

Connecting one

Any MCP-capable client takes the server URL and your API key as a header. The configuration is a few lines:

{
  "mcpServers": {
    "anweshna": {
      "url": "https://anweshna.com/mcp/",
      "headers": { "X-API-Key": "your-key-here" }
    }
  }
}

The server is stateless, so there is no session to keep alive. The agent acts as your account: it uses your plan's limits, your key's role and your billing, exactly as you would through the portal. Full reference, including the REST endpoints the tools sit on, is on the API and MCP integration guide.

The rule an agent must follow: a failed scan is not a clean result

The worst outcome in agent-driven diligence is an agent reporting "no issues found" about a document that was never scored. It is easy to build by accident: a tool call fails, the agent sees an empty list, and its summary says the document is clear.

Two mechanics catch agent builders out:

• Long scans don't block. On plans that include Deep Scan, a large document goes there automatically, and screen_document returns a "processing" status with a handle. The agent must poll get_analysis, not report the document as done.
• Request size binds first. Files travel base64-encoded inside the request, which adds about a third. A single call, including a whole batch, must stay under 32 MB, roughly 24 MB of actual document. Above that, the transport refuses with an HTTP 413 before any tool runs, so it arrives as a raw HTTP error rather than a tool error.

The risk that comes with agents: documents can talk back

Findings flow back into the agent's context, and the documents being screened came from a counterparty. A document can contain text written to steer an AI reader. Keep a person reviewing anything the agent acts on, and read Can a Document in the Data Room Manipulate an AI Reviewer? before you give an agent any authority beyond summarising.

What it doesn't do

An MCP server doesn't make an agent a due diligence team. The output is risk screening: where to look first, with evidence. It is not independent verification, and a clean result means "nothing surfaced in this document", never "this deal is clean".

Questions to settle before you connect an agent

1. Which key does the agent use? Give it a key with the narrowest role that does the job. A viewer key can read but not upload.
2. Who reads the agent's summaries? Name the person, and make it part of the workflow, not an afterthought.
3. What can the agent do with the results? Summarising is low risk. Sending results outside the team, or changing anything, deserves a human step.
4. How does it report a failure? Test it: send a file that is too large, and check the agent tells the user it wasn't screened.
5. Where does the output go? Findings returned to an agent pass into that agent's environment, under your arrangements with its provider.

Bottom line

MCP turns a screening engine into something an AI assistant can call by name. That removes the copy-paste step and makes agent workflows repeatable. Build the error handling first: an agent that can't tell a failed scan from a clean one is worse than no agent at all.

Try a screening run before you wire it into an agent →