DEV Community: Peter Ndumia

11 MCP Servers That Prove MCP Isn't Dead

Peter Ndumia — Fri, 16 Oct 2026 01:14:10 +0000

Disclosure: I'm the founder of PDFHaul, which is #5 on this list. Originally published on the PDFHaul blog, where the full source list with links lives.

An AI assistant can explain how to compress a PDF. That is useful once.

An AI assistant that can find the file, compress it, return the result, update a project page, and help create the image for an announcement is useful every day.

That difference is why the “MCP is dead” argument misses something important.

The criticism is real. Developers have connected poorly designed MCP servers, filled their agents’ context with tool descriptions, wrestled with authentication, and wondered why they did not simply call an API or use a command-line tool. In “MCP is dead. Long live the CLI,” Eric Holmes goes further. He argues that MCP offers no real-world benefit and that most work would be simpler, easier to debug, and more reliable with a good API and CLI. He cites composability, established authentication, fewer moving parts, and the ability for humans and agents to use the same commands. He also acknowledges that MCP can be useful when no CLI exists and that some cases may favor a standard interface.

That is a serious argument. If MCP merely wraps a CLI with extra setup, it has to justify the cost. But the wider claim that the protocol offers no practical benefit needs to account for what teams can do with connections built for AI clients across many services, not only what a local coding agent can do in a terminal.

MCP, the Model Context Protocol, gives an AI application a common way to discover and use capabilities provided by another system. It does not make every integration good. It does make a particular kind of workflow possible without rebuilding a separate connection for every assistant and every service.

Look at what people are already doing with it.

1. Azure turns cloud resources into tools an assistant can use

Imagine a developer investigating a failing application. They need to check a resource, inspect telemetry, and find the relevant service documentation. Without connected tools, the assistant can suggest commands, but the developer must keep moving between the chat, terminal, portal, and documentation.

The Azure MCP Server exposes Azure operations to compatible AI clients. Microsoft documents examples such as listing storage accounts and running KQL queries. In supported Visual Studio workflows, its tools can also help browse resources, run diagnostics, and work with deployments. Access remains tied to Azure credentials and permissions.

That does not mean an agent should make unreviewed production changes. It means the agent can work with the same relevant cloud context while the developer remains in control.

A CLI is valuable here too. In fact, Microsoft’s Azure tooling uses CLIs alongside MCP. The practical choice is which interface helps this particular agent and user complete the task reliably.

2. Microsoft Learn gives the assistant a route back to the documentation

An assistant can sound confident about a Microsoft feature it remembers incorrectly. That is particularly frustrating when product documentation changes.

The Microsoft Learn MCP Server lets a compatible client search Microsoft’s official technical documentation, fetch articles, and search code samples. It is a publicly available remote server.

This is a quieter example of MCP’s value. No dramatic autonomous agent is required. A developer asks a question, the assistant checks the relevant documentation, and the answer can be grounded in a source that the developer can inspect.

The capability is modest. That is precisely why it matters. Better access to current information is often more useful than another impressive-looking demo.

3. Notion connects an assistant to the work people have already organized

A team’s project knowledge rarely lives in one prompt. It lives across briefs, decision logs, tasks, notes, and databases. An assistant without access to that material can produce polished answers that ignore what the team has decided.

Notion MCP is a hosted server that lets an authorized MCP client search, read, create, and update accessible Notion content. Notion describes workflows in which a client searches pages, creates a page from the results, and updates its properties. The connection uses OAuth and is subject to workspace access controls.

Consider a project handoff. Instead of copying five pages into a chat, a user could ask an authorized assistant to find the current brief and decisions, draft a handoff page, and place it in the right workspace. The value comes from connecting the assistant’s reasoning to the team’s actual information and actions.

Could a developer write directly against the Notion API? Of course. Notion’s own MCP server uses its API. MCP’s value is in making those capabilities available through a standard interface to compatible clients, with a connection the user can authorize.

4. Higgsfield shows that MCP is about creation, not just retrieval

Many discussions treat MCP as a way for an assistant to look things up. Creative tools show the other half of the story: the assistant can also help produce an output.

