How will MCP apps change software distribution?

MCP apps change distribution because users can discover and operate software inside an AI conversation, at the moment a job appears. They do not remove the need for a product, a server, authentication, support, or sales. They move the first useful interaction closer to intent and make the host part of the delivery path.

That shift is large enough to matter and narrow enough to misunderstand. A founder who treats an MCP app as a miniature website will rebuild familiar screens inside a cramped frame. A founder who treats it as a set of tools with an optional interface can enter several hosts, learn which jobs users delegate, and earn the right to build a larger product. Distribution starts with a callable outcome, not an icon in another marketplace.

What do MCP apps add to ordinary MCP tools?

MCP apps add an interactive View to an MCP tool result. An ordinary Model Context Protocol server exposes tools and resources. The model can call a tool and the host can render text or structured data. The Apps extension lets a tool point to a ui:// resource containing HTML, which the host renders in a sandboxed iframe. The View receives tool inputs and results, then communicates with the host over JSON-RPC through postMessage.

The distinction matters. The model still chooses and calls a tool. The server still owns business logic and data access. The host still owns the conversation, consent surfaces, and iframe. The View gives the user controls where natural language is clumsy: filtering a chart, adjusting several dependent inputs, choosing rows, previewing media, or confirming a consequential action.

The official MCP Apps specification dated 2026-01-26 defines four pieces worth remembering: predeclared UI resources, metadata that links a tool to a resource, bidirectional communication, and mandatory iframe isolation. It also requires capability negotiation. A host advertises support for the io.modelcontextprotocol/ui extension and supported MIME types. A server should provide meaningful text content even when a UI exists, so a tool can degrade cleanly in a host that does not render Apps.

This is progressive enhancement, not a new application runtime that replaces the web. If your result is a short answer or a single irreversible action with a clear confirmation, text may be better. If the user must inspect, compare, manipulate, or revise a structured result, the View can remove ten conversational turns without hiding the decision.

The extension also separates model-visible tools from app-only tools. A refresh button or pagination control can call a tool whose visibility includes app but not model. That keeps mechanical UI operations out of the model's tool list. It reduces tool-selection noise and prevents the transcript from filling with interactions that do not require reasoning.

Distribution moves from acquisition to invocation

MCP app distribution begins when a host can match a user's request to your tool description. Traditional software asks a person to recognize a problem, search for a category, compare vendors, create an account, and remember to return. An app over MCP can appear after the person states the problem in ordinary language. That is a shorter path, but the model and host now mediate it.

The unit of discovery therefore changes. A website page competes for a click. A mobile listing competes for an install. An MCP tool competes to be the best declared action for a specific intent. Its name, description, input schema, authentication requirements, and observed reliability shape whether it gets called. The interface appears only after that choice, so a polished View cannot rescue a vague tool contract.

This creates three distribution layers that teams should track separately:

• Protocol reach is the number of compatible hosts in which the server can connect and its tools can run.
• Host discovery is how a user finds, approves, and enables the server within each product.
• Workflow pull is how often a real request causes the tool to be selected and completed.

Calling all three "distribution" produces bad decisions. Protocol compatibility can be high while installation remains awkward. A marketplace listing can generate many enables while the model rarely selects the tool. A private deployment can have little public reach and still produce strong revenue because one workflow runs hundreds of times inside a company.

The official MCP Registry helps with the first two layers, but it is not an app store and does not manufacture demand. Its documentation describes a centralized metadata repository for public servers, with namespace verification and standardized installation information. The registry expects downstream aggregators and marketplaces to add curation, ratings, or security review. Host applications are expected to consume those downstream registries rather than treat the official registry as the final storefront.

That design pushes commercial presentation toward hosts and aggregators while keeping server identity portable. Publish accurate metadata, but do not confuse publication with distribution. You still need examples that teach the model when to call the tool, an onboarding path a human trusts, and a job that occurs often enough to create retention.

Portability does not erase host differences

A conforming MCP app can reuse its server and View across hosts, but it will not behave identically everywhere. The protocol standardizes the connection between server, host, and iframe. It does not standardize every installation flow, viewport, theme, approval prompt, account system, telemetry hook, or marketplace rule.

Capability negotiation is the first guardrail. At initialization, inspect whether the host advertises the Apps extension and the HTML profile. Register or return a text-capable variant when it does not. Inside the View, inspect host capabilities before asking it to open a link, send a message, or perform another optional action. Treat a missing capability as normal, not an exception that leaves an empty panel.

