The Important Distinction

MCP is a protocol boundary. “MCP App” is a product and ecosystem term that can describe several different deployments:

text 
human or agent
      |
      v
Host / Client  -- approval, identity, UI, model policy
      |
      v
MCP Server     -- protocol endpoint and capability descriptions
      |
      v
application services, data, and external side effects

The protocol does not automatically provide a marketplace, a billing system, a trusted publisher, a user interface, or authorization. Those remain product and deployment responsibilities.

Four Product Shapes

Shape Typical use Main risk
local adapter expose a user-owned filesystem or development tool process permissions and local data leakage
remote integration connect a tenant to a SaaS or internal system token audience, object authorization, and data egress
embedded capability one product exposes a narrow feature to its own Host coupling, quotas, and support boundaries
catalog distribution many organizations discover and install Servers provenance, review, credentials, and lifecycle

These shapes can share an SDK but should not share assumptions. A local stdio adapter does not become a multi-tenant SaaS product by adding a manifest.

Capability Design

Tools, Resources, and Prompts have different contracts:

Primitive Contract Product question
Tool request may execute work or cause a side effect what is the exact object, actor, purpose, and idempotency key?
Resource returns bounded context or data who may read it, how fresh is it, and how is deletion propagated?
Prompt reusable instruction or interaction template what untrusted data can it include, and who may invoke it?

Prefer a narrow business operation over a generic capability:

json 
{
  "name": "invoice.get_summary",
  "description": "Return an approved summary for one invoice in the caller's tenant. Does not modify billing data.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "invoice_id": {"type": "string", "minLength": 1}
    },
    "required": ["invoice_id"],
    "additionalProperties": false
  }
}

The schema constrains shape. The server must still derive the principal from trusted context, check tenant and object access, bound the result, and redact sensitive fields.

Product Architecture

A production MCP product normally needs more than an SDK:

  1. Capability boundary: narrow Tools, Resources, and Prompts with versioned contracts.
  2. Identity boundary: authenticated principal, tenant, scopes, and workload identity.
  3. Policy boundary: object ownership, purpose, side effects, approvals, quotas, and egress.
  4. Reliability boundary: timeout, cancellation, retries, idempotency, backpressure, and recovery.
  5. Data boundary: minimization, retention, deletion propagation, audit, and export controls.
  6. Commercial boundary: plan, meter, invoice, refund, and support semantics.

Keep these boundaries explicit. A description or Tool Annotation can help a Host present risk, but it cannot authorize a call.

From Capability to Product

Use this sequence:

1. Identify a repeated job

Describe the user outcome, not the novelty of “AI integration.” Specify the input, evidence needed, expected result, human fallback, and unacceptable failure.

2. Choose the smallest interface

Start with one bounded read or reversible action. Avoid generic SQL, arbitrary HTTP, shell execution, unrestricted file access, and “do anything” prompts.

3. Establish ownership

For each object, define the source of truth for tenant, subject, account, price, role, and approval. Never accept those values from model-generated arguments when the application already knows them.

4. Measure the real outcome

Track successful business tasks, evidence correctness, authorization denials, duplicate side effects, latency tails, token and downstream cost, cancellation, and support events. Tool-call count alone is not product value.

5. Add distribution only after operations work

A catalog increases installation and supply-chain risk. First prove upgrades, rollback, credential rotation, incident response, rate limiting, and deletion.

Distribution and Discovery

A catalog or registry is an additional trust system. Its minimum design should include:

  • publisher identity and verified ownership;
  • signed or reproducibly built artifacts where applicable;
  • version and dependency pinning;
  • declared capabilities and side effects;
  • permission review before installation;
  • isolated credentials and network egress;
  • vulnerability and malicious-result response;
  • revocation, rollback, uninstall, and deletion propagation;
  • an audit trail for who installed and approved each version.

Discovery metadata is untrusted input. A listing cannot prove that a Server is safe, that its annotations are honest, or that every Tool should be exposed to every tenant.