Higgsfield’s MCP offering connects supported AI clients to image and video generation workflows. Its examples include adapting an ad into different aspect ratios and turning a creative prompt into generated visuals.

The interesting part is the workflow around the generation. A person can describe the objective, refine the direction in conversation, invoke a creative capability, inspect what comes back, and iterate. The assistant is no longer limited to writing a prompt that the person must paste somewhere else.

That does not guarantee that every image is good or that every generation is instant. It removes a handoff between deciding what to make and invoking the tool that can make it.

5. PDFHaul makes document work available inside the conversation

PDFs create their own handoffs. A person has a file and wants a result: merge documents, split out certain pages, OCR a scan, extract tables, or convert a report to Word. A general assistant can explain how to do those tasks. It needs access to document operations to carry them out.

The PDFHaul MCP server exposes 23 PDF tools to compatible clients, including merge, split, compression, OCR, conversion, table extraction, and exact-match duplicate-page removal. It also exposes file operations such as listing files and retrieving temporary download URLs. Users connect it with a PDFHaul API key.

For example, a user could ask an assistant to extract tables from a PDF into a spreadsheet, or to make a scanned PDF searchable before working with its contents. The assistant can invoke the relevant PDFHaul operation rather than stop at a set of instructions.

We built this because document work is often one step inside a larger job. People do not wake up wanting to “use a PDF tool.” They want to finish a report, prepare a submission, compare figures, or share a clean file. MCP allows PDF processing to become an available action within that broader workflow.

6. GitHub moves the assistant from code suggestions to project work

A coding assistant can draft a patch while missing the issue that prompted it, the pull request that attempted it last month, and the repository rules around the change. A developer then spends time gathering that context by hand. The GitHub MCP Server gives a compatible assistant a way to retrieve repository information, list pull requests, and work with issues through GitHub tools. GitHub also lets users configure toolsets, so an integration need not expose everything at once.

Picture a developer asking why a bug keeps returning. With appropriate access, an assistant can examine the issue history and relevant pull requests before suggesting a fix. It can help open a follow-up issue with the findings. That is more useful than confidently producing a patch from one pasted error message. The developer still needs to inspect the evidence, review the code, and decide what to merge.

This example also tests the familiar claim that the command line can do the same thing. The GitHub CLI is excellent for a developer in a terminal. An MCP connection can bring defined GitHub capabilities into a compatible assistant with configurable toolsets. The best interface depends on the agent, the user, and the permissions available. The point is that MCP makes project context and project actions accessible through a common contract.

7. Figma gives an assistant the design details that screenshots leave out

A screenshot tells a coding assistant what a screen looks like. It rarely tells the whole story about components, variables, layout, and the design system that produced it. If those details are absent, generated code can appear similar while drifting from the actual design. A person then has to explain spacing, naming, responsive behavior, and component choices all over again.

Figma’s MCP server exposes structured design context to supported development clients. Its documentation describes access to design elements such as components, variables, layout information, and, in supported setups, Code Connect mappings. The purpose is to help an agent implement a design with the context the design team actually used. It is not a promise that one tool call turns any mockup into production code.

A product team could hand a selected frame to a coding agent and ask it to build the screen using the existing components. The agent can inspect the design context while it works; a developer can compare the result to the design and test the behavior. That shortens the gap between a visual decision and an implementation decision. The integration is useful precisely because a design file carries more structure than a flat image.

8. Atlassian brings issues and decisions into the same task

A product change often begins in Jira, is explained in Confluence, and ends in a repository. The assistant working on the code may see only the last instruction, missing the acceptance criteria or a decision buried in a project page. That is how a technically sound change can solve the wrong problem.

Atlassian’s Rovo MCP Server is a cloud-hosted connection for compatible AI tools. Atlassian documents access to Jira and Confluence context, and its current guidance covers other Atlassian data in supported configurations. Its controls include the organization’s access policies. A team can give a compatible assistant the ability to look up the work item and supporting documentation, subject to what the connected user is allowed to see.

Consider a feature request with an ambiguous phrase such as “export the report.” The issue may specify the fields, while a Confluence decision records why one format was chosen. Reading those sources before implementation changes the quality of the answer. Afterward, an authorized agent might update the work item with what was done. The usefulness is not that Jira has an API. It is that the assistant can encounter the work in its original context at the point of need.