Layout needs the same discipline. A dashboard that assumes a full browser width can become unusable in a narrow conversation column. Start with one primary decision, a readable default state, keyboard access, and controls that survive a small frame. Expand when the host grants more space. Do not reproduce the navigation shell of your web product inside the host's navigation shell.

Authentication also remains host-specific at the edges. A remote MCP server may use a standard authorization flow, but account linking, reauthentication, and consent presentation can vary. Design the server so identity and entitlements live behind the tool boundary. The View should receive only the data and actions needed for the current job. If a different host changes its iframe origin or storage behavior, your paid entitlement must not disappear with browser-local state.

Build a small compatibility matrix before promising "works everywhere." Record connection transport, Apps extension support, supported host capabilities, frame behavior, authentication completion, tool approval behavior, and teardown. Test the same golden task in every host. The result should be equivalent even if presentation differs.

Portability saves the cost of separate integrations; it does not remove release testing. I have watched teams celebrate a shared protocol and then ship host-specific failures because nobody owned the last meter. Assign that ownership before launch.

Build the first app around a decision, not a dashboard

The best first MCP app helps a user make one bounded decision using data or actions that already live behind an MCP server. Good candidates have a clear intent sentence, structured inputs, a result that benefits from direct manipulation, and a completion event you can measure. A generic dashboard usually lacks all four.

Consider a cloud cost product. "Show spending" yields a chart but weak intent and no completion. "Find services that can be downsized, let me exclude production, and prepare the approved changes" creates a decision loop. The model gathers the scope, the server calculates candidates, the View lets the user inspect and exclude rows, and a separate tool prepares or applies an authorized action. The UI earns its space because visual comparison and selection beat repeated prompts.

Use a four-part test before committing engineering time:

1. Write the user request that should cause the first tool call. If it needs a paragraph of product terminology, discovery will be weak.
2. Describe the decision the View makes easier. If the answer is "see our product," build a web page instead.
3. Name the completion event, such as an approved budget, submitted configuration, exported selection, or resolved incident.
4. State what a non-App host receives. If the fallback cannot carry a useful result, the server contract is too dependent on the View.

Avoid beginning with a blank canvas, a full admin console, or a workflow that requires broad write access. Blank canvases give the model little evidence about success. Admin consoles bring permissions, navigation, and state that already work better in a browser. Broad access raises the approval burden before the user has received value.

Start with a read-heavy workflow and one narrow write action behind explicit confirmation. This is not timid product design. It is a fast way to learn whether conversational discovery produces qualified use. Once users repeat the job and ask for the next action, you have evidence for expansion.

The tool contract is the real product surface

A model selects the tool from its contract before a user sees your interface, so tool design carries product positioning, safety, and conversion. Names should describe actions. Descriptions should say when the tool applies, what it returns, and important limits. Input schemas should expose meaningful choices without making the model reconstruct your internal database.

Suppose the first app reviews engineering work for an upcoming release. A narrow contract might accept a repository identifier, a release window, and an optional risk threshold. It returns issue identifiers, reasons, owners, and recommended actions as structuredContent, plus a short textual summary for hosts without Apps. The View renders sortable rows and lets the user request details through an app-only tool.

This request and response shape is small enough to use as a contract test:

{
  "name": "review_release_risks",
  "arguments": {
    "repository": "acme/payments",
    "releaseWindow": "2026-08-14",
    "minimumSeverity": "medium"
  }
}

A successful result should preserve a useful text fallback and give the View stable data:

{
  "content": [
    {
      "type": "text",
      "text": "Found 3 release risks. One is high severity and two are medium."
    }
  ],
  "structuredContent": {
    "reviewId": "rr_1842",
    "risks": [
      {
        "id": "risk_31",
        "severity": "high",
        "reason": "Database migration has no rollback command",
        "suggestedAction": "Add and test a down migration"
      }
    ]
  }
}

Test the fallback text, schema validation, empty state, partial data, authorization failure, and retry behavior without loading the View. Then test that the View renders the same structuredContent and that its buttons call only allowed tools. This order exposes whether the server is a sound product or a UI hiding a loose API.

Keep UI-only mechanics separate. The specification allows visibility set to app for tools the iframe may call but the model should not see. A get_release_risk_detail tool can support row expansion without consuming model attention. A confirm_release_change tool probably belongs in model and app visibility because the host may need to present consent and the agent must understand the consequence.

Version the semantics, not only the code. Adding an optional field is usually manageable. Changing the meaning of severity, silently widening a write action, or removing fallback content can break host behavior without a compile error. Store golden requests and expected result shapes in CI, and run them against every server release.

Trust is part of the install funnel

