mcpField
M
mcp-apps-builder

mcp-apps-builder

github.com/mcp-useDevelopment10.8k32.8k installsUpdated 1d ago
Repository

About mcp-apps-builder

mcp-apps-builder is a skill for implementing projects with the mcp-use framework. It guides agents to inspect the installed version, follow current APIs, build MCP Apps, and verify changes against real project behavior.

Key features

  1. 01Inspect installed APIs and project files
  2. 02Build tools and interactive Views
  3. 03Follow version-specific framework conventions
  4. 04Validate changes through real lifecycles
  5. 05Avoid unsupported APIs and unsafe state

Use cases

  1. 01Adding an interactive View to an MCP tool
  2. 02Adapting a project to its installed mcp-use version
  3. 03Checking behavior before reporting implementation complete

MCP support

The skill guides implementation of MCP servers and interactive MCP Apps with mcp-use, including tools, resources, prompts, and Views.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/mcp-use/mcp-use --skill mcp-apps-builder

After installing, type/mcp-apps-builderin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

LICENSE.txt
references/
advanced-features.md
auth.md
migration.md
server.md
skills-over-mcp.md
verification.md
views.md

Details

From the project README

Build with mcp-use

Treat the installed mcp-use package, its exported types, generated declarations, and the project's existing code as the source of truth. Inspect the installed version before choosing APIs or changing code.

Workflow

  1. Inspect package.json, the server entry, exported tool refs, mcp-env.d.ts, views/, skills/, and the installed mcp-use version.
  2. Scaffold a new stable project with create-mcp-use-app@latest and the appropriate template. Match the package version or dist-tag when working on beta, canary, or an existing versioned project.
  3. Read only the references needed for the task:
    • Server for tools, resources, prompts, MCP middleware, request context, and result envelopes.
    • Views for interactive MCP Apps, React hooks, model context, host capabilities, assets, CSP, and endpoint/UI domain handling.
    • Authentication for OAuth providers, verified identity, scopes, permissions, and authorization.
    • Skills over MCP when a server should ship reusable workflows alongside its tools.
    • Advanced features for OpenAPI, proxying, notifications, subscriptions, and elicitation.
    • Migration only when retired or compatibility-only imports, helpers, registration shapes, UI patterns, or session assumptions are present.
    • Verification before reporting implementation work complete.
  4. Implement against installed types. Prefer the framework's current conventions over copied examples or historical changelogs.
  5. Validate the smallest real lifecycle that proves the changed behavior, then expand checks in proportion to risk.

Core invariants

  • Import server APIs from mcp-use, React APIs from mcp-use/react, and OAuth provider adapters from their mcp-use/oauth/* subpaths.
  • Define tool arguments with inputSchema. Add outputSchema for structured results and every View-bound tool.
  • Return raw MCP result envelopes. A successful schema-backed tool must include matching structuredContent; an expected failure may return isError: true with model-readable content.
  • Put each View at views/<name>/view.tsx and bind it with view: { name: "<name>" }.
  • Export every statically declared tool ref consumed by a View. Default-export the server entry used by mcp-use dev, build, and start.
  • Keep identity and mutable workflow state request-scoped or in an external store. Treat client-reported metadata as unverified.
  • Consider Skills over MCP when a server exposes a repeatable, multi-step workflow that would otherwise inflate tool descriptions.

Guardrails

  • Do not invent exports, configuration fields, or callback shapes. Confirm uncertain details in installed declarations or source.
  • Do not preserve APIs that are absent from the installed version merely because they appear in an existing project.
  • Do not return a plain domain object from a tool callback.
  • Do not bind a View without a matching outputSchema and structuredContent result.
  • Do not use module globals for cross-request identity, elicitation continuity, or durable business state.
  • Do not claim success from a source build alone when types, package exports, authentication, or interactive behavior changed.
  • Do not deploy or mutate external systems unless the user explicitly requests it.

Comments

Markdown supported