Host and Client Experience

“Zero-code” is not the same as zero responsibility. A good Host should make the following visible at the moment of risk:

  • which identity and tenant will be used;
  • which objects will be read or changed;
  • whether the action is reversible;
  • what data leaves the boundary;
  • expected latency, quota, and cost;
  • what approval is required;
  • how to cancel or recover.

Natural-language selection can propose a capability. The application and server decide whether it may execute.

Billing and Metering

Pricing is a contract, not a model output. Define:

Question Required decision
unit request, successful outcome, bytes, duration, or subscription
retries whether provider or client retries are billable
cancellation when a canceled task incurs cost
duplicate delivery how idempotency avoids double charge
limits per-principal, tenant, plan, and downstream quota
evidence what the customer can inspect or dispute
privacy retention and deletion of metering data

Keep account, price, currency, discount, and ownership server-side. A model may select a plan-related intent, but it must not set the authoritative amount or customer identity.

Reliability and Support

An MCP product is an operational service. Test:

  • initialization and capability negotiation;
  • schema rejection and unknown fields;
  • authentication, scope, tenant, and object mismatch;
  • result size, pagination, and sensitive-field redaction;
  • timeout, cancellation, retry classification, and idempotency;
  • reconnects, duplicate delivery, and rolling upgrades;
  • downstream outage, partial failure, and compensation;
  • quota exhaustion and fair scheduling;
  • replayed fixtures and abuse cases;
  • deletion from primary data, caches, indexes, backups, and exports.

Publish an explicit compatibility matrix:

text 
Host x Client x SDK x MCP revision x Transport x Authorization

“Works with MCP” is too broad to be a support promise.

Minimal Product Manifest

Keep commercial and operational metadata separate from protocol capabilities:

json 
{
  "product_id": "invoice-summary",
  "server_version": "1.4.0",
  "mcp_revision": "pinned-revision",
  "transports": ["stdio", "streamable-http"],
  "capabilities": ["invoice.get_summary"],
  "side_effects": "read_only",
  "data_classes": ["tenant_invoice_metadata"],
  "required_scopes": ["invoices.read"],
  "result_limits": {"max_bytes": 262144},
  "support": {"rollback": true, "contact": "owned-by-provider"},
  "billing": {"unit": "authorized_successful_task", "retry_policy": "idempotent"}
}

The manifest is a review artifact. Runtime authorization must not trust a field merely because it appears in the manifest.

When Not to Build an MCP App

Do not create a catalog product when:

  • a deterministic API or scheduled workflow solves the job more clearly;
  • the capability has no stable owner or source of truth;
  • the data cannot be legally or operationally deleted;
  • the side effect cannot be made idempotent or approved;
  • the expected value cannot be separated from model speculation;
  • support and rollback are not funded.

An MCP interface is useful when it improves a real workflow, not when it merely adds a new label to an existing endpoint.

Decision Checklist

  • [ ] Define the user outcome and failure fallback.
  • [ ] Keep the first Tool narrow, bounded, and read-only or reversible.
  • [ ] Derive identity, tenant, object, price, and ownership from trusted application state.
  • [ ] Separate protocol capabilities from catalog, UI, billing, and support metadata.
  • [ ] Treat descriptions, annotations, prompts, resources, and results as untrusted.
  • [ ] Test cancellation, retries, duplicate delivery, quotas, and downstream failure.
  • [ ] Publish only after credential rotation, rollback, revocation, uninstall, and deletion work.
  • [ ] Document the exact Host, Client, SDK, revision, Transport, and Authorization matrix.
  • [ ] Measure successful outcomes and user trust, not only tool-call volume.

Conclusion

MCP can make a capability easier for a Host to discover and invoke, but it does not turn a protocol endpoint into a trusted app store or a business model. Build the narrow capability, establish the identity and object boundary, make failure and deletion observable, and only then choose distribution and billing. This order protects user experience because the product earns trust through predictable behavior rather than promotional claims.

Primary Sources