MCP is a communication standard. It defines how an AI assistant (the client) talks to an external tool (the server). Think of it like USB for AI. Before USB, every peripheral had its own proprietary cable and driver. Printers, scanners, cameras, keyboards. Your desk looked like a wiring closet. USB created one interface that everything plugs into. MCP does the same thing for AI tool connections.
Before MCP, every integration between an AI model and an external service required custom code. Want Claude to search your files? Custom integration. Want it to query a database? Different custom integration. Want it to extract data from documents? Another one. Want it to post to Slack? Yet another. Each connection was bespoke, fragile, and maintained separately.
MCP replaces all of that with a single protocol. A tool developer builds one MCP server. That server works with Claude, Cursor, Windsurf, Cline, and any other client that speaks MCP. The AI assistant discovers what tools are available, understands how to call them, and handles the back-and-forth automatically.
Anthropic open-sourced the spec in November 2024. Within months, thousands of MCP servers appeared for everything from GitHub to Slack to database queries to document processing. The adoption was fast because the problem was real and immediate. Everyone building AI applications was drowning in integration code.
The architecture has four layers, but you really only need to think about the outer two: hosts and servers. Clients sit in between and handle the plumbing.
The host is the application on your screen. Claude Desktop, Claude Code, Cursor, VS Code with an AI extension.
Inside each host lives a client. It maintains a one-to-one connection with a specific MCP server, handling protocol-level communication. You never interact with it directly, and honestly you can forget it exists.
The server is the external tool itself. It exposes capabilities that the AI can call. A document extraction server, a database query server, a file system server. Each one runs as a lightweight process, either locally on your machine or remotely.
When you start a session, the client asks each connected server: "What can you do?" The server responds with a list of tools, their parameters, and descriptions. This is tool discovery, and it happens automatically. The AI assistant now knows what's available without anyone hardcoding a list.
Here's what the actual flow looks like when you ask Claude to extract data from an invoice:
extract_file_data tool.The whole exchange uses JSON-RPC 2.0 over standard input/output (for local servers) or HTTP with server-sent events (for remote ones). If that means nothing to you, the point is: it's simple, well-understood transport that any developer can implement in an afternoon.
MCP servers expose different capability types. Tools are the most common and what most people mean when they say "MCP." These are functions the AI can call: "Extract data from this PDF," "Run this SQL query," "Send this Slack message."
Resources are read-only data. File contents, database records, API responses. They give the AI context without requiring a function call.
There are also prompts, which are reusable templates for common workflows. A document extraction prompt might include instructions for handling multi-page invoices or formatting dates. These are less common than tools and resources, but they're useful when you want to standardize how an AI approaches a repeated task.
Document processing is one of the clearest wins for MCP, because the old workflow was genuinely painful.
Before MCP, if you wanted an AI assistant to process a document, you had two bad options. First: copy-paste the document text into the chat window. This loses formatting, ignores images and scans entirely, and falls apart on PDFs with complex layouts. Second: switch to a separate document capture tool, upload the file there, wait for results, copy the output, paste it back into your AI conversation. Context switching at its worst.
With MCP, you stay in one place. You tell Claude "extract the line items from this invoice" and it calls the connected extraction server, processes the document, and returns structured data. Same conversation. No tab switching.
But the real benefit goes deeper than convenience. Because Claude can chain MCP tool calls with its own reasoning, you get multi-step workflows that were impractical before. "Extract all invoices in this folder, compare totals against the purchase orders, flag discrepancies, and write a summary report." That sentence involves document extraction, data comparison, conditional logic, and file writing. With MCP, it's one conversation. This kind of end-to-end pipeline is what people mean when they talk about intelligent document processing.
Lido's MCP server is a good example of this in practice. It gives Claude access to template-free document extraction that works on any layout without per-vendor setup. You can ask Claude to process 50 invoices from 50 different vendors, normalize the data, and export to CSV, all without writing a script or opening a browser. For a step-by-step walkthrough, see our guide on extracting document data with Claude using Lido MCP.
The MCP ecosystem grew fast. As of early 2026, there are thousands of servers covering almost every tool category an AI assistant might need.
Servers like Lido, Koncile, and LandingAI ADE let AI assistants extract structured data from documents. Invoices, receipts, tax forms, purchase orders, insurance claims. The AI tells the server what fields to pull and gets organized data back. This replaces manual data entry for any document-heavy workflow and is one of the most practical applications of document automation today. Teams are using these servers to build AI agents that automate entire document workflows, and you can build your own in about 30 minutes. See our roundup of MCP servers for document processing for a detailed comparison.
GitHub MCP servers let AI assistants create pull requests, review code, and manage issues. Database servers let them query PostgreSQL, MySQL, or SQLite directly. File system servers give read/write access to local directories. These are popular with developers using Claude Code or Cursor, where the AI is already embedded in the coding workflow.
Brave Search, Google Maps, weather APIs, financial data feeds. MCP servers can connect AI assistants to live data that isn't in their training set. This is how an AI assistant answers "What's the weather in Tokyo right now?" when it otherwise has no way to access real-time information.
Slack, Google Drive, Notion, Linear, Jira. MCP servers for productivity tools let AI assistants read and write to the platforms where teams actually work. "Summarize the last 20 messages in #engineering" or "Create a Jira ticket for this bug" become single-step requests instead of multi-tab ordeals.
The breadth matters here. Every new MCP server added to the ecosystem becomes available to every MCP-compatible client simultaneously. A developer who builds an MCP server for their internal database immediately makes that database accessible from Claude, Cursor, and whatever else their team runs. Network effects, basically.
Installation varies by server, but the pattern is consistent. Here's how it works with the Lido MCP server.
You need Node.js 18 or later. Most MCP servers use npx for zero-install execution, so there's nothing to clone or build.
One terminal command:
claude mcp add lido -- npx -y @lido-app/mcp-serverThat registers the server. Claude Code launches it automatically in future sessions.
Edit your config file. On Mac it's at ~/Library/Application Support/Claude/claude_desktop_config.json. Add the server to the mcpServers object:
{
"mcpServers": {
"lido": {
"command": "npx",
"args": ["-y", "@lido-app/mcp-server"]
}
}
}Restart the app. The tools appear in the toolbar.
Cursor, Windsurf, Cline, and other editors have their own config methods, but the underlying command is the same. You point the client at npx -y @lido-app/mcp-server and it handles the rest.
Most MCP servers follow this same pattern: a single command or a small JSON config block. The protocol was designed so that installation takes thirty seconds, because nobody wants to spend an afternoon wiring up a tool connection.
If you already use APIs, you might wonder why MCP exists at all. APIs work fine. What problem does this actually solve?
APIs are point-to-point connections. Your application calls a specific API with specific parameters in a specific format. If you want to connect to ten services, you write ten integrations. Each one has its own authentication flow, error handling, rate limiting, and response format. That's manageable when you're building a product with a fixed set of integrations. It becomes a nightmare when you're building an AI assistant that needs to flexibly connect to whatever tools a user happens to have.
MCP is a standardized layer on top of APIs. The MCP server wraps an API (or a local tool, or a database, or anything else) and presents it through a uniform interface. The AI client doesn't need to know the specifics of each underlying service. It speaks MCP, and the server translates.
Here's a practical way to think about when to use each:
APIs make sense when you're building a production application with known integrations. You control both sides of the connection. You want maximum performance and fine-grained control. For teams that need direct programmatic access, Lido also offers a document extraction API that works outside the MCP layer.
MCP makes sense when you want AI assistants to interact with tools dynamically. The AI discovers available tools at runtime, decides which to call based on the user's request, and handles orchestration. MCP trades some raw performance for flexibility.
They're not competing. Many MCP servers are thin wrappers around existing APIs. Lido's MCP server calls Lido's extraction API under the hood. The API still exists for direct integration. The MCP server exists so AI assistants can use it conversationally.
One thing MCP handles that raw APIs don't: tool discovery. When Claude connects to an MCP server, it learns what tools are available, what parameters they accept, and what they return. With a raw API, someone has to write code that knows all of that in advance. This sounds minor until you're working with an AI assistant that connects to eight different services and you realize tool discovery turned what would be a complex integration project into a config file edit.
One of the highest-value applications of MCP is accounts payable automation. Finance teams deal with repetitive document workflows daily: invoices arrive by email, data gets keyed into ERPs, approvals bounce between people. MCP lets an AI assistant handle the extraction and routing steps conversationally.
With an MCP-connected document extraction server, a controller can say "pull the vendor, amount, and due date from every invoice in my inbox this week" and get structured data back in seconds. No switching between an email client, a PDF viewer, and a spreadsheet. Combined with MCP servers for email and spreadsheet tools, you can build end-to-end invoice processing pipelines from email to ledger without writing code.
MCP is a standard way for AI assistants to connect to external tools. Before MCP, every connection between an AI model and a tool required custom integration code. MCP defines a universal protocol so any AI client can work with any MCP-compatible tool. Build one server, and it works everywhere. Think of it as USB for AI: one standard plug that connects everything.
MCP works with any AI tool that implements the protocol. Anthropic created and open-sourced the spec, so Claude Code and Claude Desktop had early support. But Cursor, Windsurf, Cline, VS Code extensions, and other editors have adopted it. The spec is open and language-agnostic, so anyone can build an MCP client or server.
A regular API is a direct connection between two specific systems. You write code to call it, handle the response, and manage errors. MCP is a standardized wrapper that lets AI assistants discover and use tools dynamically without custom integration code. Many MCP servers use APIs internally. The difference is the interface layer: MCP provides tool discovery, uniform communication, and AI-friendly interaction patterns that raw APIs lack.
To install an MCP server, you need basic comfort with a terminal. Most installations are one command. After that, interaction is conversational. You tell the AI assistant what you need in plain English and it calls the appropriate MCP tools. Building a new MCP server from scratch does require development skills, but using existing servers does not.
MCP servers for document processing let AI assistants extract structured data from PDFs, images, and scans. Instead of manually copying data from invoices into a spreadsheet, you tell Claude to extract vendor names, totals, and line items, and it calls the connected extraction server. Tools like the Lido MCP server support template-free extraction that works on any document layout without per-vendor configuration.
There's no hard limit. Claude Code, Claude Desktop, and other MCP clients support multiple simultaneous server connections. You might run a document extraction server, a database server, and a file system server in the same session. The AI assistant picks the right tool based on your request. The practical limit is your machine's resources, since each server runs as a separate process.
%20(1).svg)
