Forem: Aakash

A bank statement PDF to Excel converter sounds like a solved problem until you actually start looking at real statements. The easy part is getting some rows out. The hard part is getting output that somebody can trust enough to use without doing half the work manually again.

That was the big realization for me.

What looked like a simple OCR or extraction problem turned out to be a much uglier workflow problem involving layout variance, scanned documents, broken tables, inconsistent debit and credit conventions, balance mismatches and a very unforgiving downstream use-case. In accounting and bookkeeping workflows, “almost correct” is often just a slower form of manual work.

That is the problem space I ended up getting into with a friend of mine, and it eventually became the basis for Smart Bank Statement.

The naive version of the problem

On paper, this problem sounds embarrassingly simple.

Take a PDF bank statement. Extract the rows. Put them into Excel or CSV. Done.

That is how most people think about it at first, and honestly, that is also how a lot of tools position it. They talk about conversion as if the job ends the moment rows appear in a spreadsheet.

But that framing hides the real problem.

Because when somebody says they want to convert a bank statement PDF into Excel, they usually do not mean “give me some table-like output.” They mean “give me data that is clean enough to reconcile, import, audit or work with downstream without me babysitting every row.”

That is a much higher bar.

Once you use that bar instead of the softer “did we extract something?” bar, the problem changes shape immediately.

Where things start breaking

A lot of document workflows look good right until you leave clean demo inputs and meet real files.

Bank statements are especially annoying because the documents vary in all the ways that matter. Some are digital PDFs with selectable text. Some are scanned. Some have low quality images. Some use multi-column layouts. Some place debit and credit in separate columns. Some collapse them into one amount column and expect the sign convention to imply direction. Some carry balances row by row. Some do not. Some have strange description wrapping or continuation rows. Some have pages where the statement header, footer or summary table looks suspiciously like transactional content.

And then there are the really fun ones: documents with multiple accounts in one file, broken table boundaries, passbook-style formats or statements where the extraction is not catastrophically wrong, just subtly wrong enough to waste your afternoon.

That last category is the one I dislike most.

If the extraction completely fails, at least the failure is obvious. If it succeeds just enough to look plausible while still shifting a row, dropping a value or distorting a balance trail, the user has to detect it manually. In finance workflows, that is where trust gets destroyed.

Why OCR accuracy is the wrong metric

One thing I became more skeptical of very quickly is marketing around raw OCR accuracy.

The reason is simple: accuracy by itself is too vague to mean much in this context.

A tool can claim very high extraction accuracy and still fail the actual workflow. It can extract text well and still produce inconsistent structure. It can identify numbers correctly and still associate them with the wrong row. It can read a page and still mis-handle the running balance. It can parse a date and still break when a narrative spills across lines.

So the real question is not just, “How accurately did you read the document?”

It is, “Can the output be trusted enough that the user saves time instead of spending that time validating the tool?”

That is a very different metric.

In bookkeeping or accounting, 99% correctness is not automatically good if the missing 1% takes disproportionate effort to find. One bad transaction can force somebody to retrace the whole sheet. A balance mismatch means somebody has to stop and investigate. A few line items shifted out of place can make a reconciliation job unreliable.

So for me, this stopped being an OCR problem pretty fast. It became a trust, validation and downstream-structure problem.

The market realization

This part also changed how I thought about the product side of it.

When I first got into this space, the broader finance angle looked tempting. Dashboards, summaries, analysis, personal finance views, maybe even a bigger “financial intelligence” layer. That all sounds interesting, and it demos well.

But the pain there felt softer.

The harder, more immediate pain was earlier in the pipeline: getting messy statements into a usable format in the first place. Before dashboards, before analytics, before any fancy insight layer, there is an ugly preprocessing problem. And if that problem is not solved well, everything after it gets contaminated.

That was where things started becoming more compelling.

My friend Rupam had already been exploring the space when I got involved. Once I joined, a lot of our conversations became less about “what broad finance thing can we build?” and more about “where is the sharper workflow pain, and what are people already wasting time on?”

That question led us toward bank statements and document conversion much more strongly than toward the analyzer-style direction.

What building around this taught me

The first lesson was that “PDF to Excel” is one of those phrases that hides an enormous amount of unpleasant detail behind a very normal-sounding sentence.

The second lesson was that narrowing the product made it stronger.

