Delicious

MCP server

Preview. The MCP server is in design — not yet live. It will mirror the REST API exactly.

The MCP server lets an agent (Claude, Cursor, your own) drive the whole pipeline conversationally — this is the "for Agents" path. It's a thin, faithful projection of the REST v1 surface: same auth, same scopes, same objects.

  • Transport: streamable HTTP MCP.
  • Auth: the same Bearer dk_… key as REST.

Tools

  • submit_idea({ pitch, audience?, monetization? }) → a run (idea mode).
  • ship_existing_app({ repo_url | spec }) → a run (ship mode — the complement surface).
  • get_run({ run_id }) · list_runs({ status? })
  • get_app_spec({ run_id }) · update_app_spec({ run_id, patch })
  • resolve_gate({ run_id, gate, decision, notes? }) — gate is idea/brand/final, decision is approve/reject.
  • get_artifacts({ run_id, kind? }) · get_scorecard({ run_id })
  • cancel_run({ run_id }) · list_apps()

Resources

  • run://{id} — exposes live run state (stage, pending gate, latest scores) so the agent always has current context without re-polling.

Prompts

  • review_app_spec — walk the user through approving the spec at the idea gate.
  • explain_rejection — turn a failed gate or App Review rejection into plain next steps.
  • next_action_for_run — translate a run's current state into the human's next move.

Design rule

The MCP tools are generated from the REST surface, not hand-maintained in parallel — so the two never drift. Build REST first; wrap MCP from it.