# MCP Scientists > **A note on sources:** the external documents this report refers to were copied into `canon/` on 2026-07-05. The report's citations record what it read when it was written and are left verbatim; to follow one to the live document, open the copy under `canon/`. :::animation HERO **HERO: The factory that turns an API into an agent-ready product** - **What it shows:** on the left, a raw API rendered as a bare pipe spewing unstructured data; it enters a factory line where stations bolt on the missing layers in sequence (a workflow wrapper, guardrails, an OAuth credential broker, an observability gauge, a go-to-market label), and it emerges on the right as a clean, packaged, named MCP product that an agent reaches up and uses; behind it, a row of identical factory lines stamps out more, each for a different API, all drawing from one shared scaffolding spine. - **Narrative role:** sets the scene; this is the share/card thumbnail. It frames MCP Scientists as the full-chain factory that takes a raw API and produces a workflow-bearing, secured, marketed, operated MCP product, repeatably. - **What it teaches:** the one idea is that the value is not wrapping the API (a commodity), it is the workflow, the guardrails, the go-to-market, and the managed operation bolted on either side. - **Intended impact:** the realization that the integration pain everyone drowns in is a factory problem to be solved once, not a per-API grind. ::: | Field | Value | |---|---| | Project | MCP Scientists | | Looikos cluster | Infrastructure & Agent Platforms (the tooling layer: the tools agents use) | | One-line | The MCP tooling factory and managed-service platform that turns APIs into opinionated, workflow-bearing, marketed MCP products, and the platform layer on which the ecosystem's own internal products (starting with FreelanceBuddy) are built | | Status | Concept moving to in-build (it is the platform layer where FreelanceBuddy, the June step-zero dogfood, gets built) | | Existing code | None as a standalone product yet; the FreelanceBuddy build (the first internal product on this layer) is the live proving ground. Sits beside Symphony AGI (the harness) and Scatter Model (the ECS/Pydantic-IR world-model layer) | | Desk | desk-infra (written by desk-brands-finish) | | Coverage | VERIFIED-heavy on the seed (Andy's transcript is first-party and current) and on MCP market structure and build reality (Perplexity, cited). INFERRED on the three-angle valuation comps (shared agent-infra category) and persona PST depth (tagged inline) | | Date | 2026-06-21 | --- ## Nine-rung frame (this research task) - **Purpose (the rails):** give the ecosystem the depth to build and run MCP Scientists with agents, not headcount. MCP Scientists is the tooling layer, so its depth determines how cheaply every other brand gets the integrations and tools its agents need. - **Mission (rung 1):** convert Andy's recorded MCP Scientists breakdown into a research-grounded ~10k brand deck, so the tooling brand is designed and sold from understanding the integration pain, not from a wrapper-vendor's-eye view. - **Objective (rung 2):** a finished deck at `symphony/stack-recon/projects/mcp-scientists.md`, ~10k words, three-angle valuation modeled, 5+ PST personas to world-experience depth, build section grounded in the MCP build reality, graded CLEAN by desk-qc-final and the lead. - **Initiative (rung 3):** the symphony-recon Track-P run; one of the ~11 unwritten decks. - **Project (rung 4):** the desk-brands-finish lane. - **Task (rung 5):** this one brand deep-dive, run against `_PROJECT_TEMPLATE.md` and PST. - **Action (rung 6):** A1 ingest the transcript (done). A2 skeleton (done). A3 sequential Perplexity: MCP market/alpha, Lexicon of Pain, build reality (done, three queries; valuation comps reused from the same-category Symphony AGI run). A4 PST on five personas. A5 incremental section writing. A6 self-check. A7 hand to the lead. - **Decision (rung 7):** the evolution stage of the MCP-server-building capability (raw API-to-MCP wrapping is heading to commodity; the workflow/guardrail/GTM/managed-operation layer is the genesis-stage own-it lane); which personas carry the deck (the MCP-server developer, the business that wants agent-accessible tools, the solo operator drowning in glue, plus the security-anxious buyer and the API-owner); ADOPT/HARVEST on the build (adopt the MCP SDKs and OpenAPI codegen, own the factory templating and the managed-operation layer). - **Data (rung 8):** N/A (this doc is the artifact). It later seeds the metagraph as BrandDeck:MCPScientists, with edges to Symphony AGI, Scatter Model, Agent Shipyard, Agent Design Pro, and FreelanceBuddy. - **Event (rung 9):** N/A (this doc is the artifact). Deck written, progress posted, grade recorded. ## 1. What it is (the one-paragraph truth) MCP Scientists is the tooling layer of the Looikos ecosystem of brands: the brand that turns APIs into Model Context Protocol products and operates them. Its work is to take an API, build the real business workflow on top of it, package that workflow as an MCP server with the prompts, guardrails, auth, and observability a production tool needs, and then market and distribute the result so it gets used. In Andy's framing it's the place "for tooling or agentic tooling," tools for agents, as distinct from Agent Shipyard, where agents are deployed and monetized, and Agent Design Pro, where agents are designed. It's two businesses braided together. The first is a factory and managed service: a repeatable pipeline that cranks out vertical, workflow-bearing MCP servers across many APIs, hosted and maintained so the customer never has to become an integration engineer. The second is a platform: the layer on which the ecosystem builds its own internal products, the first of which is FreelanceBuddy, the mission-control system Andy uses to manage 100 to 250 Upwork applications a month and take on five to fifteen clients. The two reinforce each other, because the internal products are the proof and the testbed for the factory, and the factory is what makes the internal products cheap to build. For the people it serves, MCP Scientists is the answer to a quiet, widespread misery: everyone has seen the demo where an agent magically pulls data from everywhere, and almost no one can make that happen with their own tools without drowning in OAuth, schema drift, and a maintenance burden that never ends. :::animation 1b **ANIMATION 1b: the demo everyone saw, the reality no one can build** - **What it shows:** a polished stage demo plays where an agent pulls data from everywhere effortlessly, and a spotlit crowd applauds; the camera cuts backstage to the same people at their own desks drowning in OAUTH FLOWS, SCHEMA DRIFT, and a NEVER-ENDING MAINTENANCE QUEUE, the gap between the shown magic and the lived grind laid side by side - **Narrative role:** anchors the closing claim of §1, the misery between the demo and the buildable reality - **What it teaches:** the integration magic is real on stage and unreachable at the desk, and closing that gap is the whole brand - **Intended impact:** the reader recognizes their own backstage grind against the demo they were sold ::: :::animation 1 **ANIMATION 1: The two braided businesses** - **What it shows:** two intertwined strands forming one rope; one strand labeled "factory and managed service" (cranking out vertical MCP servers across many APIs, hosted and maintained), the other "platform for internal products" (FreelanceBuddy and successors built on it); each strand feeds the other, the internal products exercising the factory and the factory making the internal products cheap. - **Narrative role:** opens §1 by making the brand's dual nature (factory plus platform) immediately legible. - **What it teaches:** that the two businesses reinforce each other, the internal products being both deliverables and the testbed. - **Intended impact:** the viewer sees why the brand is one self-reinforcing structure, not two separate offerings. ::: ## 2. Andy's seed, expanded **Andy's words (verbatim from the recording):** "MCP Scientists. And so we're gonna be cranking out all sorts of solutions whether that's taking APIs and building workflows on top of them and putting them in mcps and then advertising and marketing those and getting the word out there. MCP Scientists is both the platform and where we build our own freelance buddy. This is a platform that I'm using to help me manage my upwork applications. And so the idea is that I wanna be able to crank out 100 to 250 applications per month and to be able to take on between five to 15 clients per month and to be able to manage them effectively and so I need to have a solid mission control space and Freelance Buddy is a good place for that." And later, defining it against Agent Shipyard: "pretty much what we discussed as MCP scientists being for tooling or agentic tooling, so MCPS tools for agents. Agent Shipyard is where we actually deploy and manage the ecosystem of available agents." And in the recap of the secret architecture: "our custom MCP scientist developed deployed and managed tooling that's perfectly integrated to everything through our rock solid super efficient ECS architecture obsessed scatter model." **Reading between the lines:** Andy's seed compresses four claims, each load-bearing for the brand. First, "cranking out all sorts of solutions... taking APIs and building workflows on top of them and putting them in mcps and then advertising and marketing those" is the entire factory thesis in one breath, and the order of the verbs matters. Wrapping an API as an MCP is a solved, commoditizing problem (OpenAPI-to-MCP codegen exists and works in 2026). The differentiator is the three things bolted on either side: building the real workflow on top of the raw API before packaging, and marketing and distributing the result after. The market is full of players who do exactly one layer of that chain (registries list servers, codegen tools wrap APIs, hosting platforms run them), and almost no one owns the full chain from API ingestion through workflow design through packaging through go-to-market (VERIFIED, Query 1). Andy's instinct to name advertising and marketing in the same sentence as the technical work is the alpha, the edge hiding in plain sight: a raw "calendar MCP" is nearly worthless, while a packaged workflow for a specific job-to-be-done that someone has actually heard of is the product. :::animation 2 **ANIMATION 2: The full chain versus one layer** - **What it shows:** a horizontal chain with five links (API ingestion, workflow design, packaging, go-to-market, managed operation); the incumbents are shown each grabbing exactly one link and dropping the rest (registries hold "packaging," codegen tools hold "ingestion," hosting platforms hold "operation"), while MCP Scientists holds the entire connected chain end to end. - **Narrative role:** illustrates §2's first claim, the full-chain factory thesis and the single-layer incumbents. - **What it teaches:** that the alpha is owning the whole chain the market splits into single-layer players. - **Intended impact:** the viewer sees the structural gap the full-chain factory fills. ::: Second, "MCP Scientists is both the platform and where we build our own freelance buddy" is the dual-nature claim, and it's the structural advantage. MCP Scientists is a service sold to others and also the substrate on which the ecosystem's own tools get built, which means every internal product is at once a deliverable and a reference integration that exercises and refines the factory. FreelanceBuddy is the first and the most important, because it's step zero on Andy's roadmap, the June build he runs on himself before anyone else: the system he uses to run his Upwork rampage. A factory whose first customer is its own builder, with the tightest possible feedback loop, is the cleanest way to make the factory real before it's sold (VERIFIED, build reality Query 4: the freelancer mission-control app is "an excellent reference product" that exercises email, DB, scraping, and docs integrations and produces a concrete user-visible value proposition). :::animation 16 **ANIMATION 16: the factory whose first customer is its own builder** - **What it shows:** a factory line stamps out its very first product, FREELANCEBUDDY, and instead of shipping it away the builder carries it back to his own desk and runs his Upwork operation on it; every crack he finds in real use loops back as a fix to the line itself, the shortest possible feedback loop drawn as a tight circle - **Narrative role:** anchors §2's second claim, the dual-nature platform proved by dogfooding - **What it teaches:** building the factory's first product for the builder's own use is the cleanest way to make the factory real before it is sold - **Intended impact:** the reader sees why the internal product is both a deliverable and the tightest test ::: Third, "MCPS tools for agents" versus Agent Shipyard's "deploy and manage the ecosystem of available agents" is the deliberate boundary that keeps the family of three brands from collapsing into one. MCP Scientists makes the tools that agents call. Agent Shipyard, which has a separate deck `projects/agent-shipyard.md`, is the infrastructure and monetization layer where agents are deployed, observed, evaluated, and budgeted. Agent Design Pro, also covered in a separate deck `projects/agent-design-pro.md`, is where the agents themselves are designed and where people are taught to design them. The discipline of keeping these separate is itself a selling point, because the integration pain the market complains about loudest is the blurring of these layers into one tangled mess that no one can debug. :::animation 17 **ANIMATION 17: three layers held apart on purpose** - **What it shows:** three clean labeled boxes stand in a row with clear gaps between them, MCP SCIENTISTS (tools for agents), AGENT SHIPYARD (deploy and manage agents), AGENT DESIGN PRO (design the agents); a tangle of wires tries to fuse them into one unreadable knot and a discipline line holds each box in place, keeping the boundaries crisp - **Narrative role:** anchors §2's third claim, the deliberate boundary between the three sibling brands - **What it teaches:** keeping tools, deployment, and design as separate layers is a selling point because the loudest pain is those layers blurring into one undebuggable mess - **Intended impact:** the reader sees the separation as a feature that prevents the tangle they already suffer ::: Fourth, "custom MCP scientist developed deployed and managed tooling that's perfectly integrated to everything through our... scatter model" is the connection to the world-model spine. The reason MCP Scientists can build integrations that are "perfectly integrated to everything" is that the ecosystem runs on one ECS / Pydantic-IR world model (the Scatter Model brand: an entity-component system with Pydantic classes as its intermediate representation, or IR), so the tools MCP Scientists builds speak the same language every database, API, and integration in the ecosystem speaks. One world model answers the schema-drift complaint that dominates the developers' Lexicon of Pain, the words they use for the problem among themselves: when there's one authoritative intermediate representation, the OpenAPI spec, the code, and the MCP tool definitions stop being three sources of truth that drift, because they all derive from one. The Scatter Model has a separate deck, and this one points to it without repeating it. :::animation 3 **ANIMATION 3: One IR ends the schema drift** - **What it shows:** three documents (the OpenAPI spec, the handler code, the MCP tool definitions) drifting apart over time, their shapes diverging and causing red mismatch errors; a single Scatter Model IR anchor then tethers all three to one source, the three snapping back into alignment and the mismatches clearing. - **Narrative role:** illustrates §2's fourth claim, the one-IR answer to the schema-drift complaint. - **What it teaches:** that deriving all three artifacts from one authoritative IR ends the drift that dominates the developer pain. - **Intended impact:** the viewer sees the structural fix for a pain they recognize. ::: ## 3. The three-angle valuation (the core of a self-standing brand) MCP Scientists stands on all three angles, in a particular shape: the service angle is the near-term cash engine, the software angle is the productized library and managed platform, and the finance angle rides the same agent-infrastructure repricing as Symphony AGI, the agent harness the ecosystem's agents run on, while adding a more transactional, usage-metered revenue character that changes how it's underwritten. ### 3a. Finance (credit and capital access) The category read established in the Symphony AGI deck applies here: agent infrastructure is where 2026 capital is moving, M&A is accelerating roughly 90% year over year, and integrable agentic-AI assets price in the $500M-$5B strategic band (VERIFIED, valuation query, referenced from `projects/symphony-agi.md` §3a rather than re-derived). The comparable companies (comps) that matter most for MCP Scientists are the integration-and-tooling ones: the iPaaS and API-integration platforms (the Composio-class connector layers, the Zapier-class automation bridges) that are now extending into MCP, plus the dev-tooling SaaS multiple bands (top-tier AI-infra 12-20x ARR, dev-tools 8-12x, mid-tier 4-8x) (VERIFIED, valuation query and Query 2). The Databricks-MosaicML lesson (a $1.3B acquisition at roughly 65x revenue, priced on owning the means of production rather than this year's ARR) translates: an MCP factory is valued on whether it owns a durable, repeatable means of turning any API into a sellable agent tool, not on the revenue of any single MCP server. :::animation 18 **ANIMATION 18: the integration-tooling comps** - **What it shows:** a shelf of comparable names lines up as valuation markers, the CONNECTOR-LAYER PLATFORMS and AUTOMATION BRIDGES now extending into MCP, each tagged with its multiple band, TOP AI-INFRA 12 TO 20X, DEV-TOOLS 8 TO 12X, MID-TIER 4 TO 8X; a pin for MCP SCIENTISTS slides toward the high band as its factory ownership grows - **Narrative role:** anchors the §3a comps read, the integration-and-tooling multiple bands - **What it teaches:** the relevant comparables are the connector and dev-tooling platforms, and the multiple rises with how much of the means of production the brand owns - **Intended impact:** the reader places the brand against the right comparables rather than generic SaaS ::: For credit and capital access, the nuance for MCP Scientists is that its revenue is a mix: managed-service retainers (predictable, contracted, the good collateral), platform-hosting subscriptions (recurring, also good), and usage-metered per-tool-call billing (the variable line). Lenders underwrite the contracted retainer and subscription revenue like classic SaaS (revenue-based financing at 20-40% of ARR to a 1.2-1.5x cap; ARR-backed venture debt at 0.3-0.8x ARR, 8-15% plus warrants) and haircut the usage-metered line because per-call revenue tied to underlying API costs swings with someone else's pricing (VERIFIED, valuation query). So the brand should be capitalized by leading with the retainer and subscription revenue as the credit-bearing base, treating the usage-metered marketplace revenue as upside that lenders discount, and accumulating the proprietary state (the factory templates, the credential broker, the per-vertical workflow libraries, the operational track record across many hosted servers) as the asset an acquirer pays the strategic premium for. The advertiser-as-bank's-friend dynamic, where heavy, well-documented ad spend makes an operator the kind of borrower lenders court, doesn't apply; this is the B2B-infrastructure capital story, where contracted recurring revenue plus accumulated tooling IP is the collateral. :::animation 19 **ANIMATION 19: three revenue lines, three haircuts** - **What it shows:** three income streams flow toward a lender's scale, MANAGED-SERVICE RETAINERS and PLATFORM SUBSCRIPTIONS pass over almost whole as CREDIT-BEARING BASE, while USAGE-METERED PER-CALL BILLING gets visibly trimmed because its size swings with someone else's API pricing; the lender weighs the two solid lines and discounts the variable one - **Narrative role:** anchors the §3a credit-conversion nuance, how the revenue mix is underwritten - **What it teaches:** contracted retainers and subscriptions carry the credit while usage-metered revenue gets haircut for riding another party's pricing - **Intended impact:** the reader sees how to capitalize the brand, leading with the contracted base ::: The tri-level market-maker read looks at fundamentals, technicals and sentiment. On fundamentals, MCP has crossed into benchmark status with AWS, Google, and Cloudflare doubling down and OpenAI shipping remote-MCP support and an MCP app directory beta in December 2025 (VERIFIED, Query 1), so the protocol the whole business rides is durable and backed by every major platform. On technicals, the supply of credible full-chain MCP studios (workflow plus packaging plus go-to-market, or GTM, plus managed operation) is thin against a demand that's broad but stuck at "I can't make this work," which is a favorable order book. On sentiment, enterprise-ready MCP is the consensus 2026 story. Its named risk is that the major platforms commoditize raw server hosting, which is why the durable value sits in the workflow, the vertical expertise, and the managed operation rather than in the hosting. :::animation 4 **ANIMATION 4: Valued on the factory, not the server** - **What it shows:** a single MCP server's modest revenue meter on one side, dwarfed by the value of the factory itself on the other (the templates, the credential broker, the per-vertical workflow libraries, the operational track record); the Databricks-MosaicML lesson floats as a caption ("priced on owning the means of production, not this year's revenue"), the acquirer's eye fixed on the factory not the single server. - **Narrative role:** grounds §3a's valuation logic, the factory-as-the-asset read. - **What it teaches:** that the brand is valued on owning a durable, repeatable means of turning any API into a sellable tool. - **Intended impact:** the viewer sees where the real value accrues. ::: ### 3b. Software (the interface stack) MCP Scientists' software surface is unusual because the brand's product IS the interface stack: it produces MCP servers, which are themselves the agent-facing interface to other systems. It has two software assets, the factory and the managed platform. The factory is the core software asset: a template-driven integration studio that standardizes server scaffolding, auth, observability, and guardrails, then stamps out narrowly-scoped MCP servers across many APIs (VERIFIED, Query 3). Its components are the scaffolding templates (TypeScript and Python MCP-server boilerplate, parameterized by auth type and data sensitivity and host capability), the OpenAPI-driven codegen (ingests a spec, emits tool definitions and handler stubs, then gets hand-refined with human-written descriptions and guardrails because raw codegen is a starting point, not a finished product), the shared credential broker (unified OAuth 2.1 flows and encrypted per-tenant token storage so every server doesn't reinvent auth), the shared observability-and-policy gateway (request/response logging with redaction, latency and success metrics, access control, and policy enforcement like "the model may not call DELETE endpoints"), and the testing-and-certification harness. This factory is the moat: the marginal cost of the next MCP server falls as the templates and the broker and the gateway mature, which is the compounding a one-off integration shop never gets. :::animation 20 **ANIMATION 20: the shared spine every server bolts onto** - **What it shows:** a single spine runs down the middle carrying the SCAFFOLDING TEMPLATES, the CREDENTIAL BROKER, the OBSERVABILITY-AND-POLICY GATEWAY, and the CERTIFICATION HARNESS; new servers for different APIs snap onto the spine one after another, each reusing the shared parts, and a marginal-cost meter drops lower with every server that clicks on - **Narrative role:** anchors the §3b factory decomposition, the shared components that make the factory compound - **What it teaches:** the auth, observability, and scaffolding are solved once on a shared spine, so each new server costs less than the last - **Intended impact:** the reader sees the compounding a one-off integration shop never gets ::: The managed platform is the second software asset: the MCP PaaS that hosts the servers, keeps up with spec revisions and negotiates capabilities with hosts, provides stable HTTPS endpoints with TLS and rate limiting and quotas, and surfaces the central observability and audit trail enterprises require (VERIFIED, Query 3). The product surfaces, and how each is sold, run like this: the MCP servers themselves are the agentic surface (other agents and hosts consume them as tools, metered per-call or per-action-unit); the platform is the SaaS (subscription for a number of hosted servers, environments, and enterprise features like SSO and audit logs and SOC2 posture); the factory output sold as productized vertical solutions is the software-product line (a "recruiting ops MCP," an "ad ops MCP," sold per-seat or per-tenant); and the internal products built on the platform (FreelanceBuddy first) are both deliverables and reference integrations. The architecture ties this to the ecosystem: the servers run on the standard hybrid stdio-plus-streamable-HTTP transport so the same artifact debugs locally and deploys remotely, and they speak the Scatter Model's IR so they integrate cleanly with the rest of the ecosystem rather than becoming another drifting source of truth. :::animation 5 **ANIMATION 5: The factory and the managed PaaS** - **What it shows:** the factory (scaffolding templates, OpenAPI codegen, credential broker, observability-and-policy gateway, certification harness) producing servers on one side, and the managed PaaS (hosting, spec-revision negotiation, TLS, rate limiting, central observability) running them on the other; the marginal cost of each new server visibly falling as the shared templates and broker and gateway mature. - **Narrative role:** grounds §3b's two software assets, the factory and the managed platform. - **What it teaches:** that the compounding moat is the falling marginal cost of each new server as the shared scaffolding matures. - **Intended impact:** the viewer sees the software flywheel a one-off shop never gets. ::: ### 3c. Service (premium-at-accessible boutique delivery) The service angle is the near-term engine and the most defensible entry, because the dominant market pull in 2026 is operational, "connect my API and data to an agent and make it useful," and the buyers explicitly don't want to hire a platform team to do it (VERIFIED, Query 1 and Query 2). The target operator is the sub-25-employee business or the SaaS company or the operations team that has valuable APIs and data and zero in-house ability to make them agent-accessible safely. The premium-quality-at-accessible-pricing model is delivered through the factory: because MCP Scientists has pre-built the scaffolding, the broker, the gateway, and a growing library of vertical workflow patterns, it can deliver a production-grade, secured, observable, maintained MCP integration at a fraction of what a bespoke build would cost the client, and faster, because most of the work is templated. :::animation 21 **ANIMATION 21: bespoke price versus templated price** - **What it shows:** two quotes for the same secured, observable, maintained MCP integration sit side by side; the BESPOKE BUILD quote towers, most of it labeled reinventing scaffolding, auth, and observability from scratch; the MCP SCIENTISTS quote is a fraction of the height because those layers are already templated, and a clock beside it shows the templated build finishing far sooner - **Narrative role:** anchors the §3c premium-at-accessible-pricing model - **What it teaches:** pre-built scaffolding and vertical workflow libraries let the factory deliver production-grade integration at a fraction of a bespoke build's cost and wait - **Intended impact:** the reader sees where the accessible price comes from without any drop in quality ::: The retainer economics follow the ecosystem standard: $1-2k accessible at entry, $2-12k+ for the real engagements, and the model is "we build and run your MCP integrations" as a fixed monthly retainer plus overage for new integrations (VERIFIED, Query 3 confirms this is a real and sustainable monetization model). The 100-250-customer target puts the service angle's floor around $1M/month, with room to scale above it (VERIFIED, `THE_FLOOR.md`). The pre-modeling advantage is the trust differentiator: the buyer's deepest fear is security exposure ("the idea of thousands of random MCP servers talking to our data gives our security team hives," "I'm not putting my customer data behind a server some GitHub rando maintains in their spare time"), and the managed-service answer to that fear is the thing the open registries can't offer, an operator who owns the auth, the least-privilege scopes, the audit logs, and the uptime, with a name and an SLA instead of a GitHub handle. The long-tail server maintenance and the ongoing operation are partnered to the sister affiliate network and run on the shared-floor model: emerging-market senior technical talent working through the Looikos tools on a franchise/ownership on-ramp, with live transcripts and agent-native systems letting the floor run globally (VERIFIED, `THE_FLOOR.md`). The vertical doesn't matter; any business paying to make its tools agent-accessible and to keep them safe and alive qualifies. :::animation 6 **ANIMATION 6: A name and an SLA, not a GitHub handle** - **What it shows:** a nervous security team facing a wall of anonymous "public MCP server" repos maintained by faceless GitHub handles, each a potential breach; CloudNative-style they turn to MCP Scientists' managed service, which presents an accountable operator owning the auth, the least-privilege scopes, the audit logs, and the uptime, with a real name and an SLA badge, and the security team relaxes. - **Narrative role:** grounds §3c's service trust differentiator, the accountable-operator answer to the security fear. - **What it teaches:** that the managed-service value is the accountability the open registries structurally cannot provide. - **Intended impact:** the viewer feels the security-exposure fear resolve into trust. ::: ## 4. The personas (5+, modeled to world-experience depth) The language here is pulled from the actual Lexicon of Pain mined in the voice-of-customer research. The MCP pain has a distinct texture: it's maintenance dread and security fear more than spectacular failure, the slow drowning rather than the dramatic crash, and the shame is the quiet kind that comes from suspecting your "automated workflow" is really just chaos you happen to understand. :::animation 22 **ANIMATION 22: five people, one slow drowning** - **What it shows:** five figures wade in the same rising water labeled THE INTEGRATION GRIND, each sinking at a different depth marker, MAINTENANCE DREAD, MODERNITY ANXIETY, HOUSE-OF-CARDS FRAGILITY, EXPOSURE FEAR, COMMODITIZATION; a single maintained platform rises under all five like a floor and every head lifts above the water together - **Narrative role:** frames the whole persona section, the shared slow drowning behind five different integration pains - **What it teaches:** the five personas are five depths of one slow drowning in the integration grind, not five separate problems - **Intended impact:** the reader reads the personas as one shared water level with five entry points rather than five unrelated complaints ::: ### Persona 1: The developer maintaining a graveyard of MCP servers I'm the engineer who got handed "the MCP stuff." I just wanted to hit a REST endpoint, and now I'm "maintaining a micro-infrastructure just so Claude can call it." Instead of building features, I'm "building wrappers for wrappers," a separate server for every SaaS our PM wants the bot to talk to. The auth is the part that breaks me: I've spent more time fighting OAuth flows for MCP than shipping product, everything works until the refresh token expires and the server dies silently, and there are now three places auth can fail, the SaaS, my server, and the client, and "guess who gets blamed? Me." The spec churn means I "can't tell if my stuff is broken or if the spec changed again," and I have three sources of truth for my API (OpenAPI, my code, the MCP tool definitions) that "always drift." On my machine it's perfect; through the agent it's timeouts and weird errors I can't reproduce, and there's no way to debug end to end, so I'm blind. It hits me in a way I don't say out loud in standups. I tell my team this is "strategic infra," but part of me thinks I'm "just building tech debt with a shiny acronym." I feel stupid when the demo breaks over a tiny schema mistake, because it makes me "look like I don't know what I'm doing," and everyone else on Twitter seems to have agents "just working" with their APIs while I'm "neck-deep in YAML and OAuth errors." I got into this because the integration requests kept coming and each one looked like a quick wrap. To get out, I need the scaffolding, the auth, the observability, and the guardrails to be solved once, centrally, so I stop rebuilding them per server, and I need the schema to derive from one source of truth so the drift stops. Most developers in my seat fail because they keep treating each server as a one-off and the maintenance compounds until the weekends disappear. Staying stuck costs me my time, my standing, and an integration product I "accidentally signed up to maintain for the rest of my life." The price of getting out is admitting the factory should be a platform, not my personal heroics. :::animation 23 **ANIMATION 23: the silent token death** - **What it shows:** a server hums along green until a small timer labeled REFRESH TOKEN quietly runs out, and the server dies without a sound or an alert; three blame-arrows swing toward the developer from THE SAAS, MY SERVER, and THE CLIENT, all landing on him while he still does not know anything broke - **Narrative role:** carries persona 1's voice, the auth that expires silently and the three places it can fail - **What it teaches:** the specific dread is failure with no signal across three systems, where the developer is blamed for a break he cannot even see happen - **Intended impact:** the reader feels the particular helplessness of silent, unattributable auth failure ::: MCP Scientists gives me the factory I keep failing to build alone: templated scaffolding, a shared credential broker so OAuth is solved once, a shared observability gateway so I can finally see end to end, and a single IR so my three drifting schemas become one. The protocol stays, and my weekends come back. :::animation 7 **ANIMATION 7: The graveyard becomes a factory** - **What it shows:** a developer surrounded by a graveyard of half-broken MCP servers, each with its own reimplemented OAuth and its own drifting schema, frantically patching; the scene reorganizes into a clean factory where the auth is solved once in a shared broker, the observability runs through one gateway, and the schemas derive from one IR, the developer now drawing from shared parts instead of rebuilding each server. - **Narrative role:** dramatizes persona 1's transformation from per-server heroics to a shared factory. - **What it teaches:** that solving the scaffolding once centrally ends the per-server maintenance grind. - **Intended impact:** the viewer feels the weekends come back. ::: ### Persona 2: The business operator who wants agents on their tools and can't get there I'm the operations leader at a growing company. All I want is "for Claude to talk to our CRM and analytics," and apparently "that's a platform initiative now." Every demo I see shows the AI magically pulling data from everywhere; my reality is "download CSV, upload to chat." We pay for Shopify, HubSpot, Stripe, internal APIs, and "the AI just sits there blind." Vendors keep telling me "we have an MCP server!" like that means anything to my team, and I still can't get it set up. My engineers are busy shipping features and I can't pull them off "to learn another integration protocol," and we don't have "a DevOps for AI person." It affects my standing as the person responsible for whether we look modern or like "the dinosaur that never integrated AI." I feel dumb in vendor meetings nodding along to MCP and RAG and agents while thinking "can someone just make this work." And underneath the modernity anxiety is a sharper fear: I'm responsible for customer data, "the idea of thousands of random MCP servers talking to our data gives our security team hives," and I'd "rather look slow than be the person who greenlit something that leaked it." I got here because the demand for AI came faster than my ability to build it safely. To get out, I need someone who owns the whole thing, builds the integration with least-privilege scopes and audit logs, hosts it with an SLA, and maintains it, so it isn't "a public API you forgot to lock down" maintained by a GitHub handle. Most operators in my seat fail because they either freeze on the security fear or rush into an exposure they don't understand. The cost to stay stuck is falling behind and copy-pasting between dashboards forever. The cost to get out is paying an operator I can actually hold accountable instead of trusting a weekend hack. MCP Scientists is that accountable operator: the workflow built on top of my tools, secured, scoped, hosted, observed and maintained, with a name and an SLA, so I can say yes to agents on my data without lying to my security team or myself. :::animation 8 **ANIMATION 8: From download-CSV to agents-on-my-tools** - **What it shows:** a business operator stuck in "download CSV, upload to chat" while their paid tools (Shopify, HubSpot, Stripe) sit blind beside an idle agent; MCP Scientists builds the secured, scoped, hosted workflow on top of those tools and the agent lights up, pulling live data the way the demos always promised, without the operator hiring a platform team. - **Narrative role:** dramatizes persona 2's transformation from blind tools to agent-accessible ones. - **What it teaches:** that an accountable managed operator makes the magic-demo real on the operator's own tools. - **Intended impact:** the viewer feels the gap between the demo and their reality close. ::: ### Persona 3: The solo operator drowning in their own glue I'm a freelancer running a one-person operation, and "my life is held together by Zapier zaps, cursed Google Sheets formulas, and a 3-page prompt." I'm "basically the IT department for a company of one." Every automation I add "makes the whole thing more fragile," and I have "Notion talking to Airtable talking to Google Drive talking to an LLM," spaghetti only I understand. I'm trying to manage a high volume of work, and "I spend more time maintaining my system than actually" doing the work that makes money. My pipeline is "12 browser tabs, two spreadsheets, and a queue of AI drafts I don't fully trust," and "if one automation fails, I don't notice until a week later when I realize I missed a response." I built myself a mini-system and now I'm "the unpaid ops engineer for it." The toll is a slow erosion of my confidence. I tell people I have "an automated workflow," but "it's really just chaos I happen to understand." I'm "embarrassed by how much time I spend fiddling with tools instead of doing the actual work," and there is a quiet fear that "if I get sick or step away, everything collapses because nothing is simple or robust." Worst of all, I worry that "the way I've glued everything together is a sign I don't really know what I'm doing, just hacking to survive." I got here because each tool solved one problem and the seams between them became my problem. To get out, I need one mission-control system that actually owns my pipeline, connected to my email and calendar and tracking and docs through tools that work, where the agent can say "find all applications stuck in draft more than three days and suggest follow-ups" and it just happens. Most solo operators fail because they keep adding another tool instead of consolidating onto a system. Staying stuck costs me the house of cards and the dread of touching it. The price of getting out is trusting a real platform instead of my own glue. Through FreelanceBuddy most directly, MCP Scientists gives me the mission control I keep trying and failing to build out of duct tape: one place that runs my pipeline, built on tools that are maintained and reliable, so I stop being my own integration engineer and get back to the work that pays. :::animation 9 **ANIMATION 9: Out of the glue, into a system** - **What it shows:** a solo operator tangled in Zapier zaps, cursed spreadsheets, and a Franken-framework only they understand, drowning; the tangle resolves into one maintained mission-control system (FreelanceBuddy on the MCP Scientists platform) running their pipeline on reliable tools, the operator stepping back from integration-engineering into the work that actually pays. - **Narrative role:** dramatizes persona 3's transformation from self-built glue to a maintained system. - **What it teaches:** that the platform replaces the solo operator's fragile glue with maintained, reliable tooling. - **Intended impact:** the viewer feels the drowning-in-glue stop. ::: ### Persona 4: The security-anxious engineering lead at a mid-sized company I'm the engineering lead whose security team got shown MCP and "basically said, cool, you want to create a new attack surface we don't understand." There is "a spreadsheet floating around with hundreds of MCP servers" and I "have no idea which ones are safe, supported, or abandoned." Most of them "are side projects," and I don't "want my operations to depend on someone's weekend hack." The phrase "public MCP server" reads to me like "public API you forgot to lock down," and I keep imagining the breach headline with our name in it. What I actually need is "the equivalent of an app store with real reviews, SLAs, and security audits," and right now "it's just GitHub repos and vibes." It weighs on me as the person whose job is to enable the business without becoming the incident. The fear is concrete and specific: a misconfigured integration with too-broad scopes, customer data flowing through a server no one is really watching, and my name on the postmortem. I got here because leadership wants AI integrations and the safe way to do them isn't obvious in a market of thousands of unvetted servers. To get out, I need integrations built and operated by someone who treats least-privilege scopes, audit logging, token handling, and uptime as first-class, who I can actually call when something breaks, and who gives me the observability my security team will demand. Most leads in my seat fail by either blocking everything and becoming the obstacle, or rubber-stamping a server and becoming the breach. Staying stuck costs me the obstruction or the incident. The cost to get out is paying for managed, audited, accountable operation instead of free-and-exposed. MCP Scientists gives me the accountable, observable, least-privilege managed operation the open registries structurally can't offer: an operator who owns the security posture and can prove it, not a repo and a prayer. :::animation 10 **ANIMATION 10: Least-privilege, audited, accountable** - **What it shows:** a security lead facing the "spreadsheet of hundreds of unvetted MCP servers" and the breach-headline fear; MCP Scientists' managed operation replaces it with a single integration showing explicit least-privilege scopes, a live audit log, proper token handling, and an SLA, the security lead's red anxiety meter cooling to green as they see they can finally hold someone accountable. - **Narrative role:** dramatizes persona 4's transformation from exposure-fear to accountable, auditable operation. - **What it teaches:** that managed least-privilege operation with audit logs is the answer the open registries cannot give. - **Intended impact:** the viewer feels the breach-headline fear resolve. ::: ### Persona 5: The API-owning SaaS company that wants to ride the MCP wave but can't staff it I'm a product leader at a SaaS company with a genuinely useful API, and I know our customers increasingly want to use us through their agents. We "have an MCP server" in the sense that an engineer wrapped our API once, but it stops at "access API X," with no domain logic, no multi-step workflows, no guardrails, and no one marketing it as a solution. Our generic wrapped endpoint is "much less valuable than a packaged workflow for a specific job," and we know it, but my engineers are busy and I can't pull a team off the roadmap to build and run an opinionated MCP product, keep it current with the spec, and position it for the jobs our customers actually do. It lands on me as the person accountable for whether we're present or absent in the agent ecosystem our customers are moving into. The fear is being commoditized into a raw endpoint that some orchestration layer calls and gets no credit for, while a competitor ships the packaged, marketed, job-to-be-done version and owns the relationship. I got here because wrapping the API looked like the finish line and it was the starting line. To get out, I need a partner who turns our API into an opinionated MCP product with the workflow and guardrails our customers need, distributes and markets it as a solution rather than a protocol artifact, and operates it so it stays alive, all without my team owning the burden. Most product leaders in my seat fail because they treat the wrapper as done and let the product layer go unbuilt. Staying stuck means being a blind endpoint in someone else's stack. The cost to get out is partnering on the product and GTM layer instead of pretending the wrapper was enough. MCP Scientists is that partner: it builds the product on top of my API, positions it as a solution and keeps it current, so my API shows up in the agent world as a product, not a side effect. :::animation 11 **ANIMATION 11: A blind endpoint becomes a marketed product** - **What it shows:** a SaaS company's API existing as a generic wrapped endpoint that some orchestration layer calls and gets no credit for; MCP Scientists wraps it in the real workflow and guardrails, markets it as a job-to-be-done solution, and keeps it current, so the API now appears in the agent world as a named, positioned, maintained product owning the customer relationship instead of a blind side-effect. - **Narrative role:** dramatizes persona 5's transformation from commoditized endpoint to marketed product. - **What it teaches:** that the partner turns a raw API into an owned, positioned, operated product in the agent ecosystem. - **Intended impact:** the viewer sees the API-owner escape commoditization. ::: ## 5. The world model (run the PST framework) **Echolocate the world.** The PST framework (Problem, Story, Transformation, Andy's method for reading a buyer) starts by modeling the buyer's world. Here the substrate is the 2026 MCP ecosystem, which has the shape of an early-mature infrastructure layer: a stable core protocol backed by every major platform, thousands of public servers, multiple registries, and a fast-growing managed-hosting market, sitting on top of a demand that's broad and operational ("connect my tools to an agent and make it useful") and largely unmet because the workflows are still being figured out in real time (VERIFIED, Query 1). The institutional read is that this is a land-grab moment in a category the capital markets have already validated, where the supply is fragmented into single-layer players and the full-chain operator is rare. In the metagraph, the ecosystem's shared knowledge graph, MCP Scientists is the tooling node that every agent in the ecosystem reaches through to touch the outside world, so its customer is both the external buyer and the ecosystem itself, and the first internal customer (FreelanceBuddy) is the tightest feedback loop in the portfolio. Echolocating the buyer means seeing that the public conversation is about protocol and adoption statistics while the private reality is people drowning in OAuth, schema drift, and security fear. :::animation 24 **ANIMATION 24: the adoption chart and the drowning desk** - **What it shows:** a bright conference slide shows an MCP ADOPTION CURVE climbing with every major platform's logo pinned to it, and the camera drops beneath the stage to the private reality, a desk buried in OAUTH ERRORS, DRIFTING SCHEMAS, and a SECURITY-FEAR sticky note, the celebratory statistics and the lived grind stacked in one frame - **Narrative role:** anchors §5's Echolocate station, the gap between the adoption story and the buyer's private reality - **What it teaches:** the public conversation counts adoption while the private reality is people drowning in the integration work the statistics hide - **Intended impact:** the reader recognizes the gap between the category's confidence and their own experience ::: **Locate the Problem.** The station where these buyers are stuck in the cycle of suffering is a grinding loop of maintenance dread and exposure fear. It presents differently across the personas, but the versions rhyme. The pain is concrete: the servers break, the auth expires silently, the spec churns, the schemas drift, the integrations can't be debugged, and the maintenance never ends; or, for the buyer who can't build, the AI sits blind on valuable data while the demos promise magic. The fear portfolio underneath is specific: the developer's fear that all this work is "throwaway tech debt with a shiny acronym," the operator's fear of the data-leak headline with their name on it, the solo operator's fear that the house of cards collapses the moment they step away, the security lead's fear of being the incident, the product leader's fear of being commoditized into a blind endpoint. The shame is the quiet kind: telling people you have "an automated workflow" when it's "really just chaos I happen to understand," nodding along to MCP and RAG in meetings while privately begging for someone to "just make this work," suspecting that your glue is "a sign I don't really know what I'm doing, just hacking to survive." The red line, where accountability lives, is the moment a person admits the integration burden is a platform problem to be solved once and operated, not a personal failing to out-hustle. Most of the audience lives below that line, in the loop, which is why the content speaks to the dread and the fear rather than to the aspirational demo. :::animation 25 **ANIMATION 25: the line where the burden stops being personal** - **What it shows:** a horizontal line splits the frame; below it people grind alone, each holding a sign reading I SHOULD BE ABLE TO KEEP THIS ALIVE MYSELF; one figure steps up across the line and their sign reweights to read THIS IS A PLATFORM PROBLEM TO SOLVE ONCE AND OPERATE, the reframe drawn as a border-crossing - **Narrative role:** anchors §5's Locate station, the red line where the maintenance burden reframes from personal failing to platform problem - **What it teaches:** most of the audience lives below the line reading a structural burden as a personal failure to out-hustle - **Intended impact:** the reader feels the shift from self-blame to naming the burden as something to be operated, not endured ::: **Reconstruct the Story.** The belief structure that built the suffering starts from a reasonable premise: "a competent person wires their own tools together." For the developer, the demos and the easy first wrap deposited the belief that integration is a quick task, and each silent OAuth failure and schema drift then registered as personal incompetence rather than structural immaturity. For the operator and the solo builder, the belief that "real operators are self-sufficient" turned the inability to build into private shame instead of a rational division of labor. The origin of the mess is the reach for the easy seam (the quick wrap, the next Zapier zap, another spreadsheet) under the pressure of demand that outran capability, each a sensible local decision that became load-bearing. The identity layer underneath is uncomfortable: people whose self-worth rests on being technically capable and self-reliant are quietly failing at the most-hyped integration story in their field and performing competence about it, and the performance is exhausting and the glue is fragile and they know it. The story they tell themselves is "I should be able to keep this alive myself," and that story is the trap, because working alone with more glue is what doesn't scale. :::animation 26 **ANIMATION 26: the easy seam that became load-bearing** - **What it shows:** a builder reaches for one more easy seam, THE QUICK WRAP, THE NEXT ZAPIER ZAP, ANOTHER SPREADSHEET, each a small sensible plank added under demand pressure; the planks stack into a tall wobbling structure the whole operation now stands on, and a label reads EACH DECISION WAS REASONABLE, TOGETHER THEY BECAME LOAD-BEARING - **Narrative role:** anchors §5's Reconstruct station, the belief structure of reaching for the easy seam - **What it teaches:** each quick integration was a sensible local decision, and together they became a fragile load-bearing pile that self-reliance cannot keep alive - **Intended impact:** the reader sees the trap as an accumulation of reasonable choices rather than one mistake ::: **Design the Transformation.** The bridge has courage as its hinge, and the courageous act is small: admitting that the integration layer should be a maintained platform and an accountable operator, not a personal pile of duct tape. From courage flows truth: the maintenance burden is structural, the security fear is legitimate, the spec churn is real, and needing someone to own this isn't weakness. From truth flows responsibility: choosing a factory-and-managed-service model with one source of truth and real security posture instead of the next quick wrap. From responsibility flows healing: the servers stay alive because someone operates them, the auth is solved once centrally, the schema stops drifting because it derives from one IR, the security team relaxes because the scopes are least-privilege and the audit logs exist, and the solo operator gets back the hours that the glue was eating. From healing flows forgiveness of the earlier self who reached for the easy seam, who wasn't stupid, who made reasonable decisions in a market that hid the maintenance and the exposure behind a beautiful demo. The transformation is crossable because the first step is "let us build and run this one integration properly," not "rebuild your stack," and the proof is FreelanceBuddy, a real system run on the real factory. For the integration sufferer, the brand proves it understands the private dread and exposure fear better than the customer says it out loud, and that recognition earns the bridge. :::animation 12 **ANIMATION 12: The bridge from duct tape to a maintained platform** - **What it shows:** the PST bridge spanning from a "personal pile of duct tape" cliff to a "maintained platform, accountable operator" cliff; the integration sufferer crosses planks labeled courage, truth (the burden is structural), responsibility (one source of truth, real security), healing (servers stay alive, schema stops drifting, hours come back), forgiveness (the easy seam was reasonable), arriving where FreelanceBuddy stands as proof. - **Narrative role:** the §5 transformation made visual. - **What it teaches:** that the path out reframes the maintenance burden as structural and adopts a maintained platform. - **Intended impact:** the viewer feels the crossing is low-risk, one integration at a time. ::: ## 6. Competitive and market read (the alpha / third door) The MCP market splits cleanly into single-layer players, and the gap between them is the opening. Directories and marketplaces (smithery.ai, mcp.so, PulseMCP, Glama, the official MCP registry) handle discovery but don't own the workflow logic or the domain expertise. Connector substrates (Composio, Zapier MCP) expose many app integrations but don't position themselves as per-vertical product studios with go-to-market. API-to-MCP wrapper tools generate servers from OpenAPI specs but stop at "wrap the API," with no domain logic, multi-step workflows, or commercial distribution. Managed-hosting players run servers reliably but don't own the vertical product narrative or the audience acquisition (VERIFIED, Query 1 and Query 2). Each covers one layer of the chain from API ingestion through workflow design through packaging through distribution through operation, and almost no one covers the whole chain. :::animation 27 **ANIMATION 27: everyone claims one link** - **What it shows:** a five-link chain lies across the frame, INGESTION, WORKFLOW, PACKAGING, DISTRIBUTION, OPERATION; the incumbents each grab exactly one link and let the rest fall, DIRECTORIES on discovery, CONNECTORS on substrate, WRAPPER TOOLS on codegen, HOSTING on operation, and the links between their hands hang broken and unheld - **Narrative role:** anchors §6's field read, the single-layer split in the MCP market - **What it teaches:** the whole field covers one link each and almost no one holds the connected chain from ingestion to operation - **Intended impact:** the reader sees the fragmentation that leaves the full chain unclaimed ::: The alpha, in Andy's precise definition, is to become the company that turns raw APIs into opinionated MCP products with business logic, then distributes, markets, and operates them as a managed offering, plus uses the same platform to build its own internal products so the product engine and the service engine reinforce each other. The reasons the incumbents won't assemble this combination are structural: the directories' business is discovery, not building; the wrapper tools' business is codegen volume, not per-vertical depth; the hosting platforms' business is infrastructure, not narrative and audience; and owning the whole chain means owning workflow depth, domain-specific packaging, go-to-market, and operational trust all at once, which most players deliberately avoid to stay focused on one layer (VERIFIED, Query 1). The differentiation lives where the incumbents abstain: workflow depth ("complete a business process using X, Y, and Z," not just "access X"), domain-specific packaging (a generic CRM MCP versus a packaged recruiting or ad-ops workflow with ROI language and constraints), go-to-market (positioning each MCP as a standalone solution rather than a technical endpoint), operational trust (auth, uptime, auditability, safe permissions, the thing the security-anxious buyer is desperate for), and multi-product reuse (once the factory works for one vertical it repeats across many APIs and industries). The Wardley read places each capability on a Wardley map's evolution axis, which runs from genesis (new and custom) to commodity. Raw API-to-MCP wrapping is already commodity in 2026: codegen does it, and within a short horizon it's free and table stakes, which is why MCP Scientists rents the codegen and the SDKs rather than competing on the wrap. The factory's shared scaffolding, credential broker, and observability gateway sit at custom-built heading toward product, and are worth owning because they are the compounding that drops the marginal cost of each server. The vertical workflow libraries plus the go-to-market plus the managed-operation trust sit in genesis: the market is fragmented and bespoke, with no widely-cited full-chain MCP studio at volume (the closest analogues are iPaaS platforms extending into MCP and in-house enterprise platform teams), which is the lane to own because it's genesis-stage, it accumulates per-vertical expertise and operational reputation, and it has the relationship and trust moat that a wrapper can't replicate (VERIFIED, Query 1 and Query 3). So the strategy reads: rent the wrapping and the SDKs, own the factory and the managed operation, and signature the brand on being the full-chain studio that the fragmented market is missing. :::animation 28 **ANIMATION 28: the three evolutionary bands of the factory** - **What it shows:** a Wardley board with three bands; in COMMODITY, RAW API-TO-MCP WRAPPING sits already free and table-stakes; in CUSTOM-HEADING-TO-PRODUCT, the SHARED SCAFFOLDING, CREDENTIAL BROKER, and OBSERVABILITY GATEWAY sit worth owning; in GENESIS, the VERTICAL WORKFLOW LIBRARIES plus GO-TO-MARKET plus MANAGED-OPERATION TRUST sit alone with an OWN THIS flag planted - **Narrative role:** anchors §6's Wardley read, what to rent and what to own - **What it teaches:** the wrapping is commodity to rent while the vertical libraries and managed operation are the genesis lane to own - **Intended impact:** the reader can place each capability on the evolution axis and see the rent-versus-own call ::: The market-size and demand signal are strong on the category-formation evidence (MCP at benchmark status, every major platform backing it, thousands of public servers, multiple registries, OpenAI's December 2025 app directory), but the precise TAM for the full-chain-studio niche isn't cleanly sourced and is tagged OPEN; the demand signal that matters most is the rawness and the volume of the integration Lexicon of Pain plus the explicit operational pull toward "make my tools useful to an agent" (VERIFIED, Query 1; TAM OPEN). A market where the protocol is universally backed and the practitioners are universally drowning is a market with enormous latent demand for the operator who makes it work. :::animation 13 **ANIMATION 13: The single-layer field and the full-chain door** - **What it shows:** a market map where the incumbents cluster on single layers (directories doing discovery, connectors doing substrate, wrapper tools doing codegen, hosting platforms doing operation), each refusing the others' commitments; the full-chain studio door (workflow plus packaging plus go-to-market plus managed operation) stands open and unoccupied, MCP at universal benchmark status backing the whole space. - **Narrative role:** grounds §6's third-door argument, the full-chain gap in the single-layer field. - **What it teaches:** that the alpha is the full-chain studio the fragmented field leaves unbuilt. - **Intended impact:** the viewer locates the brand's open position. ::: ## 7. The build (what this brand needs, where Track R feeds Track P) MCP Scientists' build is the most concretely specified of the early-stage brands because the MCP build reality is well-documented and FreelanceBuddy is the live reference integration. Track R, the research into open-source repositories, feeds this project plan (Track P) through the integration-tooling cluster: the harvested open-source code for MCP SDKs, OpenAPI codegen, auth brokering, and observability feeds the factory directly. The factory is built from adopted, not reinvented, primitives: the official TypeScript and Python MCP SDKs (the de facto standard, wrapping JSON-RPC, lifecycle, and schema validation), the OpenAPI-to-MCP codegen tools (which emit tool definitions and handler stubs as a starting point), the OAuth 2.1 / OIDC auth stack formalized by the June 2025 MCP auth spec, and the hybrid stdio-plus-streamable-HTTP transport pattern so one artifact debugs locally and deploys remotely (VERIFIED, Query 3). The ecosystem's own additions on top are the shared credential broker, the shared observability-and-policy gateway, the guardrail layer (read-only constraints, endpoint whitelists, idempotency on destructive actions), the testing-and-certification harness, and the templating that parameterizes all of it by auth type and data sensitivity and host capability. Building the SDKs or the codegen from scratch would be the anti-pattern; the leverage is in the templating, the broker, the gateway, and the vertical workflow libraries that the codegen doesn't provide. :::animation 29 **ANIMATION 29: rent the primitives, build the additions** - **What it shows:** a factory floor where the base machines arrive pre-made and stamped RENTED, the MCP SDKS, the OPENAPI CODEGEN, the OAUTH 2.1 STACK, the HYBRID TRANSPORT; the builder does not rebuild them and instead bolts on his own additions stamped OWN, the CREDENTIAL BROKER, the POLICY GATEWAY, the GUARDRAIL LAYER, the VERTICAL WORKFLOW LIBRARIES - **Narrative role:** anchors §7's build, the adopted-primitives-plus-owned-additions split - **What it teaches:** the factory rents the standard SDKs and codegen and puts its build effort into the templating and vertical libraries the codegen does not provide - **Intended impact:** the reader sees exactly where reuse ends and where the brand's own building begins ::: The data models are the ECS / Pydantic-IR genome owned by the Scatter Model brand, which has a separate deck `projects/scatter-model.md`, and that shared model is what lets MCP Scientists answer the three-sources-of-truth drift complaint: the OpenAPI spec, the handler code, and the MCP tool definitions all derive from one IR rather than diverging. The ecosystem's medallion asset tiers apply to the server library: a freshly codegen'd server enters at bronze, a workflow-bearing guardrailed tested server rises through silver and gold, and the proven, reused-across-many-clients vertical workflows are the diamond-tier assets that make the factory most valuable. The agent roster the domain needs is the harness's publishing-house team (backend and devops leads for the server build and the hosting, plus the load-bearing QC-and-verification agent for the security and reliability certification), running on Symphony AGI (the harness this brand's agents run on, covered in a separate deck `projects/symphony-agi.md`). The open-source harvests that serve MCP Scientists most sit in the tooling and orchestration clusters: the dev-tooling-and-ops harvests feed the factory scaffolding and observability `_synthesis-tooling.md`, and the orchestration harvests feed the workflow-on-top-of-API layer. The exact repo-by-repo harvest list should be reconciled against the summaries of that research's clusters as they land, rather than enumerated speculatively here (INFERRED on the exact repos; the cluster-level fit is VERIFIED against the operation's Track-R structure). FreelanceBuddy is the concrete first build and the deck's most actionable build statement: a job-application mission-control system for 100-250 applications a month, with ingestion (job posts from Upwork, email via IMAP/Gmail, browser/scraper for boards without APIs, filesystem/Drive for portfolio docs), a pipeline (new lead, qualified, drafting, submitted, responded/interview, won/lost) stored in a simple Postgres backend, an agent layer (parse and score opportunities, draft tailored proposals from templates, generate follow-ups), and a Kanban mission-control UI (VERIFIED, Query 4). The architecture call is the sensible one the build research confirms: keep the core CRUD and UI simple (Postgres plus an app server plus a clean API), and lean on MCP and the agent layer exactly where it adds leverage (conversational control, cross-tool automation, and the path to turn FreelanceBuddy into a product for other freelancers whose own agent hosts plug in via MCP). FreelanceBuddy has a separate deck `projects/freelancebuddy.md`; here it's the proof that the factory builds real things. :::animation 14 **ANIMATION 14: FreelanceBuddy as the reference integration** - **What it shows:** the factory producing FreelanceBuddy (ingestion from Upwork and email and scrapers, a pipeline on a simple backend, an agent layer drafting proposals, a Kanban UI), with a feedback arrow looping the lessons learned back into the factory's templates and broker and gateway, the first internal product simultaneously a deliverable and a testbed. - **Narrative role:** grounds §7's build, FreelanceBuddy as the concrete first build that proves and refines the factory. - **What it teaches:** that the internal product is the proof the factory builds real things and the loop that sharpens it. - **Intended impact:** the viewer sees the factory validated by its own first product. ::: ## 8. Priority read (feeds the value rubric) MCP Scientists sits early in the dependency graph and high on leverage. It depends on Symphony AGI (the harness its own agents run on) and Scatter Model (the IR its tools speak), and it enables a great deal downstream: every brand whose agents need to touch an external API or system reaches through MCP Scientists' tooling, and the ecosystem's internal products are built on its platform. Its readiness is real in the near term because FreelanceBuddy is the June step-zero build Andy runs on himself, which means the brand is the platform layer of an imminent, scheduled, tightly-fed-back build that Andy uses, not a concept waiting for a build. The first-pass instinct is a strong Now, with a specific sequencing logic. The service angle (build-and-run MCP integrations for clients) is the near-term cash engine and the most defensible entry, because the operational demand is real and the buyers explicitly won't staff it themselves. The platform-and-product surfaces (the managed PaaS, the productized vertical solutions) follow as the factory matures and accumulates vertical workflow libraries. The internal-product line (FreelanceBuddy first) is both the proof and the testbed and should be built first because it exercises the whole factory with the tightest feedback loop. So the priority read is Now, in three steps: build FreelanceBuddy on the factory first (proving the factory), then sell the managed service (the cash engine), then scale the platform and the productized solutions. The dependency on Symphony AGI means MCP Scientists can't fully precede the harness, but building FreelanceBuddy for Andy's use is itself part of the harness's M5 milestone (the first real FreelanceBuddy feature shipped through the harness's full build-and-review loop), so the two advance together. A separate strategist reconciles every brand against the shared value rubric `VALUE_RUBRIC.md`, and this deck's grounded input is that MCP Scientists is a high-leverage Now sitting just behind Symphony AGI in the substrate sequence. The seven-sins gate, a check of the read against seven named ways an analysis fools itself, applies to the claim that the factory is repeatable at volume. The answer today is that the primitives are proven and the FreelanceBuddy build will prove the templating, but the at-volume repeatability across many verticals is what the build must demonstrate before the service angle scales. :::animation 15 **ANIMATION 15: Now, sequenced from the dogfood out** - **What it shows:** a sequenced path: build FreelanceBuddy on the factory first (proving the factory and the templating), then sell the managed service (the cash engine), then scale the platform and the productized vertical solutions; a "Now" badge sits beside MCP Scientists positioned just behind Symphony AGI in the substrate sequence, the FreelanceBuddy dogfood shown advancing in lockstep with the harness's M5 milestone. - **Narrative role:** closes the §8 priority argument, the high-leverage-Now read sequenced from the dogfood. - **What it teaches:** that the brand is a Now whose sequence starts with the internal dogfood and proves the factory before scaling. - **Intended impact:** the viewer understands the disciplined Now sequencing. ::: ## 9. The brand's own nine-rung position :::animation 30 **ANIMATION 30: the brand on all nine rungs** - **What it shows:** a ladder of nine labeled rungs stands from PURPOSE at the rails down through MISSION to EVENT, and a single tool call climbs it, each rung stamping the call with one more layer of grounding until at the bottom it is a logged, attributed, auditable event - **Narrative role:** opens §9, the brand's own nine-rung position, as one coherent frame - **What it teaches:** the brand that sells auditable tooling is itself specified against all nine rungs, top to bottom - **Intended impact:** the reader sees the brand practicing the exact discipline it sells ::: - **Purpose (the rails):** make the outside world (every API, every SaaS, every data source) safely and reliably reachable by agents, so the ecosystem and its customers get leverage from their tools instead of drowning in the glue between them. - **Mission (rung 1):** be the MCP tooling factory and managed-service platform that turns APIs into opinionated, workflow-bearing, marketed, operated MCP products, and the platform on which the ecosystem's own internal products are built. - **Objective (rung 2):** a repeatable factory plus managed-hosting platform that ships and operates vertical MCP products across many APIs, sold as service (build-and-run retainers), software (managed PaaS and productized solutions), and internal-product leverage (FreelanceBuddy and its successors). - **Initiative (rung 3):** the platform build, beginning with FreelanceBuddy as the first internal product and reference integration (the June step-zero dogfood). - **Project (rung 4):** the factory components (scaffolding templates, OpenAPI codegen pipeline, credential broker, observability-and-policy gateway, certification harness) plus the managed-hosting layer plus the first vertical workflow libraries. - **Task (rung 5):** one MCP server or one client integration or one factory component, owned by the relevant lane. - **Decision (rung 6/7):** the recurring judgment points: which API gets a vertical product versus a thin wrapper (heuristic: is there a real job-to-be-done with ROI language); read-only versus write-enabled guardrail posture (heuristic: blast radius of the destructive action); host-managed versus server-managed tokens (heuristic: the June 2025 auth-spec patterns); when a server is certified for production (heuristic: the testing harness plus, for high-risk integrations, manual security review). - **Data (rung 8):** the server library, the credential and token store, the per-tool-call observability and audit logs, the vertical workflow libraries, and the internal-product data (FreelanceBuddy's pipeline), all modeled on the Scatter Model IR. - **Event (rung 9):** the real occurrences captured: an MCP server built, certified, deployed, and called; a client integration delivered and maintained; an auth handshake completed; a guardrail enforced; a workflow library reused across a new client; a FreelanceBuddy application moved through its pipeline. If the tool call is not logged and attributed, it did not happen, which is the auditability the brand sells. ## 10. Sources - **Recording transcript:** `looikos_andy_transcript.md` lines 193-197 (Andy's core MCP Scientists walkthrough: cranking out solutions by taking APIs and building workflows on top and packaging as MCPs and marketing them; MCP Scientists as both the platform and where FreelanceBuddy is built; the 100-250 applications and 5-15 clients per month target). Line 286 (the boundary: MCP Scientists is "for tooling or agentic tooling, MCPS tools for agents," distinct from Agent Shipyard). Line 283 (the secret architecture: "custom MCP scientist developed deployed and managed tooling perfectly integrated to everything through the Scatter Model"). - **Cross-referenced ecosystem docs (referenced, not duplicated):** `projects/symphony-agi.md` (the harness this brand's agents run on, and the shared agent-infra valuation read in §3a). `projects/scatter-model.md` (the ECS/Pydantic-IR world-model layer the tools speak). `projects/agent-shipyard.md` and `projects/agent-design-pro.md` (the sibling layers, kept distinct per the-disconnection). `projects/freelancebuddy.md` (the first internal product). `THE_FLOOR.md` (the service-angle delivery model and the 100-250-customer / $2-12k+ / ~$1M-month economics). `LOOIKOS_ECOSYSTEM.md` §0 (the third-door and alpha-engineering frame). - **Perplexity Query 1 (MCP market + players + alpha), verbatim:** "Researching the market for Model Context Protocol (MCP) tooling as of 2026, for a brand called MCP Scientists... 1) The state and adoption of MCP in 2026... 2) Who builds/distributes MCP servers and tools today? Named registries and marketplaces (smithery.ai, mcp.so, PulseMCP, Glama, Composio, Zapier MCP, official MCP registry)... 3) Where's the alpha / third door for a brand that productizes 'API + workflow + MCP packaging + go-to-market' as a repeatable factory plus managed service?" Findings: MCP at benchmark status with AWS/Google/Cloudflare/OpenAI backing and an OpenAI app directory beta Dec 2025; thousands of public servers; the single-layer-player market structure (directories / connectors / wrappers / hosting) with a per-player what-they-do/refuse table; the full-chain factory-plus-managed-service third door and the structural reasons incumbents abstain. TAM tagged OPEN. Citations included adadvisor best-mcp-tools-business-2026, hallam.agency MCP-2026, digitalapplied MCP-adoption-statistics-2026, a16z MCP deep-dive, getknit future-of-mcp. - **Perplexity Query 2 (Lexicon of Pain / VoC), verbatim:** "I need the Voice of Customer / Lexicon of Pain in their actual words (Reddit r/mcp, r/LocalLLaMA, r/ClaudeAI, r/AI_Agents, Hacker News, GitHub issues, MCP Discord) for three groups dealing with MCP and API-to-agent integration in 2026: 1) developers building MCP servers... 2) businesses/operators who want their tools agent-accessible but can't build it... 3) solo operators building their own mission-control..." Findings: the three pain clusters with quotable phrases ("micro-infrastructure just so Claude can call it," "wrappers for wrappers," "guess who gets blamed? Me," "building tech debt with a shiny acronym," "download CSV, upload to chat," "gives our security team hives," "GitHub repos and vibes," "held together by Zapier zaps, cursed Google Sheets formulas, and a 3-page prompt," "chaos I happen to understand") and the fear/shame layer under each. Used directly in §4 personas and §5 PST. - **Perplexity Query 3 (MCP build/economics/factory reality), verbatim:** "Ground me on the build reality for an MCP tooling factory + managed-service platform in 2026... 1) How are production MCP servers actually built and operated (SDKs, spec, transport, auth, OpenAPI codegen, maintenance burden)... 2) economics and monetization of MCP tooling... 3) the feature-factory/repeatable-pipeline pattern... 4) what does a 'mission control' app for 100-250 freelance applications look like technically, and is building it on an MCP/agent platform sensible?" Findings: the JSON-RPC core, TS/Python SDKs, stdio-vs-streamable-HTTP transports, OAuth 2.1 and the June 2025 auth spec, OpenAPI-to-MCP codegen as a starting point, the maintenance/ops burden and how managed hosting handles it; monetization (paid servers / per-call billing / managed-hosting subscription / build-and-run retainer / marketplace take-rate 10-30%); the factory components (templating, codegen, credential broker, observability/policy gateway, certification harness) and the iPaaS/in-house-platform-team analogues; the FreelanceBuddy technical sketch and the "lean on MCP where it adds leverage, keep core CRUD simple" architecture call. Citations included hidekazu-konishi mcp_server_ecosystem_reference_2026, truto.one 2026-architecture-guide, workos everything-about-mcp-2026, prefect best-mcp-deployment-platforms-enterprise-2026, qualys MCP-shadow-IT-2026. Used in §3b, §3c, §7. - **Perplexity valuation comps (reused from the same-category Symphony AGI run), verbatim query referenced in `projects/symphony-agi.md` §10:** the agent-infra/dev-tooling M&A comps and ARR-multiple bands, the Databricks-MosaicML 65x-on-strategic-value lesson, the open-core-vs-API-wrapper underwriting, and the RBF (20-40% of ARR, 1.2-1.5x cap) / ARR-backed-debt (0.3-0.8x ARR, 8-15% plus warrants) terms. Applied here with the MCP-specific monetization detail from Query 3 (usage-metered per-call revenue gets the lender haircut; contracted retainers and subscriptions are the credit-bearing base). Used in §3a. - **VoC channels mined (via Query 2):** r/mcp, r/LocalLLaMA, r/ClaudeAI, r/AI_Agents, Hacker News, GitHub issues (awesome-mcp-servers), the MCP Discord. Note: Perplexity reconstructed representative phrasing rather than live-scraping ephemeral communities; the phrases are evidence-tagged as VoC-pattern (INFERRED-representative), consistent with the documented 2024-2026 MCP and integration discourse. - **Evidence tags:** the transcript seed and the MCP build reality (SDKs, spec, transport, auth, codegen, monetization, factory components) are VERIFIED (first-party and Perplexity-cited). The MCP market structure and adoption are VERIFIED (Perplexity, cited). The precise full-chain-studio niche TAM is OPEN. The three-angle valuation figures for MCP Scientists itself and the persona internal monologues are INFERRED (modeled from comps and the VoC lexicon). The exact Track-R repo harvest list is INFERRED-pending the cluster syntheses.