9. Google Maps grounds a conversation in actual places and routes

Not every valuable tool call is about software development. Ask a general assistant for nearby locations and it may rely on stale knowledge or produce an answer without a traceable place. The problem is even clearer for routes, where distance and duration depend on the actual origin and destination.

Google Maps Platform’s Maps Grounding Lite offers an MCP server with tools for place search, weather lookup, and route information. It can return place identifiers, coordinates, and Google Maps links alongside results. This is a concrete example of an assistant retrieving real-world context through a service built for that domain. It does not make every recommendation correct, and a user should still inspect the returned places and route details.

Imagine planning visits to several public locations. The assistant can ask the Maps service for candidate places, use the returned identifiers to distinguish similarly named locations, and request route information. It can then explain the options with linked places instead of pretending that its language model memory is a live map. MCP matters here because the same compatible client that handles a document or workspace page can also call a geospatial capability when the task requires one.

10. Cloudflare shows a way to keep a large service usable

One of the strongest objections to MCP is tool sprawl. If a server exposes hundreds of endpoints as separate tool descriptions, an agent may spend more context reading the menu than doing the job. Cloudflare’s own MCP servers are an interesting answer to that problem rather than a denial that it exists.

Cloudflare documents a search-and-execute pattern for its services. Instead of loading every API endpoint as an individual MCP tool, the agent can search a typed representation of the API and execute against the relevant capability. Cloudflare says an equivalent server with every endpoint exposed as a native tool would consume more than one million tokens of tool definitions. That comparison is Cloudflare’s, and the practical results depend on the client and task, but the design principle is clear: expose discoverable capability without making the model carry an enormous catalog.

A developer investigating a deployment or security configuration does not need every Cloudflare endpoint in the prompt. They need a reliable route to the small part of the service relevant to the question, plus appropriate account permissions. MCP gives Cloudflare a standard entry point while its server design addresses scale. This is the kind of implementation detail critics are right to demand, and the kind builders can improve.

11. Playwright lets an assistant inspect what a web app actually does

An assistant can write a plausible test for a web page it has never opened. It may invent a button label, miss an error state, or assume a form submits as intended. The Playwright MCP server, maintained in Microsoft’s Playwright project, gives compatible clients browser automation tools that use structured accessibility snapshots. The assistant can navigate, inspect page elements, interact with controls, and observe the result.

For a checkout-free signup flow or a document upload page, a developer could ask an agent to open the site, try the path, and report where it fails. The agent can read the page structure as it goes instead of relying entirely on a screenshot or a guessed selector. This is useful for exploratory debugging and iterative testing. It is not a substitute for a stable automated test suite, and any agent acting in a browser should have a clearly scoped environment.

Playwright also offers a CLI for coding agents. Its documentation explains that a CLI can be efficient for some coding workflows, while MCP suits specialized iterative loops with persistent browser state. That is a more useful conclusion than a protocol funeral. The same project can support both interfaces because they serve different working patterns.

What these examples prove and what they do not

These eleven examples do not constitute one magical assistant that can access every service at once. A client must support the relevant connection, the user or organization must authorize it, and the server must expose the needed capability. A successful tool call also does not establish that the resulting answer is accurate. The assistant must interpret the output, and a human should review consequential actions.

They do establish a narrower and stronger point: teams across cloud operations, documentation, workspace knowledge, media creation, document processing, code collaboration, design, project management, maps, infrastructure, and browser automation have found a use for a shared connection pattern. Those are different domains with different underlying APIs. The commonality is the assistant’s need to discover a capability, provide the right inputs, and receive usable output.

The measure of success is not the number of MCP servers installed. It is whether a particular connection reduces a real handoff while keeping permissions understandable and results verifiable. That is why a small, focused server can be more valuable than a giant catalog, and why an agent should ask for confirmation before an irreversible action. Better servers make the protocol feel less like plumbing and more like completed work.

The strongest CLI argument still deserves a direct answer

