Our CEO — who also holds the CVO title, chief vision officer, and has been the one pushing AI research at the company in the first place — brought a problem to a meeting. A client's fiscal managers hand us a batch of budget-update PDFs, and getting that data into our system takes them 40 to 50 hours of manual extraction and reformatting, every time. He wanted to know why AI couldn't just do it: take the PDFs, transform them into something our system could import, and call it a day. That was roughly the whole vision.
Suffering from success
I suggested an MCP server. I'd heard the term and understood, vaguely, what it was for — letting an AI agent call real code and actually run functions instead of just describing what it would do. I had never built one, or used one, or set one up. None of that stopped me from saying it out loud as the answer, and the moment I did, it stopped being a suggestion and became my task. High priority, demo-ready expected, and I was now the one doing the research and development for it. There's a DJ Khaled line for this — "suffering from success" — and that's exactly what it felt like. I hadn't left myself an option to fail. I'd just volunteered for a tool I didn't know how to build yet.
Getting IT to say yes
Before I could build anything, MCP access needed to be turned on — it had been disabled company-wide over cost concerns, and that wasn't a switch I could flip myself. I made the case to IT anyway, in the limited terms I actually understood at that point: that in theory, a scoped MCP server could do exactly what the CEO had described, and that the cost concern was something to configure around, not a reason to keep it off entirely. I wasn't the expert in the room. I was just the one who'd already said yes.
The server, then the real work
Once access came through, I asked AI to build the server itself — a working MCP server in Python, plus a README documenting how it worked, since I already knew I wouldn't be the only one who'd eventually need to understand it. Getting the server running was the easy part. The real work was the tools I built on top of it: one that reviews an import file and scores how feasible it is to extract — how much of the data is actually recoverable, what's likely to get skipped, essentially a quality rating before anyone commits to using it. Another cross-checks the output against our SQL database's existing conventions, so what comes out the other end already matches our schema instead of needing manual cleanup afterward.
Chasing better extraction
Getting good data out of the PDFs turned out to be the actual problem. I tested several approaches: straight text extraction with various 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 instead of the raw text layer. Testing that many approaches, that quickly, isn't something I could have done without AI directing and building each variant — this was testing practice I designed, with AI doing the delivery. Each method got incrementally better, but never clean. Formatting kept coming out wrong, and pieces of data kept going missing no matter which method produced the fewest errors elsewhere.
It's not just me who thinks this is hard
After work one night, I went looking for how other people had solved this. What I found on Reddit and a few dev forums was more or less a consensus: PDF data extraction is a genuinely hard problem, and plenty of people who'd tried it concluded it wasn't worth solving generally. I brought it up at our next dev meeting, half expecting someone to have a trick I'd missed. Instead, the team had run into the same wall before and told me the same thing the forums had — push back on the ask.
I haven't pushed back yet. What I have is a working server, two tools that make any import measurably safer to trust, and a clear-eyed read on where the actual ceiling is instead of a guess. This project is turning into something bigger than the PDF import problem it started as — it's the proof of concept for what AI infrastructure looks like at this company, and I'm the one who has to deliver it. That's the same shape as the ADA agent and the UI rebuild before it: a gap nobody else is positioned to close yet, so I'm closing it.
The real reason I still haven't pushed back: I found the actual fix. Running a PDF directly through an LLM instead of a coded extraction pipeline sidesteps the ceiling entirely — no parsing library, no vision-model workaround, just the model reading the document the way a person would. The only thing missing is an LLM API endpoint of our own to run it against, which turned out to be exactly what the AWS AgentCore conversation was about.
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.