Improving my approach to the MCP integration

When Anthropic released the Model Context Protocol, the natural response was to ship an MCP server. Expose your functions, publish the spec, let clients call your API from their LLM workflows. That is what MCP is for, and it is not wrong as a starting point.

Industry pressure to stay on the bleeding edge for AI products meant that exposing the core functions the same exact way an API would gain the company an easy win.

An MCP server exposing the platform's core functions across the document automation workflow:

• Document upload and ingestion.
• Extraction retrieval by document, field, and entity.
• Validation states and exception flags.
• Assignment and routing controls.

The connection worked. Clients could invoke platform functions directly from Claude or their existing LLM workflows. But the design stopped short of what it should have been, and that is the more useful lesson.

The problem is that a function wrapper is not a product decision. Most MCP implementations expose individual operations: upload a document, retrieve an extraction, review. The caller then has to know which functions to call, in what order, with what inputs, to accomplish anything meaningful. That is not an integration. That is an API with extra steps and a new orchestration burden on the client side.

In a high-stakes document workflow platform, that burden is directly addressed. The returned data is carefully shaped by the forward-deployed engineers because not only did it return cleaned and enriched data, it equipped the user with visibility and access control, document timeliness tracking, cross-document linkages, and validation flags for where a human needed to review.

A function wrapper that returns a bare extracted value strips all of that out. The client's agent received a number with no context for whether to act on it, escalate it, or route it for review.

A skill is not a function wrapper. A function returns what you asked for. A skill accomplishes something meaningful and returns everything a downstream system needs to decide what to do next. "Obtain marketable securities from this financial statement" is a skill. It should return:

• The specific value resulting from summing extracted values in the "Assets" table for "marketable equities" and "marketable debt."
• Validation state(s) and references to other data within the document, such as common stock plus preferred stock not adding up to marketable equities.
• Cross-document references that corroborate or conflict with it:
  • Simple, one-line comparisons: check if equal to "Ending Market Value/Aggregate Fund NAV" from the corresponding entity's (see the Data SITREP) Custodian Statement.
  • More complex flows built into the MCP skill: from the 10-K Fair Value document, sum "Level 1 Assets" and "Level 2 Assets" and then determine equivalence to "marketable equities."

Ultimately, the caller's agent should be able to make a routing decision from a single response without knowing anything about the steps that produced it.

Any skills-based MCP design also needs to account for the fact that the calling user must be identified, and the governance and entitlements system determining what documents they have access to must apply.

At its heart, my learning from this experience was to build for skills, not individual functions, and return everything that a downstream agent needs to act, rather than just the value it asked for.

The instinct to expose individual functions is understandable. It maps cleanly to how APIs are designed, and it feels complete once the connection works. But a client agent that has to orchestrate five function calls to accomplish one goal, then parse ten separate responses to understand what happened, has not gained anything over a direct API integration. The protocol changed. The complexity did not.

The design that would have been right: compose the functions into skills oriented around what a client's workflow actually needs to accomplish, and build the response schema around what a downstream agent needs to act, not around what the platform happened to surface. Validation state, document linkage, review status, assignment context. Everything that lets the next step in the workflow happen without a human in the middle performing and defining the mundane checks from different sources should have been in place.

MCP as a protocol surface for financial document workflows is early. The interesting design problems are not in what functions to expose but in how workflow state, validation context, and exception handling travel across an agent boundary into a client's LLM orchestration layer. That is a product problem before it is a technical one.

Delivering MCP as a skill also eliminates the necessity of client training and replaces it with a more concentrated effort between the forward-deployed team and the client to build a reusable system. This also mitigates the risk of a client-side process failing or being defined poorly and having that reflect badly on the document intelligence product itself.