Holmes is right that a well-designed CLI is composable, inspectable by a human, and often already connected to an established login. A developer can pipe a huge Terraform plan through local filters without sending the whole thing into a model’s context. That is a genuine advantage. An MCP server that dumps the entire plan or replicates every command with worse authentication has not improved the workflow.

But “the CLI works well here” does not establish “MCP provides no real-world benefit.” Several examples above are hosted services used in AI clients that are not simply shells on the user’s machine. A person connecting an authorized Notion workspace, a Figma design, a Maps data service, or a PDF operation can use a client’s tool discovery and structured calls without each client separately learning a vendor’s CLI installation, command syntax, output conventions, and login flow. An official server can package domain-specific operations and authorization for more than one compatible client. That is a practical benefit if the integration is well built, even though its underlying service still has an API.

Nor does an official MCP server make a CLI obsolete. GitHub and Playwright provide especially useful counterexamples because both interfaces exist. One can prefer the CLI for a local coding loop and the MCP connection for a different client or an iterative tool workflow. The claim worth defending is conditional and testable: where a server gives an assistant relevant capabilities with less integration work and acceptable reliability, MCP earns its place. These published examples demonstrate concrete capabilities, not measured proof that MCP is faster than a CLI in every use case. That narrower conclusion is enough to challenge an obituary.

The critics are right about bad MCP servers

None of these examples proves that every MCP server is worth installing.

A server with dozens of vague tools can be harder for an agent to use than a focused CLI. A thin wrapper around an existing API may add little value. Authentication and permissions need careful design. Outputs need to be useful to the model without flooding its context. Any action that changes data deserves an appropriate review path.

These are product and implementation questions. They should be tested, not waved away.

Quandri Engineering, for example, published measurements criticizing context use and reliability. Its article now includes an update saying that deferred tool loading in current Claude Code versions largely addressed the specific context-bloat problem it measured, while other concerns remain. That is what a useful technical debate looks like: make a claim, measure it, and revise it when the tools change.

MCP is also evolving. Its maintainers have published a 2026 roadmap covering scalability, governance, and enterprise use. A roadmap is not proof that every problem is solved, but it is evidence of an actively developed protocol rather than an abandoned idea.

The question is what the assistant needs to do

If an agent needs one local command and a well-documented CLI already exists, use the CLI.

If an application needs a reusable, permission-aware connection to a service that many compatible assistants may use, an MCP server can make sense. If the task spans cloud resources, documentation, workspace content, creative production, and PDFs, a shared way to expose those capabilities becomes more compelling.

Azure, Microsoft Learn, Notion, Higgsfield, PDFHaul, GitHub, Figma, Atlassian, Google Maps, Cloudflare, and Playwright illustrate different parts of that picture. Their existence does not prove that any single combined workflow is automatically available in every client. It shows that useful capabilities are being made available through the same protocol.

That is the part the obituary gets wrong.

MCP does not need to replace APIs or CLIs to be valuable. APIs remain the underlying service interfaces. CLIs remain excellent tools, especially for developers. MCP gives compatible AI applications a structured way to use capabilities exposed by those systems.

The interesting question in 2026 is no longer, “Can an assistant talk about the work?”

It is, “Can the assistant reach the right tools, with the right permissions, and help finish it?”

That is why MCP is still worth building well.

Sources: the full list of references, with links, is in the original post. If you want to try the PDFHaul MCP server from this article, setup steps are in the docs.

Why Extracting Tables From a PDF Is Harder Than It Looks (and How We Actually Do It)

Peter Ndumia — Wed, 19 Aug 2026 00:36:56 +0000

If you have ever copy-pasted a table out of a PDF, you already know what happens. Rows collapse into one long line of text. Columns interleave. Numbers land in the wrong cell, or no cell at all. The table on the page looks perfectly structured, but a PDF has no real concept of "table." It only knows where individual characters sit on a page. Every extraction tool, ours included, has to reconstruct the table from scratch, using nothing but the position of each word.

That gap between "looks like a table" and "is structured data" is where almost every free PDF tool falls apart. Here is how we handle it, what actually works, and where it still doesn't.

Two different jobs, two different tools

PDFHaul splits this into two separate tools because they solve different problems.

