FrontPanel Platform API - v6.1.0
    Preparing search index...

    Interface AppMCP

    The mcp sub-API exposed on window.FrontPanelAPI for app renderers whose effective bindings permission is "allow".

    Lifecycle:

    1. App calls register(...) for each tool it intends to expose (must match a name in the package's mcp.json).
    2. App calls useWorkQueue(...) once with the WorkQueue it uses for UI device work, so MCP-driven work serializes against UI.
    3. App calls ready() to publish the registration batch — one tools/list_changed notification fires.
    4. Subsequent register/unregister calls (e.g., when gateware unlocks new capabilities) are microtask-coalesced into single tools/list_changed notifications.

    register / unregister / ready are async because the authoritative validation lives in main (descriptor membership, duplicate-name detection). Apps that await them learn at the call site if the descriptor and code disagree, rather than later at first tools/call. Apps that don't await still get console errors via unhandled rejection — the local handler map is rolled back on failure so the renderer's view stays consistent with main.

    Error notes:

    • Errors thrown across IPC lose their prototype; consumers discriminate on .name. register/unregister/ready re-throw with that contract preserved.
    interface AppMCP {
        ready(): Promise<void>;
        register(name: string, handler: MCPHandler): Promise<void>;
        runOnQueue<T>(task: () => Promise<T>): Promise<T>;
        unregister(name: string): Promise<boolean>;
        useWorkQueue(queue: WorkQueue): void;
    }
    Index

    Methods

    • Returns Promise<void>

    • Parameters

      Returns Promise<void>

    • Type Parameters

      • T

      Parameters

      • task: () => Promise<T>

      Returns Promise<T>

    • Parameters

      • name: string

      Returns Promise<boolean>