DongHyuk Lim Forward Deployed Engineer
ENKO

Enterprise Integration / Investment Platform

Turning an MCP request into six working investment workflows

The customer asked for “an MCP server for investors,” but there was no product specification behind the request. I interviewed three VC investors, checked their workflows against 115 platform APIs, and defined six capabilities worth building. Over two months I completed the project solo: product definition, MCP server, company switching, customer-login integration, and all six workflows.

Delivered — paid customer project, completed Solo projectProduct definition to deliveryJune–July 2026
6workflows

Defined, prioritised and implemented

115APIs

Analysed against real investor tasks

3investors

Interviewed and used for pre-testing

2months

Solo, from open request to delivery

On this page
  1. 01Project snapshot
  2. 02What I owned
  3. 03The initial request
  4. 04Discovery: from user work to product scope
  5. 05Constraints that shaped the system
  6. 06Key decisions
  7. 07Service architecture
  8. 08Authentication and company switching
  9. 09One workflow, end to end
  10. 10Implementation
  11. 11Outcome — and what this case does not claim
  12. 12What I learned
01

Project snapshot

CustomerInvestor-facing portfolio platform (anonymised)
UsersInvestors and portfolio users working across one or more companies
DurationJune–July 2026 (2 months)
TeamSolo project
ResearchInterviews and pre-testing with 3 VC investors
My roleProduct-definition and implementation owner: user research, capability design, architecture, server code, customer communication
EnvironmentMCP server · Claude / GPT MCP clients · customer login · customer platform APIs
StatusAll six workflows and the integration completed and delivered
02

What I owned

I owned the complete path from an open-ended customer request to a delivered product.

BuiltUser research: interviews and pre-testing with 3 VC investors.
BuiltAnalysis of 115 customer API endpoints to determine what the platform could actually support.
BuiltDefinition, prioritisation and implementation of all six product capabilities.
BuiltMCP server architecture, authentication integration and the multi-company context model — written by me.
BuiltCustomer-login integration so users authenticate through the customer’s own system when connecting from Claude or GPT.
BuiltAccess-control hardening: PKCE on the authorisation flow and a Fernet-encrypted DiskStore for tokens, against token theft, session leakage and cross-company queries.
BuiltCustomer communication and delivery of the paid project.
03

The initial request

“Build an MCP server for investors.”

Customer request, in full

The request named a technology, but it did not define a product. Three questions were still unanswered:

  1. What work were investors trying to complete with an LLM?
  2. Which of those workflows could the customer’s existing data support?
  3. How could an LLM client access the right company’s data without breaking the customer’s security model?

Building a generic wrapper around the platform API would have produced tools, but not necessarily a product anyone needed.

Initial framingExpose the platform through MCP.
What I needed to discoverWhere an LLM could remove a real handoff, search or reporting burden in an investor’s workflow.
Product definitionBuild a secure workflow layer that lets investors use the platform’s existing data through their real LLM client.
04

Discovery: from user work to product scope

I started with users rather than endpoints. I interviewed 3 VC investors about:

  • The investment tasks they performed repeatedly.
  • How they already used LLMs in their work.
  • Where they copied information between the platform, documents and an LLM.
  • Which questions required searching across portfolio, reporting, fund or notification data.

I then checked each candidate workflow against the data the customer platform actually held. This removed ideas that sounded useful but could not be supported reliably, and turned user needs into a concrete product specification.

Interviews × platform data × security model → six capabilities
Interviews × platform data × security model → six capabilities3 investor interviewsrepeated tasks, real LLM usage115 platform APIswhat the data can actually answerCustomer security modelidentity, multi-company isolationOnly what survivesall three filters1. Reporting collection status2. Review-status briefing3. Fund performance & capital4. Portfolio search5. Risk-grade movement6. Notification triage
A candidate workflow had to survive all three filters. Anything the platform data could not answer reliably was cut before implementation, not discovered during it.
CapabilityWorkflow servedBuild order
Reporting collection statusCheck which company reports have or have not been collected1 · user pre-test
Review-status briefingSummarise the current status of portfolio reviews2 · user pre-test
Fund performance and capitalRetrieve fund performance and capital information3 · user pre-test
Portfolio searchFind companies and portfolio information through natural-language requestsCompleted
Risk-grade movementIdentify and explain changes in company risk gradesCompleted
Notification triageFind and prioritise platform notifications that need attentionCompleted

The order came from observed user value, not API convenience. All six capabilities were subsequently completed.

05

Constraints that shaped the system

  • The system had to work when users connected the MCP server from Claude or GPT, including the CLI workflow identified during research.
  • MCP tool calls did not carry an ordinary browser session.
  • The customer already had an authentication system that had to remain authoritative.
  • One investor could belong to multiple companies.
  • Every tool call had to use the correct company context and preserve company-level data isolation.
  • A capability was only valid if the existing customer platform held the data required to answer it.
  • The server had to integrate with existing APIs rather than duplicate portfolio data in a separate system.
06

Key decisions

01Design for the MCP clients users actually used

Early discussion assumed a desktop-only LLM experience. User research showed the system needed to work through the Claude or GPT clients users actually connected to MCP, including their CLI workflow. I designed the product around that environment instead of preserving the original assumption.

This changed the interaction model, the authentication path, and the way tool results needed to be returned.

trade-offA harder authentication path than a desktop-only assumption would have needed. Accepted: the other option was a product that did not fit the users’ real environment.
02Define tools around workflows, not API endpoints

The customer platform exposed 115 endpoints, but endpoint coverage was not the goal. I grouped data and actions around tasks investors were trying to complete, then exposed those workflows as six capabilities.

