# Codemind

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

- name: dev.codemindhq/codemind
- version: 1.0.0
- connection class: R0 (autonomous)
- trust: 82/100 flags: no-repository
- quality: 76/100 (good)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/dev.codemindhq%2Fcodemind
- tools: https://api.protogrid.dev/v1/servers/dev.codemindhq%2Fcodemind/tools

**An agent can connect right now, no human step.** Remote endpoint, no authentication, reachable on the last probe.

## Connection (mcpServers)

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


## Trust

- hygiene: 80
- liveness: 99
- freshness: 100
- provenance: 55
- drivers: +dns-namespace +website +reachable +uptime-97% +updated-10d-ago -no-repository
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 76/100 (good)

### protocol: 75 (weight 25)

- warn `protocol.modern`: newest supported version is 2024-11-05; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
- n/a `protocol.stateless`: only applies to 2026-07-28 servers
- pass `protocol.transport`: streamable HTTP
- n/a `protocol.list_ttl`: only applies to 2026-07-28 servers

### authorization: n/a (weight 15)

- n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth
- n/a `auth.secret_in_url`: no templated URL

### tool hygiene: 64 (weight 30)

- pass `tools.descriptions`: every tool has a description
- warn `tools.description_length`: 1 tools have descriptions over 1,024 characters, which crowds the context
- pass `tools.schemas`: every tool has an object input schema
- fail `tools.annotations`: no tool declares readOnlyHint or destructiveHint, so clients cannot tell safe calls from risky ones
- fail `tools.directory_hints`: no tool declares all four of readOnlyHint, destructiveHint, idempotentHint and openWorldHint; missing: get_build_files (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); get_build (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); build_feature (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); …
- pass `tools.token_cost`: about 6,401 tokens to load every tool
- pass `tools.api_dump`: tools are not a one-to-one API dump

### stability: 100 (weight 15)

- pass `stability.changes`: 5 tool changes in 30 days
- pass `stability.rug_pull`: no tool changed its meaning under the same name

### dependencies: n/a (weight 15)

- n/a `deps.known_vulns`, `deps.mcp_sdk_version`, `deps.resolvable`: no npm or PyPI package

- tools: 27, about 6,401 tokens to load them all
- tool set hash: e7cbae96e2444849afd2532a3a50b215
- tools last changed: 2026-10-19T09:12:13.200Z
- badge: [![protogrid quality](https://protogrid.dev/badge/dev.codemindhq/codemind.svg)](https://protogrid.dev/servers/dev.codemindhq/codemind)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

- 2026-10-19 `build_from_spec` changed (inputSchema)
- 2026-10-19 `continue_batch` added
  - Resume a finished Ship run (started with build_from_spec) that ended incomplete or nothing_delivered: re-dispatches only the stories that did not verify, in the same run. Verified stories are not rebuilt or billed again; a resumed story is billed once, when it first verifies. Each resumed story is told why its earlier attempt failed. At most 2 resumes per run (then RESUME_LIMIT_EXCEEDED). The same throttle, plan cap and allowance apply as for a new submission. Resuming a run with nothing left to do changes nothing. Track progress with get_batch.
- 2026-10-17 `list_repos` changed (description)
  - before: 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`.
  - after: Lists GitHub repos currently attached to the caller's tenant via Codemind Resolve (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`.
- 2026-10-15 `create_free_account` changed (inputSchema)
- 2026-10-11 `get_billing_status` added
  - 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.

Full history: https://api.protogrid.dev/v1/servers/dev.codemindhq%2Fcodemind/changes

## Remotes

- https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10 (streamable-http, auth none, reachable true, uptime30d 0.974359)

## Packages

_none_

## Tools (27)

- `build_batch`: 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.
- `build_feature`: 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.
- `build_from_spec`: 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.
- `cancel_build`: Cancel a running build. Has no effect on builds that already reached a terminal state.
- `continue_batch`: Resume a finished Ship run (started with build_from_spec) that ended incomplete or nothing_delivered: re-dispatches only the stories that did not verify, in the same run. Verified stories are not rebuilt or billed again; a resumed story is billed once, when it first verifies. Each resumed story is told why its earlier attempt failed. At most 2 resumes per run (then RESUME_LIMIT_EXCEEDED). The same throttle, plan cap and allowance apply as for a new submission. Resuming a run with nothing left to do changes nothing. Track progress with get_batch.
- `continue_build`: 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.
- `create_free_account`: 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.
- `get_batch`: Get the aggregate status of a batch submitted via build_batch.
- `get_billing_status`: 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.
- `get_build`: Get the current state of a build by ID (status and error details).
- `get_build_files`: Retrieve the generated files from a completed build. Returns each file path and full content.
- `get_build_spec`: 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.
- `get_review`: 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.
- `get_test`: 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.
- `get_triage_diagnostics`: 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.
- `get_triage_runs`: 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.
- `get_usage_guide`: 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.
- `list_builds`: List recent builds for this tenant.
- `list_repos`: Lists GitHub repos currently attached to the caller's tenant via Codemind Resolve (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`.
- `notify_files_written`: 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.
- `retry_build`: Retry a failed build using the same spec (story, acceptance criteria, stack, existing files).
- `review_code`: 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.
- `stream_batch`: 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.
- `stream_build`: 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.
- `stream_review`: Follow a review submitted by review_code in real time. Resolves with the findings and the approve/request-changes verdict.
- `stream_test`: Follow a test submitted by test_component in real time. Resolves with the pass/fail verdict and the generated verification test content.
- `test_component`: 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.