Our CEO (also chief vision officer, and the person pushing AI research at the company) brought a problem to a meeting. A client's fiscal managers hand us a batch of budget-update PDFs in non-standard, irregular formats, and reading them and doing the data entry into our systems takes 40 to 50 hours every time. He wanted to know why AI couldn't take the PDFs, turn them into something our system could import, and be done.
Suffering from success
I suggested an MCP server. I knew roughly what it was for, letting an agent call real code instead of describing what it would do, but I'd never built one, used one, or set one up. The moment I said it, it stopped being a suggestion and became my task: high priority, demo expected, mine to research and build. I'd volunteered for a tool I didn't know how to make yet.
Getting IT to say yes
MCP access was disabled company-wide over cost concerns, and turning it on wasn't my call. I made the case to IT in the limited terms I understood at that point: a scoped MCP server could do what the CEO described, and the cost concern was something to configure around rather than a reason to keep it off. I wasn't the expert in the room, just the one who'd said yes.
The server, then the real work
Once access came through, I had AI build the server, a working MCP server in Python plus a README, since I knew others would need to understand it. That was the easy part. The real work was the tools on top: one that reviews an import file and scores how much of the data is recoverable and what's likely to get skipped, a quality rating before anyone commits to using it; another that cross-checks the output against our SQL database's conventions so it matches our schema without manual cleanup.
Chasing better extraction
Getting good data out of the PDFs was the hard part. I tested straight text extraction with several Python libraries, PDF-to-semantic-HTML, PDF-to-Excel, and vision-based methods that screenshot the regions a model thinks are tables and read the data off the image. Testing that many approaches that fast wasn't something I could have done without AI building each variant. Every method improved on the last and none came out clean: formatting kept breaking, data kept going missing.
Other people think this is hard too
One night I went looking for how other people had solved it. Reddit and a few dev forums were near-consensus: PDF data extraction is a hard problem, and plenty of people who tried concluded it wasn't worth solving generally. I raised it at the next dev meeting and the team said the same thing the forums had: push back on the ask.
I haven't pushed back, because I found the direction. Running a PDF straight through a foundation model instead of a coded extraction pipeline skips the ceiling every coded approach hit: no parsing library, no vision workaround, the model reads the document the way a person would. I'm now working directly with AWS to use their tools to extract data from the irregular formats, and it's making good progress. It's active development, not a stalled project.
What I have now: a working server, two tools that make any import safer to trust, and a real path through the extraction problem. It's become the proof of concept for what AI infrastructure looks like at this company, the same shape as the ADA agent and the UI rebuild: a gap nobody else was positioned to close.
Update: that proof-of-concept framing turned out to be right. See the follow-up on the two MCP servers I built next, for my own dev workflow.