Integrates with Cursor CLI and Anthropic Claude for automated code generation and project management. Supports multi-build orchestration, design pattern management, and real-time build tracking via WebSocket and HTTP endpoints.
This server has moderate structural issues. Tool definitions are present with schemas and descriptions, but many descriptions are terse (under 50 chars), parameters lack detailed guidance, error handling is minimal, and there are significant security concerns (secrets passed as parameters). The server also exposes internal implementation details (buildId, promptId, retryCount flags) that should be hidden from LLMs. Tool composition is reasonable but lacks idempotency guidance and output schema documentation. No tool annotations (readOnlyHint/destructiveHint/idempotentHint) are present, and error responses are generic JSON blobs without actionable recovery guidance.
Secrets exposed as tool parameters: gitHubToken, gitUserEmail, supabaseServiceRoleKey, cursorApiKey, claudeApiKey all passed as input parameters. These will be logged in agent traces and prompt history, creating credential leakage vectors.
No output schemas documented. LLMs cannot infer what fields will be returned from tools like cursor/get-project-state or cursor/get-files. This prevents proper downstream tool chaining and forces agents to guess at response structure.
Descriptions too terse to guide LLM selection. 'Get current project state' (28 chars), 'Build the project' (17 chars), 'Run tests in the project' (24 chars) lack context on WHEN to use each tool vs alternatives and what prerequisites exist.
Move all credentials (gitHubToken, cursorApiKey, claudeApiKey, supabaseServiceRoleKey) OUT of tool parameters. Inject them server-side via environment variables or vault. Accept only identifiers (userId) in parameters and resolve credentials server-side.
Add explicit output schemas for every tool. Example for cursor/get-project-state: return {projectPath: string, status: 'ready'|'building'|'failed', lastModified: ISO8601 date, errorMessage?: string}. Document this in the ListTools response or tool description.
Expand tool descriptions to 80-150 characters, answering WHAT (what does it do), WHEN (when to call instead of a similar tool), and WHAT IT RETURNS. E.g., 'Retrieve current build/test status and error details of a project. Call this after create-project or build-project to verify success. Returns {status, lastModified, errorMessage, fileCount}.'
Add detailed parameter descriptions. For projectPath: 'Absolute or relative file system path to the project root. Must contain a package.json or cursor.config.json. If relative, resolved from the server's working directory.' For framework: 'Frontend framework to scaffold: react|vue|svelte|next|nuxt. Required for new projects; ignored if project exists.'
Implement structured error responses with recovery guidance. Instead of {success: false, error: 'Project not found'}, return {success: false, error: 'Project not found at /home/user/my-project', suggestion: 'Try cursor/check-project first to verify the path', isRetryable: false}.
Remove implementation-detail parameters (buildId, promptId, retryCount, isFirstPrompt, isRetry). These should be managed server-side. Simplify cursor/execute-prompt input to just {prompt, projectPath, timeout, context, files, provider}.
Parameter descriptions missing or minimal. 'projectPath' appears in 6 tools with identical minimal description 'Path to the project', no guidance on format (absolute vs relative), validation rules, or what to do if path is invalid.
No error handling guidance. Tool responses return generic JSON with 'success: false' and an error message. No actionable recovery steps (e.g., 'try check-project first', 'retry in 30s', 'this is non-recoverable'). LLMs cannot determine what to do next.
Opaque internal parameters exposed to LLM: buildId, promptId, retryCount, isFirstPrompt, isRetry in cursor/execute-prompt. These are implementation details that should be hidden. LLMs will pass them incorrectly or confuse them with domain parameters.
No tool annotations. cursor/create-project, cursor/execute-prompt, and cursor/build-project are destructive (side-effecting) writes, but lack destructiveHint flag. cursor/get-project-state and cursor/get-files should have readOnlyHint. This prevents agents from reasoning about safety and idempotency.
Enum constraints missing. 'provider' parameter in cursor/execute-prompt has enum ['cursor', 'claude-code'], but many other free-form parameters (framework, packageManager, template, designColorPalette, designPhilosophy) lack constraints. LLMs will hallucinate invalid values.
No pagination or result-limiting guidance. cursor/get-files accepts a pattern parameter but no limit or offset. If a project has thousands of files, the response could explode. No mention of how many files are returned or how to paginate.
Timeout handling is present but not idempotency-safe. cursor/execute-prompt accepts a timeout parameter and has isRetry flag, but no guidance on whether retries after timeout are safe (idempotent) or risk duplicate prompts/side effects.
cursor/execute-prompt
Add tool annotations to every tool. Example: cursor/create-project should have {destructiveHint: true} (creates files). cursor/get-project-state should have {readOnlyHint: true} (read-only). cursor/execute-prompt should have {destructiveHint: true, idempotentHint: false} (side-effecting, not safe to retry blindly).
Convert free-form string parameters to enums where possible. Provide valid framework options (react, vue, next, etc.) as an enum. Provide packageManager as enum (npm, yarn, pnpm). Add designColorPalette enum (primary, secondary, accent, etc.) or link to a design reference endpoint.
Add pagination to cursor/get-files. Introduce parameters limit (default 50, max 500) and offset (default 0). Return {files: [...], total: number, hasMore: boolean, nextOffset: number}. State in description: 'Returns up to 50 files per call to prevent context overflow.'
Document idempotency for cursor/execute-prompt. If the tool is NOT idempotent (retries risk duplicate code generation), state: 'WARNING: Retrying with identical prompt may generate duplicated code changes. Only retry if the first attempt fails before reaching the LLM.' If it IS idempotent, state: 'Safe to retry. Identical prompt on same project will return the same result.'
Add a 'dry-run' or 'preview' mode to cursor/execute-prompt and cursor/build-project. LLMs making mistakes with code generation is expensive. Support preview: true parameter so agents can see what will happen before committing changes.
Document tool chaining paths. After cursor/create-project succeeds, the next tool is likely cursor/execute-prompt. State this dependency in descriptions: 'After calling create-project with projectPath=/home/user/my-app, call execute-prompt with the same projectPath to run the initial setup prompt.'