Built on Model Context Protocol

AI-First Capability Units
for Modern AI Systems

MCPlet is a code-first convention profile on top of MCP and MCP Apps that packages business intent with explicit visibility, authentication, and safety boundaries for AI operations.

Status Draft specification
Current version v202603-03
Updated 2026-03-27
Host profiles WebUI and Agent
Maintained by MCPlet Working Group
MCPlet = AI Flexibility + UI Convenience + Passkey Authenticity
🤖
AI Flexibility
AI agents handle complex reasoning and tool orchestration with full flexibility
🖥
UI Convenience
Rich interactive interfaces via MCP Apps for intuitive human interaction
🔐
Passkey Authenticity
FIDO2 Passkey ensures real human presence, enabling true Human-in-the-loop
MCPlet architecture banner showing AI host, MCPlet intent unit, and MCP server relationships

What is MCPlet?

MCPlet is a constrained, single-intent capability unit built on Model Context Protocol. Each MCPlet packages one business intent, explicit safety boundaries, and optional UI so hosts can expose AI tools in a predictable, reviewable, and secure way.

Single Intent

Each MCPlet represents exactly one business intent. No ambiguity, no complexity—just focused, purposeful capability.

MCP Tool Integration

Each MCPlet wraps one MCP tool invocation, providing a standardized interface for AI systems.

📱

Optional UI

Deliver rich interactive experiences via MCP Apps, with automatic fallback to text-based responses.

🔒

Safety First

Explicit lifecycle and safety constraints ensure AI systems operate within defined boundaries.

📊

AI Metadata

Rich output metadata enables AI reasoning about operations, suggestions, and next steps.

🚀

Stateless Design

Pure functional model with no hidden state. All data flows through the Host for transparency.

🔒

Passkey Authentication

Built-in FIDO2 passkey support for secure, passwordless authentication with direct AI Chat integration, enabling fast Human-in-the-loop with ease.

What are the three MCPlet types?

MCPlet classifies tools as read, prepare, or action. Read tools are safe and idempotent, prepare tools stage or validate inputs before commitment, and action tools cause side effects and therefore require stronger confirmation and enforcement.

read

Query & Search

Safe, idempotent operations for data retrieval with no side effects.

  • No side effects
  • Idempotent by design
  • Safe for autonomous AI
  • Returns enriched data with metadata
prepare

Validation & Setup

Gather or validate information before committing to irreversible actions.

  • May require confirmation
  • No irreversible side effects
  • Returns structured preparation data
  • Enables progressive workflows
action

Execute & Commit

Operations that cause irreversible side effects with mandatory human oversight.

  • Explicit human confirmation
  • Clear intent surfacing in UI
  • Returns results with guidance
  • Full audit trail maintained

How does MCPlet handle authentication?

Protected MCPlets declare authentication in code-first `_meta.auth` metadata. For model-visible actions, the host intercepts the call, obtains a Passkey assertion, and the backend verifies it before the business action runs.

_meta contract
{
  "_meta": {
    "mcpletType": "action",
    "visibility": ["model", "app"],
    "mcpletToolResultSchemaUri": "mcplet://tool-result-schema/approve_order",
    "ui": {
      "resourceUri": "ui://orders/approve.html",
      "displayMode": "inline"
    },
    "auth": {
      "required": "passkey",
      "enforcement": "strict",
      "promptMessage": Please authenticate with Passkey to confirm the operation
    }
  }
}
            
  • 🔒

    FIDO2 Standard

    Uses WebAuthn/FIDO2 standards for maximum security and browser compatibility.

  • 📱

    Host Interception

    The host pauses protected action calls, runs the Passkey ceremony, and injects credentials outside business arguments.

  • Strict Enforcement

    Model-visible actions can require backend verification so unconfirmed side effects never execute silently.

  • 🔒

    Stateless Backend

    The host owns state and orchestration while the MCPlet backend verifies Passkey assertions without hidden session coupling.

How does MCPlet architecture work?

MCPlet sits between an AI-capable host and an MCP server. The host manages state, policy, and orchestration, while each MCPlet keeps one intent, explicit metadata, and a clear execution path for UI or agent-driven flows.

AI Host
AI Agent
MCPlet
Intent Unit
MCP Server
Tool Provider

What design principles define MCPlet?

MCPlet is designed to make AI operations predictable: one intent per unit, stateless execution, explicit visibility, progressive enhancement, and security controls that keep side effects reviewable.

01

Single Intent

Each MCPlet does one thing well. No Swiss Army knives—just focused, purposeful capability.

02

Stateless by Default

No hidden state, all data flows through the Host. Transparency as a design requirement.

03

AI-First Design

Output includes rich metadata specifically designed for AI reasoning and decision-making.

04

Progressive Enhancement

Works perfectly in text mode, enhanced with rich UI when MCP Apps support is available.

05

Safety Constraints

Explicit side effects, mandatory review for actions. Security by design, not by accident.

Start with the canonical draft

Use the HTML specification overview for quick reading, the raw markdown for normative source text, and the FAQ for direct answers to adoption questions.