PDF to Excel rebuilds the whole document as a single spreadsheet, in the order it appears on the page: form labels, key-value pairs, section titles, and tables all together. It is for documents where you want the full content, not just the numbers, things like invoices, time sheets, and reports.

Extract Tables does the opposite. It ignores everything that isn't a table and hands back one clean sheet per table, nothing else. It is for people who want structured data out, ready to sum, sort, and filter, not a copy of the document.

Both tools share the same underlying geometry engine. The difference is what each one keeps and what it throws away.

How Extract Tables actually decides what's a table

The core problem with table extraction is that "looks tabular" and "is tabular" are not the same thing. A vector chart's axis box, a form's outlined signature field, and a two-column list of allergen names all produce something that a naive extractor will happily read as a grid. None of them are tables.

Our pipeline handles this in four phases, all before anything is written to a spreadsheet:

Phase 1: classify the page. Every page is scored as bordered (has ruled lines or filled-rectangle grid lines), stream (no borders, but rows visibly span both sides of a column gap), columnar (independent parallel lists that never interact), or plain text.

Phase 2 and 3: run the right extractor for the layout. Bordered pages go through Camelot's lattice mode. Borderless but structured pages go through Camelot's stream mode. Neither result is trusted blindly.

Phase 4: catch what the first pass missed, and gate everything. This is the important part. Every candidate table, whether it came from Camelot, from an explicit rectangle grid, or from our own zone-based word extraction, has to pass a classifier before it is counted as a table at all. The classifier checks column count, row density, and how numeric or short the cell contents are. A form field's outline box or a chart's axis lines will fail this check and get demoted to plain text instead of becoming a two-cell "table." Without this gate, Camelot's own false positives, grid-shaped chart elements, form outlines, would get counted as extracted tables. With it, only genuine tables make it through.

Underneath all four phases sits a shared geometry layer that does the actual measuring: it finds page gutters by picking the split point that divides the text most evenly (not just the widest gap, which a table's own label-and-value gap can be wider than), clusters words into lines by their vertical center rather than their top or bottom edge (so bold headers and footnote superscripts don't throw off row grouping), strips dot leaders like "Section..........12" before measuring column gaps (leaders fill the whitespace a gap detector relies on), and merges a wrapped label back onto the row it belongs to before anything gets written out.

Tables that span a page break get stitched back together too. If two adjacent pages produce tables with the same column count, and the second page's first row looks like a repeat of the first page's header (fuzzy-matched, so "Week No." and "Week Number" still count as the same header), they are joined into one continuous table instead of two separate sheets.

The numbers

We measure this against a verified 20-PDF corpus spanning financial reports, government tenders, laws and regulations, and scientific articles, scored on both cell content and correct row and column placement.

	Content accuracy	Structure accuracy
PDF to Excel	84% average (94% typical)	79% average (89% typical)
Extract Tables	84% average (100% typical)	83% average (100% typical)

Average and typical (median) diverge because a handful of document types outside our core use case, dense mathematical notation and pages built around vector charts, drag the average down. Inside the core use case, financial, business, and legal documents, both tools sit at 83 to 100 percent uniformly across every file we tested.

What it's not good at yet

We would rather tell you this directly than let you find out the hard way.

Scanned PDFs get real table detection too, not just text. We run OCR automatically before extraction starts, no separate step needed. For tables with visible ruled borders, the table-line detection itself runs directly on the rendered page image, so it works whether the underlying PDF has any vector graphics data or not, a scanned bordered table gets picked up the same way a native one would. The honest limit: table shape detection is one thing, text quality is another. A low-resolution or heavily degraded scan can still produce garbled cell content even when the table's structure is found correctly, since that depends on how much a scanner or camera actually captured, not on our extraction logic.

Pages with charts can leak garbage. A vector chart's axis numbers and legend entries currently extract as short text blocks alongside the real content, because the classifier correctly recognizes they aren't tables, but nothing yet recognizes they belong to a chart and should be dropped entirely, keeping only the caption. This is the single biggest gap we're working on.

Dense academic and mathematical notation is a genuinely different layout problem, and accuracy drops to 35 to 52 percent on that category. If your PDF is a math-heavy research paper, expect a rougher result than a financial statement.