This kept the MCP server from becoming a thin, difficult-to-use mirror of the existing API.

trade-offMost endpoints are not exposed. Accepted: six usable workflows beat 115 unusable tools.
03Reuse the customer’s authentication system

I rejected a separate credential store for the MCP server. It would have duplicated identity data, created another security boundary, and made account changes harder to keep consistent.

Instead, connecting the MCP server from Claude or GPT routes the user through the customer’s own login. The MCP server then uses the verified customer identity and memberships without introducing a second account system.

Reusing the customer’s identity system does not remove the risk — it moves it to the token. I diagnosed the access-control gaps in the client’s service flow and implemented PKCE on the authorisation code exchange with a Fernet-encrypted DiskStore for the resulting tokens, so a stolen disk or a leaked session does not become a usable credential.

trade-offMore integration work up front, and a dependency on the customer’s identity service. Accepted: one authoritative identity system, no second place for accounts to drift.
04Make company context a first-class part of every request

An authenticated user was not enough to identify the correct data scope, because one investor could belong to multiple companies. The server also had to know which company the user intended to work with.

I designed two ways to establish that context: infer a company from the user’s request when an explicit company keyword is present, and provide an explicit callable company-switching capability when the user needs to change or confirm context. The selected company context is then passed through to downstream tool handlers and customer APIs.

trade-offEvery handler carries context plumbing. Accepted: without it, a correct-looking answer could come from the wrong company.
05Prioritise with users before completing the full tool set

The six capabilities were not treated as equally urgent. A user pre-test identified reporting collection status as the first workflow to implement, with review briefing and fund performance next.

This gave the build a defensible order and created an earlier path to validating real value.

trade-offThree capabilities waited. Accepted: the order was explainable to both the users and the customer.
07

Service architecture

Claude / GPT → MCP server → customer platform
Claude / GPT → MCP server → customer platformInvestorClaude / GPTMCP client (incl. CLI)Authentication bridgeCompany-context resolverWorkflow tool handlers (×6)Customer API clientExisting authentication serviceCustomer platform APIsCompany-isolated portfolio dataloginverified identity + membershipscompany scopecompany-scoped requestscoped datastructured result
Built by meCoordinated by meExisting / partner-owned
The login integration keeps the customer’s identity system authoritative. When a user connects the MCP server from Claude or GPT, the customer login verifies the user and makes the correct company memberships available. The company-context resolver then determines which company scope applies before a workflow handler reaches the platform API.
08

Authentication and company switching

This was the hardest integration problem in the project. The product could have six useful tools and still fail if authentication or company context was unreliable.

Identity → memberships → company scope → scoped result
Identity → memberships → company scope → scoped resultInvestorMCP clientMCP serverCustomer identityPlatform API1connect2handshake3login4identity5memberships6resolve scope7scoped call8scoped result
Step 1

The user connects the MCP server

From Claude or GPT — including the CLI workflow surfaced during research.

1 / 8
Step through the flow. The critical property is at step 8: a result can only leave the server inside the company scope it was fetched with.
09

One workflow, end to end

A worked example of the reporting-collection-status capability — the workflow users ranked first. Values are substituted; no customer data appears here.

mcp · reporting collection status
mcp · reporting collection status
userWhich portfolio companies still haven’t submitted this quarter’s reports?
ctxcompany context: FUND-A (resolved from session · switchable)
toolreporting_collection_status(period="2026-Q2", status="missing")
out4 of 21 companies missing · period 2026-Q2 COMPANY-A2 last submitted 2026-Q1 14 days overdue COMPANY-B7 last submitted 2026-Q1 9 days overdue COMPANY-C1 never submitted new position COMPANY-D4 last submitted 2025-Q4 47 days overdue
noteStructured result, not prose. The client can rank, filter and follow up without another round trip.

The same request under a different company context returns a different set — and never both. Company isolation is enforced on the path to the API, not by trimming the response.

10

Implementation

My work combined product scoping and hands-on server development:

  1. Interviewed 3 VC investors about their workflows and LLM usage.
  2. Mapped candidate tasks against 115 platform API endpoints and available data.
  3. Defined six capabilities and prioritised them through a user pre-test.
  4. Specified the Claude / GPT MCP interaction model and tool surface.
  5. Designed the server architecture and customer authentication integration.
  6. Implemented company membership lookup and context switching.
  7. Wrote the MCP server and all six workflow handlers.
  8. Completed the customer-login and multi-company context integration.
  9. Tested and delivered the finished system within two months.
11

Outcome — and what this case does not claim

Delivered

  • An open-ended MCP request converted into six implemented investment workflows.
  • 115 platform endpoints analysed against user needs and available data.
  • Build order established through pre-testing with 3 VC investors.
  • The customer’s own login works when connecting the MCP server from Claude or GPT.
  • Authentication, company switching and company-level data isolation completed as core system behaviour.
  • The full two-month project completed solo as a paid customer delivery.

Delivery status

  • Product definition, server implementation, six workflows, customer login and multi-company context are complete.
  • The customer project is finished and delivered.

Not claimed

  • Post-delivery usage metrics were not part of the project and are not claimed here.
  • Customer satisfaction was not measured as part of the engagement.
12

What I learned

When a customer asks for a technology, the product still has to be discovered. The useful specification came from the intersection of three things: the user’s workflow, the data the platform actually held, and the security model the customer already operated.

The feature list was only one part of the system. Authentication and company context had to be treated as product behaviour from the beginning, because they determined whether every workflow result could be trusted.

Diagrams are drawn from the real systems and redrawn here; customer names, data and identifiers are removed.