Users and host operators evaluate an MCP server as delegated authority, not as a decorative plugin. The server can receive context, access connected systems, and perform actions. Every permission request and external domain therefore affects conversion. Security review is part of distribution work.

The Apps specification gives teams a useful constraint: the View runs in a sandboxed iframe, and the host constructs a Content Security Policy from declared metadata. If an app omits CSP domains, the restrictive default blocks external connections and external resources. A host may restrict the policy further, but it must not allow an undeclared domain. That is a good default. Bundle the View when practical and declare the smallest set of origins it genuinely needs.

Do not interpret sandboxing as proof that the whole product is safe. The iframe may be isolated while the server holds powerful credentials. Tool descriptions can still invite overly broad calls. A write tool can still act on the wrong tenant. Authorization, tenant isolation, audit logs, idempotency, rate limits, and confirmation for consequential actions still belong on the server.

The official registry verifies that a publisher controls a GitHub or domain namespace. Its own documentation says it delegates code scanning to package registries and downstream aggregators. Namespace verification answers "who published this?" It does not answer "is this implementation safe?" Put that distinction in your sales material and internal review so nobody treats a registry entry as certification.

A sensible public listing should state requested systems, read and write scope, data retention, support contact, and the reason for every permission. For enterprise buyers, prepare a data-flow diagram, deletion behavior, incident contact, and a list of subprocessors. These are sales assets because they shorten approval time. Vague claims about security make the buyer's reviewer do more work.

Instrument consent without collecting conversation content you do not need. Record that a tool call was requested, approved or denied, completed or failed, and which coarse failure class occurred. Redact tool arguments by default, then add allowlisted fields only when they are safe and needed. The quickest way to poison distribution is to surprise a user about where their prompt data went.

Monetization stays attached to the server and account

MCP Apps define interaction, not billing. The protocol does not give every developer a universal checkout, entitlement system, or revenue share. Your company still needs an account relationship, a way to determine plan access, and a purchase path allowed by each host. Keep entitlement checks on the server so the same customer receives the same access across supported hosts.

There are four credible commercial shapes. Existing SaaS products can include MCP access in current plans and use the app as a lower-friction interface. Usage products can meter completed server work, such as processed documents or executed analyses. Team products can charge per workspace or capacity because shared data and controls create the value. Service businesses can use an app as a diagnostic surface that leads to a scoped engagement.

Do not charge for the novelty of appearing in chat. Charge for an outcome, proprietary data, controlled execution, saved labor, or reduced risk. A free chart backed by public data will face copies. A workflow that combines company context, policy, approval, and execution has more defensible economics.

Avoid an early recommendation I hear often: put a paywall immediately after the first tool call to test willingness to pay. It is popular because the signal looks clean. It is usually wrong because the user has not yet learned whether the app can complete the job, and the host-mediated flow already asks for trust. Let a new user reach one meaningful result, then gate repetition, scale, collaboration, premium data, or execution.

The View should explain an entitlement boundary in plain language. The server must enforce it. Never rely on hiding a button, since an app or model can call tools directly. Return a structured error that distinguishes authentication required, plan required, quota reached, and permission denied. Give the host enough text to explain the next action without exposing account details.

For a consulting or audit offer, the useful app may stop before automated execution. It can collect structured evidence, show the cost or workflow pattern, and make the scope of human work legible. On oleg.is, that logic supports a Team & AI Audit when the evidence shows duplicated engineering work or weak AI operating practices; the app should diagnose the boundary without pretending a chat widget can replace leadership.

Revenue signals appear before revenue

The strongest early monetization signal is repeated completion of the same costly job by the same account. Installs, tool impressions, and iframe opens measure exposure. They do not show that a user obtained enough value to pay. Track the path from expressed intent to completed outcome.

A useful event model has six stages: server enabled, tool eligible, tool called, View rendered or fallback delivered, workflow completed, and workflow repeated. Add approval denied, authentication failed, user abandoned, and server failed as explicit exits. Measure accounts as well as events so one developer testing fifty times does not look like fifty prospects.

Completion must match the product promise. For a budget allocator, moving sliders is activity; saving an approved allocation is completion. For incident triage, opening a table is activity; assigning or resolving the selected incidents is completion. For a design review, generating a preview is activity; exporting or accepting a choice is completion.

Watch these signals in order:

• Users restate the same intent and select the tool without extra prompting.
• Accounts repeat the completed workflow within its natural cycle.
• Users connect higher-value data or invite a teammate after the first result.
• Users hit a real capacity boundary and ask to continue.
• Buyers ask about control, support, auditability, or procurement.

