- 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)
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.
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. 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.
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.
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, is the infrastructure and monetization layer where agents are deployed, observed, evaluated, and budgeted. Agent Design Pro, also covered in a separate deck, 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.
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.
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. 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). 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.
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. 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.
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, 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.
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. 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.
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. 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.
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. 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.
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. The 100-250-customer target puts the service angle's floor around $1M/month, with room to scale above it. 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. The vertical doesn't matter; any business paying to make its tools agent-accessible and to keep them safe and alive qualifies.
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.
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.
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.
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.
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.
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.
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.
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. 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.
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.
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.
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.
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. 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.
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. 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. 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.
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; 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". 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.
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. 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.
The data models are the ECS / Pydantic-IR genome owned by the Scatter Model brand, which has a separate deck, 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). 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, 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.
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. 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; here it's the proof that the factory builds real things.
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, 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.