There is a strong temptation, especially early on, to make a product broader because broader sounds more ambitious. In reality, broader often means blurrier. The more we looked at the workflow, the more it made sense to stay focused: take bank statement PDFs, extract the data, normalize it properly and make the result actually usable.

The third lesson was that extraction is only one layer. Validation matters just as much. In some cases, more. If you do not have ways to detect suspicious output, verify balance consistency or surface probable mistakes, you are not really solving the full problem. You are just producing output that still needs human suspicion attached to it.

And once human suspicion becomes mandatory, part of the product value disappears.

What we ended up building

That is the line of thinking that eventually became Smart Bank Statement.

Rupam had the initial seed of the idea. I joined once things were already moving, and together we pushed it through the more difficult stage: looking harder at the market, rejecting the softer and more crowded direction, narrowing the scope and getting an MVP built around a workflow that felt painful enough to matter.

I do not find that story as glamorous as the polished startup version where the product vision arrives fully formed from day one. But it is closer to how real products actually happen.

Aakash — Mon, 16 Mar 2026 18:39:25 +0000

Aakash

Mar 16

The day my MCP adapter stopped being just plumbing

#showdev #ai #mcp #security

Comments

6 min read

The day my MCP adapter stopped being just plumbing

Aakash — Mon, 16 Mar 2026 18:35:56 +0000

TL;DR: Remote MCP Adapter started as a usability layer for remote MCP workflows, but recent MCP tool-poisoning research made one thing painfully clear: middleware in the path is also part of the security boundary. In v0.3.0, I added tool-definition pinning, drift detection, metadata sanitization, description minimization, and stricter session binding to reduce what unsafe upstream metadata and session misuse can do.

After finishing the core work for Remote MCP Adapter, I did what most of us do after shipping something that finally works: I stepped back and started looking around.

I wanted to see how other people were dealing with the same class of problems. Remote MCP is useful, but once the client and server stop sharing a filesystem, things get ugly fast. Uploads become awkward. Generated files become awkward. Anything involving screenshots, PDFs, artifacts, or session-scoped state becomes awkward. That was the original reason I built the adapter in the first place.

I wrote more about that side of the story in the earlier blog that inspired this work.

Then I ran into a post on DEV: Your MCP server's tool descriptions are an attack surface.

That post, along with the underlying research it points to, forced an uncomfortable realization.

The adapter I had built to make remote MCP usable had already placed itself in the middle of a trust boundary.

And if something sits in the middle of a trust boundary, it does not get to pretend it is just plumbing anymore.

The realization

My adapter was already doing serious work. It was sitting between the client and upstream MCP servers. It was forwarding model-visible tool metadata. It was managing uploads, artifacts, and per-session state. It was translating behavior across boundaries that do not exist in local-only setups.

That is the kind of component people often mentally classify as a thin relay.

It is not.

Once a gateway or adapter sees tool catalogs, schema text, descriptions, session identifiers, uploads, auth context, and returned artifacts, it has already become part of the system's security posture whether the maintainer planned for that or not.

That was the moment the project changed in my head.

Remote MCP Adapter was no longer just a convenience layer for remote file and artifact handling. It had also become a natural enforcement point.

Not a silver bullet. Not an AI firewall. Not some magical solution to MCP security.

But definitely an enforcement point.

What changed in v0.3.0

v0.3.0 is the first release where I treated the adapter like that explicitly.

The goal was not to solve all MCP security problems. That would be dishonest.

The goal was narrower and much more practical:

stop blindly relaying model-visible tool metadata
detect when tool definitions drift mid-session
reduce how much unsafe or unnecessary description text reaches the model
tighten the adapter's own session semantics once stateful features and auth are involved
document what is implemented and what is still out of scope

That led to five concrete changes.

1) Safer defaults for model-visible tool metadata

The adapter now takes a stricter default stance for tool metadata.

core.tool_metadata_sanitization.mode now defaults to sanitize
core.tool_definition_pinning.mode now defaults to warn

That default matters.

Before this, users had to think like security engineers up front and opt into the right behavior. Now the adapter starts from a safer position and becomes stricter from there if the environment demands it.

I prefer that tradeoff. A lot of security features die in the field simply because they exist only as options nobody enables.

2) Tool-definition pinning and drift detection

This one addresses what some people are calling the "rug pull" problem.

If a server presents one tool catalog at the start of a session and then later changes tool titles, descriptions, or schemas, that is not a harmless cosmetic update anymore. That is model-visible behavior changing under an already-established trust relationship.