The last signal often matters more than a flood of casual use. Questions about access controls and invoices sound like friction, but they show that someone is imagining the app in a real operating process. Conversely, users who praise the interface and never complete the job are giving design feedback, not a business signal.

Price tests should follow the constraint users already reveal. If they want more runs, test usage or capacity. If collaboration creates demand, test workspace pricing. If approval and accountability dominate, test an organizational plan. If every account needs substantial configuration, sell onboarding or a service rather than burying labor inside a cheap subscription.

Ship through three controlled releases

A disciplined release sequence can test the distribution thesis before you fund a product suite. Keep each release long enough to observe the workflow's natural repeat interval. Weekly work needs several weeks; a quarterly planning tool needs design partners and explicit follow-up because passive retention data arrives too slowly.

Release one to a handful of design partners with direct installation instructions. Support one host, one read-heavy tool, one View, and one completion event. Watch calls and failures with consent, interview users after they complete or abandon the job, and fix contract ambiguity before adding features. The goal is not scale. It is proving that the model invokes the right tool for the right request and the user can finish.

Release two adds a second host and text fallback verification. It also introduces authentication recovery, entitlement errors, and a narrow write action if users have asked for it. Compare the same golden task across hosts. Any host-specific branch must have an owner and a test, or portability debt will grow invisibly.

Release three adds public metadata in the official registry where eligible, then pursues the downstream marketplace or host channels relevant to the buyer. Prepare a short description centered on the job, accurate permissions, screenshots or examples required by the channel, support terms, and the commercial path. Measure which channel produces completed workflows, not listing views.

Set kill criteria before public promotion. Stop or redesign if the model frequently selects the tool for the wrong intent, users need manual rescue for ordinary completions, permission denial dominates, or repeat use does not appear within the natural cycle. More hosts will multiply those defects. They will not solve them.

Set expansion criteria too. Add another workflow when existing accounts repeatedly ask for an adjacent action and the same data and authority can support it. Add another host when target accounts already use it or a channel can deliver them. Add paid capacity when repeat users meet the boundary, not when the roadmap says billing is due.

Choose the server delivery model as part of this release plan. A local package can suit developer tools and data that must stay on a workstation, but every runtime requirement increases installation failure and support cost. A remote server gives you one deployed version, centralized entitlement checks, and faster fixes. It also makes your uptime, latency, tenant isolation, and authorization flow part of every customer interaction. There is no universally superior choice. Pick the model that matches the data boundary and the buyer who approves it.

For a remote commercial product, separate the connection from account creation. The connection proves that a host can reach the server. Account linking proves who the user is. Workspace selection proves which organization owns the data. Entitlement checking proves what the organization bought. When teams collapse those into one callback, support cannot tell whether a failed first run came from transport, identity, tenant choice, or plan access. Record each transition as a distinct event and return a distinct, safe error.

For a packaged local server, make installation deterministic. Pin the command and required environment variables in server metadata, provide a health tool with no write scope, and fail before the model tries a business action if configuration is incomplete. The official registry can describe packages, remote URLs, arguments, and environment variables, but a host or downstream marketplace decides how much of that setup becomes one click. Test the published metadata in the exact channel, not only in your development client.

Channel partnerships also change the roadmap. A host may offer qualified reach but require review, support response times, or UI behavior that your direct install never needed. Treat that work as customer acquisition cost and compare it with completed paid workflows from the channel. Protocol support alone is cheap; dependable channel operations are not. A channel that sends many curious users and few repeat completions can consume more engineering time than a small direct program with clear buyers.

The durable advantage sits behind the View

The View will become easier to copy than the system behind it. Standard components, starter templates, and host conventions will make competent interfaces cheap. A lasting product needs a server that combines trusted data, precise tools, account memory, policy, and execution better than a generic agent can assemble on demand.

That changes what a founder should protect. Do not spend the first months perfecting custom chrome. Invest in tool semantics, authorization, data quality, evaluation cases, fast failure recovery, and evidence that the workflow produces a better outcome. These assets improve every host and every interface.

MCP apps also make narrow products more plausible. A conventional SaaS product needs enough surface area to justify a destination users visit. An app can meet the user inside an existing destination and do one job well. That lowers packaging cost, but it also exposes weak products quickly. If the server only wraps a common API with generic descriptions, the host or another server can substitute it.

The opportunity is not "an app store inside AI." It is a new path between stated intent and governed software action. Build one decision loop, keep the server useful without the iframe, and measure repeated completion. When those three hold, distribution and monetization have something real to amplify.