Ductape MCP Server

Migration guidance is available from ductape_docs({ topic: "migration" }). It starts with an original E2E baseline, defaults to a separate new codebase, requires contextual review and strict parity evidence, and ends against the unchanged original E2E suite. Administrative work and marketplace discovery use ductape_cli; ductape_execute remains publishable-key runtime-only. MCP never accepts or forwards DUCTAPE_ACCESS_KEY.

MCP (Model Context Protocol) server that exposes Ductape SDK operations as tools. All calls go through the Ductape backend proxy at a fixed URL; the SDK never runs in the MCP process. It is completely stateless; you provide your Publishable Key per execution.

Prerequisites

• Ductape backend (proxy and users services) reachable at https://api.ductape.app (handled automatically)
• A workspace Publishable Key (from your Ductape workspace)

Install

cd platform/mcp-server
npm install

MCP SDK: npm install pulls in @modelcontextprotocol/sdk and zod (v1, recommended). For the v2 alpha server package instead, use npm install @modelcontextprotocol/server zod @cfworker/json-schema.

Configuration & Run

npm run build && node dist/index.js

Or with tsx:

npm run dev

The server uses stdio transport (stdin/stdout), so it is intended to be spawned by an MCP client (e.g. Cursor). There are no environment variables required to run the server.

Cursor configuration

In Cursor, add the server in MCP settings (e.g. ~/.cursor/mcp.json or project .cursor/mcp.json):

{
  "mcpServers": {
    "ductape": {
      "command": "node",
      "args": ["/absolute/path/to/Ductape/platform/mcp-server/dist/index.js"]
    }
  }
}

Use an absolute path for args[0].

Tools

The server exposes runtime, schema, documentation, CLI, discovery, migration, and setup tools. Core tools include:

1. ductape_execute:

   • It runs any allowed SDK module method via the backend proxy.
   • Arguments:
     • publishable_key (string, required for authentication)
     • module (e.g. databases, storage, vector)
     • method (e.g. query, list, findSimilar)
     • params (array of positional arguments matching the SDK).
   • Full reference: The tool description embeds the complete list of modules, allowed methods, and their expected parameters for quick reference. (See docs/TOOLS.md if using a client that requires it).

2. ductape_generate_payload:

   • Calls backend POST /integrations/v1/payloads/generate.
   • Returns canonical executable payload templates with schema metadata ({ payload, meta }).
   • Intended for MCP-assisted code snippet generation and payload prefill in agent workflows.
   • Arguments:
     • workspace_id, user_id, public_key
     • product_tag, env_slug
     • operation_family, method
     • optional targets, schema_mode, include_session, include_cache, input_hint

3. ductape_generate_snippet:

   • Calls ductape_generate_payload flow and returns:
     • generated payload/meta
     • ready-to-copy SDK snippet in typescript or python
   • Intended for engineers and copilots that need executable examples quickly.

4. ductape_events_topic_setup / ductape_events_validate_project:

   • Generate one canonical ductape/events/<topic-tag>.topic.json asset shape without writing it.
   • Validate filenames, one-object-per-file schemas, unique qualified tags, supported fields, and publisher references before provisioning.
   • Aggregate topic catalogues, manifests, envelope registries, and custom event registries are rejected.

5. ductape_function_setup:

   • Produces the secure local and remote setup for application functions referenced by portable Features.
   • Requires an externally reachable HTTPS base URL (HTTP only for localhost development).
   • Returns deterministic well-known routes, framework raw-body requirements, HMAC-SHA256 headers, runtime verification steps, and fail-closed conditions.
   • Agents must implement and verify the route; they must not claim remote availability from local registration alone.
   • Agents must first extract native Ductape primitives from migrated code and reserve Functions for irreducible residual domain logic while preserving original transaction boundaries.

6. ductape_frontend_analytics_validate_project:

   • Read-only audit for deployable applications using @ductape/react, @ductape/vue, or the browser client.
   • Requires an enabled, deferred, or prohibited decision per application in ductape/analytics/frontend.json.
   • When enabled, checks analytics usage, authenticated identity lifecycle, router pageviews, named events, client-failure signals, and auto-capture privacy review.
   • Reports actionable findings without rewriting application source.

The ductape_cli MCP tool also exposes public app discovery: marketplace search <capability>, marketplace categories, and marketplace get <app_tag>. Inspect the app before generating or executing an action payload.

Feature classification

ductape_docs({ topic: "features" }) treats a Feature as a named, reusable product capability with a stable input/output contract and a useful managed-execution boundary. Features may be synchronous and entirely local; Events, signals, schedules, waits, retries, and rollback are optional patterns. Repository analysis distinguishes FEATURE, FEATURE_STEP, DOMAIN_SERVICE, UTILITY, and INFRASTRUCTURE_ADAPTER, explains its evidence, and groups related low-level operations instead of turning every exported function into a Feature.

Security

• Passing the publishable_key on a per-request basis guarantees that each execution is isolated. This architecture safely supports deployments that multiplex multiple user connections in a single server thread (e.g., SSE), avoiding cross-tenant leakage.