So the adapter can now baseline the first visible tool catalog for a session and compare later catalogs against it.

When a drift is detected, policy decides what happens next:

warn
block
invalidate the session entirely

This is not meant to be clever. It is meant to be boring and reliable.

If the thing the model sees has changed, that change should not pass through silently.

3) Metadata sanitization before forwarding tool schemas

Tool poisoning is not only about the top-level tool description.

That is one of the most important takeaways from the recent research. Once tool metadata enters the model context, any model-visible text can become an instruction surface: titles, descriptions, schema text, annotation titles, nested descriptions, and other fields that look harmless when treated like normal software metadata.

So v0.3.0 adds model-visible metadata sanitization for:

tool titles
tool descriptions
annotation titles
schema text

In stricter mode, the adapter can block tools with dirty metadata instead of forwarding them at all.

This is the right place to be conservative. If the middleware is already on the path, it should at least stop acting like every upstream schema is innocent by default.

4) Tool description minimization and stripping

There is now a unified tool_description_policy that applies to both top-level tool descriptions and nested schema descriptions.

It supports three modes:

preserve
truncate
strip

This one is especially useful for paranoid or tightly controlled environments.

Sometimes the right answer is not "try to detect every clever poisoning trick in free-form description text."

Sometimes the right answer is: why is this much prose reaching the model at all?

That is what this policy is for.

If an environment does not need rich description text, it should be allowed to minimize or remove it completely.

5) Stricter session binding when adapter auth is enabled

This one is less flashy, but it matters.

Once the adapter stores uploads, artifacts, cancellation state, or other per-session data, session integrity stops being just an MCP transport concern. It becomes part of the product's own security model.

So when adapter auth is enabled, sessions are now bound to the authenticated context that established them.

That means a reused Mcp-Session-Id cannot simply be picked up under a different authenticated context.

If the adapter is going to own state, then it also has to own the consequences of that state being misused.

Why I did not want to oversell this

It would be very easy to market all of this as:

"Remote MCP Adapter now protects you from MCP poisoning."

That would be lazy and false.

What v0.3.0 does is much more specific.

It gives the adapter enough awareness and policy surface to stop being a blind forwarder of model-visible tool metadata and state.

That helps.

It does not magically solve:

first-seen poisoning that looks semantically legitimate
every novel encoding trick
every schema-level manipulation pattern
every exfiltration path through allowed downstream tools
every bad trust decision made elsewhere in the stack

Those limits matter, and pretending otherwise would make the release less trustworthy, not more.

Evidence and implementation trail

I did not want this release to be just a changelog dressed up as a security post, so I wrote and linked the supporting material as well.

The implementation and evidence trail for this work lives here:

GitHub repo: Remote MCP Adapter
Security snapshot: https://github.com/aakashH242/remote-mcp-adapter/blob/main/SECURITY.md
Dedicated security docs: https://aakashh242.github.io/remote-mcp-adapter/security/
Issue 22 — Tool definition pinning and drift detection: issue #22
Issue 23 — Normalize and sanitize tool schemas before forwarding: issue #23
Issue 24 — Tool description minimization / stripping: issue #24
Issue 25 — Harden adapter-managed session semantics: issue #25
Evidence blog: https://aakashh242.github.io/blog/2026/03/16/dev-blog-securing-remote-mcp-adapter-1-evidences.html

Credit where it is due

This release did not come out of nowhere.

The immediate push came from reading Your MCP server's tool descriptions are an attack surface, along with the research and guidance around MCP tool poisoning and schema manipulation.

That post is worth reading, and so is the work behind it.

If you are exploring the security side of MCP seriously, do check out Pipelock as well. It takes a more security-focused posture as a dedicated control point, and it is useful to see how others are approaching the same family of problems.

If you are running remote MCP setups in a team or organization and have seen poisoning, schema weirdness, or mid-session tool drift in the wild, I would genuinely like to hear about it. Real attack samples and ugly edge cases are far more useful than clean toy examples when deciding what to harden next.

I Added Code-Mode to My MCP Gateway to Beat Context Bloat

Aakash — Tue, 10 Mar 2026 21:28:10 +0000

Aakash

Mar 10

Too Many MCP Tools Make Agents Worse - Here’s How I Fixed It

#ai #mcp #agents #llm

Comments

4 min read