Outside those three cases, financial reports, government forms, contracts, business documents, this is what the tool is actually built for, and the numbers above reflect that.

What's next

For the harder cases above, badly degraded scans, dense academic layouts, chart-heavy pages, we're looking at a premium tier built on Google's Document AI, a cloud model trained specifically on document structure rather than the geometry-based approach described here. It would not replace what's already free, it would be an option for the documents that currently come out rough.

So we'll ask directly instead of guessing: would you pay for more accurate extraction on your hardest documents, the ones that don't come out clean today? Tell us.

Try it

Extract Tables and PDF to Excel are both free, with no account required for a single file. Upload a PDF and see which one gives you what you need: the full document, or just the numbers.

I Built an MCP Server So AI Assistants Can Process PDFs Directly

Peter Ndumia — Mon, 03 Aug 2026 19:35:24 +0000

I run PDFHaul, a free browser and mobile PDF toolkit, as a solo founder. A few months ago I kept running into the same friction point: every time I wanted an AI assistant to help with a PDF task, I had to manually download the file, upload it somewhere, run the tool, then feed the result back into the conversation. For anything involving more than one file, that loop got old fast.

So I built an MCP server for PDFHaul. This post covers what it does, how it's built, and a few of the harder decisions along the way.

What MCP Actually Solves Here

Model Context Protocol gives an AI assistant a standard way to call external tools directly, instead of a person acting as the manual bridge between the assistant and every service it needs. For PDF work specifically, that means an assistant like Claude or Cursor can merge, split, compress, or convert a file as part of a conversation, without a human stepping out to run the tool separately.

The PDFHaul MCP server exposes 12 tools across four categories: file management, editing, conversion, and compression. It's live at pdfhaul.com/mcp-server, where you can find setup instructions and generate an API key.

Architecture

The server runs on the same Node.js/TypeScript and GCP Cloud Run infrastructure as the rest of PDFHaul, which kept the initial build simpler than starting a separate service from scratch. The tools themselves wrap the existing PDF processing logic, so I wasn't rebuilding PDF handling, just exposing it through a new interface.

A few decisions that took more thought than I expected:

Auth. API keys are hashed with bcrypt before storage, and requests are authenticated with a combination of the API key and a JWT. I didn't want to store anything resembling a plaintext credential, even for a free product, since API keys tend to get pasted into config files and committed by accident more often than anyone would like to admit.

Rate limiting. In-memory rate limiting per key, tuned conservatively at first. Cloud Run's stateless nature means in-memory limits reset on cold starts, which is a real tradeoff worth knowing about if you're building something similar. I accepted it for now rather than standing up Redis for a v1.

SSRF prevention. Several of the tools accept a URL as input (for example, fetching a PDF to process rather than uploading bytes directly). Any tool that accepts a URL from the caller is a potential server-side request forgery vector, so requests are validated against a blocklist of internal IP ranges and non-HTTP(S) schemes before the server ever fetches anything.

Idempotency keys. AI assistants sometimes retry tool calls, whether from a timeout, a dropped connection, or the assistant itself deciding to try again. Without idempotency handling, a retried "merge these files" call could produce duplicate output or double-charge a rate limit. Each mutating tool call accepts an idempotency key so a retry returns the original result instead of redoing the work.

Audit logging. Every tool call is logged with enough detail to reconstruct what happened, without logging the file contents themselves. This matters more for a PDF tool than it might for other APIs, since the whole product's trust model is built around not retaining user files longer than necessary.

Getting Listed

The server is listed on the official MCP registry, which so far has been the main discovery channel. Compared to building a plugin or waiting on marketplace approval in other ecosystems, the registry listing process was refreshingly lightweight.

Where This Leaves Things

Foxit and Nitro are the other PDF vendors I've seen building MCP servers, both larger companies with existing enterprise PDF products. Being early here as a solo founder is less about outcompeting them head-on and more about being genuinely useful to the AI-assistant-tooling crowd before the space gets crowded.

If you're working with PDFs inside an AI assistant workflow and want to try it, the server is free to use: pdfhaul.com/mcp-server. I'm happy to answer questions about the implementation in the comments, especially on the auth or SSRF handling if anyone's building something similar.

Peter, founder of PDFHaul