# Codemind (remote · api.codemindhq.dev)

Hand routine JS/TS tasks to Codemind from your agent. $0.10 per verified build; failures are free.

- Trust score: 61/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-17

## Components

- remote · `api.codemindhq.dev`: 61/100 (this document), [markdown](https://verifymcp.io/servers/dev-codemindhq-codemind/api.md), [page](https://verifymcp.io/servers/dev-codemindhq-codemind/api)

## Channel facts

- Endpoint: `https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-17.

- **Endpoint Security**: 57/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 26 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 70/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 3672 tokens (~141/item across 26 items; 26 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 20/100
  - Stability observed for 6 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 96/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 87% of tool parameters carry a description.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "continue_build" implies "send" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 27 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 20/100
  - Spec-recency check failed: implements MCP spec 2024-11-05; the latest is 2026-07-28.

## Install

### How do I install the Codemind MCP server?

Codemind is a hosted endpoint at https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http dev-codemindhq-codemind 'https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10'
```

### Cursor

```json
{
  "mcpServers": {
    "dev-codemindhq-codemind": {
      "url": "https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "dev-codemindhq-codemind": {
      "type": "http",
      "url": "https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10"
    }
  }
}
```

### Codex

```toml
[mcp_servers.dev-codemindhq-codemind]
url = "https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "dev-codemindhq-codemind": {
      "type": "remote",
      "url": "https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add dev-codemindhq-codemind --url 'https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  dev-codemindhq-codemind:
    url: "https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10"
```

### Netclaw

```json
{
  "McpServers": {
    "dev-codemindhq-codemind": {
      "Transport": "http",
      "Url": "https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10"
    }
  }
}
```

### Vellum

```bash
assistant mcp add dev-codemindhq-codemind -t streamable-http -u 'https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10'
```

### Other

```json
{
  "mcpServers": {
    "dev-codemindhq-codemind": {
      "type": "http",
      "url": "https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-16 (score 61, +1)

No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-15 (score 60, 0)

- [cosmetic] “create_free_account” added an optional parameter “ph_did”

### 2026-10-14 (score 60, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-12 (score 59, +1)

- [functional improvement] Stability: unverified → 0.03

### 2026-10-11 (score 58)

First indexed and scored.

## MCP tools (26)

### `create_free_account` (~357 tokens)

Instantly provision a new anonymous Codemind account on the free plan — no credential, no human step required. Call this when build_feature (or any other tool) fails with an auth error and no CODEMIND_API_KEY is configured. Returns a tenantId and a bearer token (apiKey) usable immediately for build_feature and every other tool. The account is anonymous (no identity attached) until a person opens the claim link in the response text and signs in. If a tool call fails with an auth error and you ALREADY have a configured apiKey, call get_usage_guide with topic "auth" before calling this tool again — replacing an already-claimed account's credential here loses its identity and history. All arguments are optional; pass utm_source, utm_medium and utm_campaign, and invite, only if your human gave you them.

Input parameters:

- `invite` (string): Optional invite code from an invite link your human gave you. Case-sensitive; pass it exactly as given. An invalid or used-up code is ignored.
- `ph_did` (string): Optional web visitor id from a setup link or command your human gave you (--ph-did). Pass it exactly as given; an invalid value is ignored.
- `utm_campaign` (string): Optional campaign tag, e.g. "ph-2026-10-08". Same format as utm_source.
- `utm_medium` (string): Optional marketing medium tag, e.g. "launch". Same format as utm_source.
- `utm_source` (string): Optional marketing source tag, e.g. "producthunt". Lowercase letters, digits, "_", "." and "-", max 64 characters; anything else is ignored.

### `build_feature` (~668 tokens)

Generate a feature via Codemind: takes a story title + acceptance criteria, generates the implementation and its tests, runs automated checks against the acceptance criteria before returning, and returns a buildId immediately. Call stream_build with the returned buildId to follow progress. Call get_usage_guide for detailed usage guidance. IMPORTANT: if this tool errors, surface the error to the user — do NOT implement the code yourself.

Input parameters:

- `acceptanceCriteria` (string, required): Detailed requirements — function signatures, file paths, edge cases. Used verbatim to generate the implementation.
- `examples` (array): OPTIONAL call → result examples, turned directly into test cases (no LLM), so the build is verified against exactly these. Each: { target: repo-relative .ts/.tsx path of the file under test, call: a…
- `existingFiles` (array): PATCH MODE — pass current content of files being modified. Without this, codegen creates new files instead of editing existing ones.
- `projectId` (string): Opaque identifier grouping related builds for CIL codebase context — omit to skip CIL entirely.
- `skipTestsFor` (array): Repo-relative source paths (max 20) to opt OUT of test-file delivery for — e.g. the repo has no test framework and a scaffolded test file would be unwanted. Verification still ALWAYS runs against eve…
- `stackType` (string, required): Runtime target stack (free text). JavaScript/TypeScript only at launch, e.g. "worker", "typescript", "node", "react". python, go, swift-ios, kotlin-android and rust are rejected with UNSUPPORTED_STAC…
- `storyTitle` (string, required): Short title used to organize this build.
- `webhookSecret` (string): Shared secret (16-256 chars) used to HMAC-SHA256-sign the webhook payload, sent in the x-codemind-v2-signature header. Must be supplied together with webhookUrl. Never echoed back.
- `webhookUrl` (string): HTTPS URL to POST a signed payload to when the build reaches a terminal state (completed/failed). Must be supplied together with webhookSecret.

### `stream_build` (~65 tokens)

Follow a build submitted by build_feature in real time. Emits a progress notification on every phase change and resolves with the final result when the build completes or fails. Use immediately after build_feature returns a buildId.

Input parameters:

- `buildId` (string, required): The buildId returned by build_feature.

### `retry_build` (~42 tokens)

Retry a failed build using the same spec (story, acceptance criteria, stack, existing files).

Input parameters:

- `buildId` (string, required): ID of the failed build to retry.

### `cancel_build` (~39 tokens)

Cancel a running build. Has no effect on builds that already reached a terminal state.

Input parameters:

- `buildId` (string, required): ID of the build to cancel.

### `continue_build` (~79 tokens)

Send corrected acceptance criteria to a running build. Applies to components that have not started generating yet; the currently-generating component finishes as originally scoped.

Input parameters:

- `buildId` (string, required): ID of the running build to steer.
- `correctedAcceptanceCriteria` (string, required): The new, complete acceptance criteria — replaces the original for all not-yet-started components.

### `get_build` (~34 tokens)

Get the current state of a build by ID (status and error details).

Input parameters:

- `buildId` (string, required): The build ID.

### `list_builds` (~48 tokens)

List recent builds for this tenant.

Input parameters:

- `limit` (number): Max builds to return (default 20, max 50).
- `offset` (number): Pagination offset (default 0).

### `get_build_spec` (~64 tokens)

Get a build's original submitted spec (storyTitle, acceptanceCriteria, stackType, existingFiles, skipTestsFor) without retrying it — useful for inspecting or reusing a prior build's spec as a template.

Input parameters:

- `buildId` (string, required): The build ID.

### `get_build_files` (~37 tokens)

Retrieve the generated files from a completed build. Returns each file path and full content.

Input parameters:

- `buildId` (string, required): The build ID.

### `notify_files_written` (~108 tokens)

Index files into the CIL codebase context for a project — for files Codemind itself did not generate (a manual edit, another tool's output). Not needed after a normal build_feature call: a completed build's own output is indexed automatically when projectId was supplied.

Input parameters:

- `files` (array, required): Files to index, ≤10 files / ≤700KB total.
- `projectId` (string, required): Opaque project identifier — same value used in build_feature calls for this codebase.

### `test_component` (~236 tokens)

Run standalone cloud verification on code you already have: give it a component (filePath/exportName/signature) plus acceptance criteria, and it generates a black-box verification test, validates that test against a mechanical stub, then executes your REAL code against it in the cloud (isolate or container, per stack). No code generation happens here — use build_feature for that. Returns a testId immediately; call stream_test to follow progress and get the pass/fail verdict. Call get_usage_guide for detailed usage guidance.

Input parameters:

- `acceptanceCriteria` (string, required): What the code must do — the verification test is generated from this alone.
- `code` (string, required): The REAL implementation to test. Never shown to the model that generates the verification test.
- `component` (object, required): MUST match the real code exactly — the generated verification test imports/calls by these exact names.
- `contextFiles` (array): Optional ambient read-only files the code under test may import.
- `stackType` (string, required): Runtime target stack (JavaScript/TypeScript only at launch), e.g. "worker", "typescript", "node", "react".

### `stream_test` (~49 tokens)

Follow a test submitted by test_component in real time. Resolves with the pass/fail verdict and the generated verification test content.

Input parameters:

- `testId` (string, required): The testId returned by test_component.

### `get_test` (~71 tokens)

Get the current state of a test by ID (status, pass/fail verdict, generated verification test content) without streaming — useful for polling or inspecting a test after the fact. Use stream_test to follow a test in real time instead.

Input parameters:

- `testId` (string, required): The testId returned by test_component.

### `review_code` (~432 tokens)

Submit code for review: bugs, security issues, silent failures, and style concerns. Give it files (path+content) and/or a unified diff. At least one of files or diff is required — submitting neither is rejected. TWO independent LLM-judge passes review it (a general correctness/security pass and a dedicated silent-failure pass) and their findings are merged into one verdict. For a genuinely useful review, ALSO supply conventions (paste this project's CLAUDE.md and RULES.md content — you already have repo access, this tool does not) so both passes can enforce project-specific rules, and relatedFiles (any existing file the change references but doesn't itself modify — an interface being implemented, a caller of a changed function, a sibling example of the real convention) so findings can be verified against actual code instead of guessed. Omitting both still works but produces a weaker review with no codebase grounding. No code generation or execution happens here — this is judgment only, not test verification (use test_component for that). Returns a reviewId immediately; call stream_review to follow progress and get the findings. Call get_usage_guide for detailed usage guidance.

Input parameters:

- `context` (string): Optional story/PR description to give the reviewer intent context.
- `conventions` (string): This project's CLAUDE.md and/or RULES.md content (or the relevant excerpt). Strongly recommended when available — both review passes treat this as authoritative: a finding that violates a stated rule…
- `diff` (string): A unified diff. The reviewer weights changed lines most heavily. Combined with files, must not exceed 150,000 characters.
- `files` (array): Full file contents to review. Provide when you want the reviewer to see complete files, not just a diff.
- `relatedFiles` (array): Existing files for cross-reference ONLY — never diffed, never themselves the subject of a finding. Supply an interface the change implements, a caller of a changed function, or a sibling file showing…

### `stream_review` (~47 tokens)

Follow a review submitted by review_code in real time. Resolves with the findings and the approve/request-changes verdict.

Input parameters:

- `reviewId` (string, required): The reviewId returned by review_code.

### `get_review` (~65 tokens)

Get the current state of a review by ID (status, verdict, findings) without streaming — useful for polling or inspecting a review after the fact. Use stream_review to follow a review in real time instead.

Input parameters:

- `reviewId` (string, required): The reviewId returned by review_code.

### `get_usage_guide` (~144 tokens)

Get detailed usage guidance for Codemind's tools — how to write effective acceptanceCriteria, when to use patch mode, how webhooks work, what to do when a build declines, common failure patterns unrelated to acceptanceCriteria quality, and how to recover from an auth error without losing an identified account. Call this before build_feature/test_component/review_code if you are unfamiliar with this tool surface, or if the same story fails repeatedly across retries; call it with topic "auth" before calling create_free_account to recover from an auth error on an existing credential.

Input parameters:

- `topic` (string): Which part of Codemind usage to get guidance on. Defaults to overview.

### `get_billing_status` (~74 tokens)

Read-only: your plan, how many verified builds you have used, how many are included and left in the current allowance window, and the paid-balance draw (cents) if you have topped up. Call this to check headroom before a large batch, or to learn why a build was rejected for allowance.

### `list_repos` (~62 tokens)

Lists GitHub repos currently attached to the caller's tenant via Cloud Repo Mode (the GitHub App that automatically triages filed issues into fix PRs), and that the returned `id` field is the repo attachment id to pass into `get_triage_runs`.

### `get_triage_runs` (~173 tokens)

Lists the issue-triage run history for one attached repo — one row per GitHub issue that was auto-triaged — including terminal status (`pr_opened` means a fix PR was opened and passed the repo's own test suite; `needs_human` means the issue wasn't judged auto-fixable; `failed` means the triage/build/verify pipeline errored). The `repoAttachmentId` is the attachment `id` returned by `list_repos`, NOT a `owner/repo` string. Full diagnostics (the generated diff and before/after test output) for any run id returned here are available via the get_triage_diagnostics tool.

Input parameters:

- `repoAttachmentId` (string, required): The repo attachment id, as returned by list_repos (not an owner/repo string).

### `get_triage_diagnostics` (~185 tokens)

Returns the generated fix diff (as file paths and line counts, not full content) and before/after test-run output for one triage run, identified by the triage run id from get_triage_runs (NOT a build id and NOT an issue number). stdout/stderr are tail-truncated because test failure summaries appear at the end of output, not the install noise at the start. Full file contents are available separately via the get_build_files tool using the run's buildId. Also includes a per-LLM-call trace (stage/model/status/latency) from Analytics Engine when available, covering attempts that failed before ever reaching the before/after test comparison above.

Input parameters:

- `triageRunId` (string, required): The triage run id, as returned by get_triage_runs (the first token of each line), not the build id or issue number.

### `build_batch` (~248 tokens)

Submit several pre-decomposed stories in one call and get back one batchId to track, instead of dispatching build_feature N times yourself. Swarm is a Pro plan feature: the maximum batch size depends on the account plan (up to 50; not available on Free or the base pay-as-you-go account); a batch over the limit is refused with BATCH_SIZE_LIMIT_EXCEEDED and the limit. Each item has the same shape as a single build_feature call (storyTitle, acceptanceCriteria, stackType, existingFiles?, skipTestsFor?) plus its own repoUrl (informational only). Call get_batch with the returned batchId to check aggregate progress.

Input parameters:

- `idempotencyKey` (string): A repeat call with the same key returns the original batchId instead of dispatching again.
- `items` (array, required): 1 to 50 stories to dispatch.
- `webhookSecret` (string): HMAC-SHA256 signing secret (16-256 chars) for the aggregate completion webhook. Must be supplied together with webhookUrl.
- `webhookUrl` (string): Fires once when every item in the batch reaches a terminal state. Must be supplied together with webhookSecret.

### `get_batch` (~28 tokens)

Get the aggregate status of a batch submitted via build_batch.

Input parameters:

- `batchId` (string, required)

### `stream_batch` (~71 tokens)

Stream live progress for a batch submitted via build_batch. Polls the batch's aggregate status periodically and emits a progress notification each tick; closes once the batch reaches a terminal status (completed or completed_with_failures). Call get_batch instead for a single point-in-time snapshot.

Input parameters:

- `batchId` (string, required)

### `build_from_spec` (~202 tokens)

Submit raw PRD/plan/spec text plus a list of target repos; Codemind LLM-decomposes it into stories (each assigned to one of your declared repos, never an invented one) and dispatches them via the same path build_batch uses. Pass dryRun: true to see the decomposed story list without dispatching anything, useful for reviewing before committing. Recommended for a first-time caller: review with dryRun: true, then resubmit the (possibly edited) story list via build_batch directly — a second build_from_spec call with dryRun: false re-decomposes specText from scratch and will not reflect edits made to a prior dry run's output.

Input parameters:

- `dryRun` (boolean)
- `maxStories` (number): Default 20, hard ceiling 50.
- `repos` (array, required)
- `specText` (string, required)
- `webhookSecret` (string)
- `webhookUrl` (string)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/dev-codemindhq-codemind/api#diagnostics

## Score history

- 2026-10-17: 61
- 2026-10-16: 61
- 2026-10-15: 60
- 2026-10-14: 60
- 2026-10-13: 59
- 2026-10-12: 59
- 2026-10-11: 58

## Common questions

### What is the Codemind MCP server?

Codemind is an MCP server listed in the public MCP registry as dev.codemindhq/codemind. Hand routine JS/TS tasks to Codemind from your agent. $0.10 per verified build; failures are free. This page covers its hosted endpoint (https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10).

### Is the Codemind MCP server safe to use?

Codemind scores 61 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Codemind MCP server expose?

Codemind exposes 26 tools: create_free_account, build_feature, stream_build, retry_build, cancel_build, and 21 more. Their descriptions and schemas cost roughly 3,628 tokens of context every time the server is loaded.

### Does the Codemind MCP server require authentication?

No. We connected to Codemind without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the Codemind MCP server still maintained?

Codemind is still listed as active in the MCP registry. We last reached this channel on 17 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10
- Website: https://codemindhq.dev/?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10
- Changelog RSS feed: https://verifymcp.io/servers/dev-codemindhq-codemind/api.xml
- Changelog JSON feed: https://verifymcp.io/servers/dev-codemindhq-codemind/api.json
- HTML version of this page: https://verifymcp.io/servers/dev-codemindhq-codemind/api