Build Your First Feature with Codapult MCP

This workflow uses MCP as a project-aware development surface. The assistant reads the current project context first, proposes a bounded change, uses the generator where it fits, and runs the repository checks before you review the diff.

1. Connect MCP

The generated .cursor/mcp.json starts the published CLI server:

{
  "mcpServers": {
    "codapult": {
      "command": "npx",
      "args": ["-y", "@codapult/cli@latest", "mcp-server"],
      "cwd": "."
    }
  }
}

Verify the connection from the project root:

npx @codapult/cli mcp doctor

2. Start with context, not a file path

Ask the assistant to inspect the active providers, enabled features, schema, and conventions:

Read the Codapult project context and current Git diff. I want to add saved reports for organization members. Identify the existing auth, organization, database, navigation, and testing patterns. Do not edit files yet.

This matters because a Codapult project can remove modules during setup and can use different providers. The correct implementation depends on the project that is actually present.

3. Generate the smallest boundary

For a dashboard feature, the CLI generator creates an authenticated server page:

npx @codapult/cli generate page reports

For an API boundary or server action, use:

npx @codapult/cli generate api reports
npx @codapult/cli generate action reports

The generators provide a safe starting shape with authentication, rate limiting, or input validation. Connect that starting shape to the product's business behavior by asking MCP to inspect the generated files and follow the existing service, schema, and navigation conventions.

4. Ask for an implementation plan

Using the generated reports boundary, propose the schema, organization-scoped query, server action, dashboard UI, and tests. Reuse existing components and keep the first change limited to listing and creating reports. Show the files you will change before editing.

Prefer one source of truth for validation and provider behavior. Keep organization scope in the data access path, not only in the page UI.

5. Verify the result

Run the relevant type-check, lint, and tests for the reports feature. Then run Codapult Doctor and report any schema, environment, or provider mismatch. Do not hide warnings or change unrelated files.

You can also run the checks directly:

pnpm type-check
pnpm test
npx @codapult/cli doctor

If the feature changes the database, inspect the generated schema diff and migration plan before applying it with pnpm db:push or the project's migration workflow.

MCP boundaries

MCP reads the local project and can execute configured project commands. Use it alongside code review, database backups, provider staging tests, and deliberate mutation decisions. Treat generated code as a typed starting point and review the final diff like any other change.