Investigation: Cursor IDE plugin

## Background

Cursor (https://cursor.com/) is an AI-first IDE with a large and growing share of developer mindshare, particularly among developers building AI-augmented applications — which overlaps substantially with Harper's target audience. This issue is to investigate what a Cursor plugin would look like and whether it's worth building.

## Why this is worth exploring

**MCP is already there.** Harper 5.1 ships a built-in MCP server (`harper mcp` stdio CLI, operations profile + application profile tool generation). Cursor natively supports MCP server connections through its settings. The lowest-friction first step may be as simple as a plugin that auto-detects a running Harper instance and scaffolds the MCP config — at which point Cursor's AI assistant has full access to Harper's schema, table operations, and custom tools without any additional work.

**Developer loop.** The primary friction point for Harper app development is the round-trip between the editor and external tools (CLI, Studio, REST calls) to inspect data, check schema, and manage tables. A plugin that surfaces those operations in-editor — even just a sidebar to query a table or tail logs — tightens the loop meaningfully.

**Distribution.** The Cursor Marketplace is a discovery surface. A "Harper for Cursor" listing puts Harper in front of developers who haven't heard of it through other channels, and signals that Harper is a modern, AI-native platform.

**Harper Agent in context.** The Harper Agent already handles app creation and management through a conversational interface. A Cursor plugin could embed that directly in the IDE, with the added advantage of having the agent know which file you're editing, what schema is active, and what errors the current code is producing.

## What to investigate

1. **MCP-first approach** — How much does Cursor's built-in MCP support cover? Can we ship a plugin that's primarily a MCP configuration helper (auto-detect local Harper, write `~/.cursor/mcp.json`, provide a UI to point at remote instances) rather than a full extension? This would have very low maintenance overhead.

2. **Extension API scope** — What does a fuller Cursor extension enable that the MCP path doesn't? Candidates: schema-aware code completion for Harper component files, inline Harper logs, sidebar table browser, component hot-reload status indicator.

3. **Overlap with `harper-agent`** — The agent already scaffolds and manages Harper apps. What's the right division of responsibility between the in-IDE plugin and the agent? Likely the agent handles creation/management reasoning; the plugin handles real-time IDE integration (completions, live status, quick queries).

4. **Effort estimate** — Cursor extensions are VS Code-compatible, so prior art is plentiful. A minimal MCP-config plugin is probably a day of work; a full-featured extension with schema completions and a table browser is a larger investment. Estimate both.

5. **Comparable art** — Prisma, Supabase, and PlanetScale all have VS Code/Cursor extensions. Review what they do and what's landed well vs what's underused.

## Proposed scope for an MVP

If we move forward, a reasonable first version would be:
- Auto-detect a local Harper instance (check well-known ports, parse `harperConfig.yaml`)
- Write/update `~/.cursor/mcp.json` to add the Harper MCP server entry
- Provide a command palette entry to point the plugin at a remote Harper host
- Bundle a Harper-specific system prompt snippet that gives Cursor's AI context on Harper's component model and schema conventions

This is essentially a distribution mechanism for the MCP server with a thin configuration UI on top.