dev.codemindhq/codemind

Est-ce que dev.codemindhq/codemind est sûr ?

Au dernier audit MCP Hub, le serveur MCP « dev.codemindhq/codemind » est classé « Non encore testé ». Référencé dans l'annuaire. Seul le pentest comportemental fait foi, et il n'a pas encore été exécuté sur ce serveur. Le verdict est réévalué en continu ; consultez la fiche pour l'état à jour.

Méthode : MCP Hub analyse la description de chaque outil (couche 1) et, pour le verdict fort, exécute le serveur dans une micro-VM isolée avec leurres et réseau bloqué (couche 2). On publie des noms et des compteurs, jamais le contenu brut renvoyé par un outil.

Les 27 outils

• build_batch≈ 779 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.

  Paramètres, retour & exemple (4)

  Paramètres

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

  Exemple d'appel

  {"name": "build_batch", "arguments": {"items": []}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• build_feature≈ 1357 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.

  Paramètres, retour & exemple (9)

  Paramètres

  • examples · array · optionnel
    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 TS expression such as "clamp(5, 0, 10)", imports?: export names the call uses (default: the component's main export), expected?: JSON value (compared with toEqual) OR throws?: error class name such as "RangeError", async?: true when the call returns a promise }. Exactly one of expected / throws per example; max 50. expected is JSON, so undefined, NaN, -0 and Dates cannot be expressed; describe those in acceptanceCriteria instead. For a new file every example must fail before the implementation exists; in patch mode at least one must fail against the current file (the rest act as regression guards). Only .ts/.tsx targets are supported.
  • projectId · string · optionnel
    Opaque identifier grouping related builds for CIL codebase context — omit to skip CIL entirely.
  • stackType · string · requis
    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_STACK_TYPE until each has measured success.
  • storyTitle · string · requis
    Short title used to organize this build.
  • webhookUrl · string · optionnel
    HTTPS URL to POST a signed payload to when the build reaches a terminal state (completed/failed). Must be supplied together with webhookSecret.
  • skipTestsFor · array · optionnel
    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 every component regardless of this setting — it only filters which files are DELIVERED to you, never whether verification happens. If the target project has NO test infrastructure at all, the build will very likely still fail even with this set — there is currently no fallback verification mode (e.g. typecheck-only) for that case. Explicit opt-in only, never infer from acceptanceCriteria prose.
  • existingFiles · array · optionnel
    PATCH MODE — pass current content of files being modified. Without this, codegen creates new files instead of editing existing ones.
  • webhookSecret · string · optionnel
    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.
  • acceptanceCriteria · string · requis
    Detailed requirements — function signatures, file paths, edge cases. Used verbatim to generate the implementation.

  Exemple d'appel

  {"name": "build_feature", "arguments": {"stackType": "texte", "storyTitle": "texte", "acceptanceCriteria": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• build_from_spec≈ 590 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.

  Paramètres, retour & exemple (7)

  Paramètres

  • repos · array · requis
  • dryRun · boolean · optionnel
  • deliver · string · optionnel · pull_request
    Opt in to delivery: when every story has finished, open one pull request per target repo (a draft if any story did not verify or the repo's own tests newly fail). Needs the repo attached through the GitHub App; an unattached repo is reported with nextAction attach_repo and its files stay available from get_build_files. Never merged automatically. Results appear under deliveries in get_batch.
  • specText · string · requis
  • maxStories · number · optionnel
    Default 20, hard ceiling 50.
  • webhookUrl · string · optionnel
  • webhookSecret · string · optionnel

  Exemple d'appel

  {"name": "build_from_spec", "arguments": {"repos": [], "specText": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• cancel_build≈ 70 tokens

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

  Paramètres, retour & exemple (1)

  Paramètres

  • buildId · string · requis
    ID of the build to cancel.

  Exemple d'appel

  {"name": "cancel_build", "arguments": {"buildId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• continue_batch≈ 176 tokens

  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.

  Paramètres, retour & exemple (1)

  Paramètres

  • batchId · string · requis

  Exemple d'appel

  {"name": "continue_batch", "arguments": {"batchId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• continue_build≈ 146 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.

  Paramètres, retour & exemple (2)

  Paramètres

  • buildId · string · requis
    ID of the running build to steer.
  • correctedAcceptanceCriteria · string · requis
    The new, complete acceptance criteria — replaces the original for all not-yet-started components.

  Exemple d'appel

  {"name": "continue_build", "arguments": {"buildId": "texte", "correctedAcceptanceCriteria": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• create_free_account≈ 437 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.

  Paramètres, retour & exemple (5)

  Paramètres

  • invite · string · optionnel
    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 · optionnel
    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_medium · string · optionnel
    Optional marketing medium tag, e.g. "launch". Same format as utm_source.
  • utm_source · string · optionnel
    Optional marketing source tag, e.g. "producthunt". Lowercase letters, digits, "_", "." and "-", max 64 characters; anything else is ignored.
  • utm_campaign · string · optionnel
    Optional campaign tag, e.g. "ph-2026-10-08". Same format as utm_source.

  Exemple d'appel

  {"name": "create_free_account", "arguments": {"invite": "texte", "ph_did": "texte", "utm_medium": "texte", "utm_source": "texte", "utm_campaign": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• get_batch≈ 52 tokens

  Get the aggregate status of a batch submitted via build_batch.

  Paramètres, retour & exemple (1)

  Paramètres

  • batchId · string · requis

  Exemple d'appel

  {"name": "get_batch", "arguments": {"batchId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• get_billing_status≈ 96 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.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "get_billing_status", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• get_build≈ 61 tokens

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

  Paramètres, retour & exemple (1)

  Paramètres

  • buildId · string · requis
    The build ID.

  Exemple d'appel

  {"name": "get_build", "arguments": {"buildId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• get_build_files≈ 70 tokens

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

  Paramètres, retour & exemple (1)

  Paramètres

  • buildId · string · requis
    The build ID.

  Exemple d'appel

  {"name": "get_build_files", "arguments": {"buildId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• get_build_spec≈ 96 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.

  Paramètres, retour & exemple (1)

  Paramètres

  • buildId · string · requis
    The build ID.

  Exemple d'appel

  {"name": "get_build_spec", "arguments": {"buildId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• get_review≈ 102 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.

  Paramètres, retour & exemple (1)

  Paramètres

  • reviewId · string · requis
    The reviewId returned by review_code.

  Exemple d'appel

  {"name": "get_review", "arguments": {"reviewId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• get_test≈ 108 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.

  Paramètres, retour & exemple (1)

  Paramètres

  • testId · string · requis
    The testId returned by test_component.

  Exemple d'appel

  {"name": "get_test", "arguments": {"testId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• get_triage_diagnostics≈ 238 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.

  Paramètres, retour & exemple (1)

  Paramètres

  • triageRunId · string · requis
    The triage run id, as returned by get_triage_runs (the first token of each line), not the build id or issue number.

  Exemple d'appel

  {"name": "get_triage_diagnostics", "arguments": {"triageRunId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• get_triage_runs≈ 210 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.

  Paramètres, retour & exemple (1)

  Paramètres

  • repoAttachmentId · string · requis
    The repo attachment id, as returned by list_repos (not an owner/repo string).

  Exemple d'appel

  {"name": "get_triage_runs", "arguments": {"repoAttachmentId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• get_usage_guide≈ 228 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.

  Paramètres, retour & exemple (1)

  Paramètres

  • topic · string · optionnel · overview | patch-mode | webhooks | error-handling | common-failures | auth | cloud-swarm
    Which part of Codemind usage to get guidance on. Defaults to overview.

  Exemple d'appel

  {"name": "get_usage_guide", "arguments": {"topic": "overview"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• list_builds≈ 74 tokens

  List recent builds for this tenant.

  Paramètres, retour & exemple (2)

  Paramètres

  • limit · number · optionnel
    Max builds to return (default 20, max 50).
  • offset · number · optionnel
    Pagination offset (default 0).

  Exemple d'appel

  {"name": "list_builds", "arguments": {"limit": 1, "offset": 1}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• list_repos≈ 84 tokens

  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`.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_repos", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• notify_files_written≈ 212 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.

  Paramètres, retour & exemple (2)

  Paramètres

  • files · array · requis
    Files to index, ≤10 files / ≤700KB total.
  • projectId · string · requis
    Opaque project identifier — same value used in build_feature calls for this codebase.

  Exemple d'appel

  {"name": "notify_files_written", "arguments": {"files": [], "projectId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• retry_build≈ 73 tokens

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

  Paramètres, retour & exemple (1)

  Paramètres

  • buildId · string · requis
    ID of the failed build to retry.

  Exemple d'appel

  {"name": "retry_build", "arguments": {"buildId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• review_code≈ 658 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.

  Paramètres, retour & exemple (5)

  Paramètres

  • diff · string · optionnel
    A unified diff. The reviewer weights changed lines most heavily. Combined with files, must not exceed 150,000 characters.
  • files · array · optionnel
    Full file contents to review. Provide when you want the reviewer to see complete files, not just a diff.
  • context · string · optionnel
    Optional story/PR description to give the reviewer intent context.
  • conventions · string · optionnel
    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 here is always blocking.
  • relatedFiles · array · optionnel
    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 the project's real convention, so the reviewer can verify claims against real code instead of guessing.

  Exemple d'appel

  {"name": "review_code", "arguments": {"diff": "texte", "files": [], "context": "texte", "conventions": "texte", "relatedFiles": []}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• stream_batch≈ 112 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.

  Paramètres, retour & exemple (1)

  Paramètres

  • batchId · string · requis

  Exemple d'appel

  {"name": "stream_batch", "arguments": {"batchId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• stream_build≈ 110 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.

  Paramètres, retour & exemple (1)

  Paramètres

  • buildId · string · requis
    The buildId returned by build_feature.

  Exemple d'appel

  {"name": "stream_build", "arguments": {"buildId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• stream_review≈ 83 tokens

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

  Paramètres, retour & exemple (1)

  Paramètres

  • reviewId · string · requis
    The reviewId returned by review_code.

  Exemple d'appel

  {"name": "stream_review", "arguments": {"reviewId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• stream_test≈ 85 tokens

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

  Paramètres, retour & exemple (1)

  Paramètres

  • testId · string · requis
    The testId returned by test_component.

  Exemple d'appel

  {"name": "stream_test", "arguments": {"testId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• test_component≈ 550 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.

  Paramètres, retour & exemple (5)

  Paramètres

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

  Exemple d'appel

  {"name": "test_component", "arguments": {"code": "texte", "component": {}, "stackType": "texte", "acceptanceCriteria": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

C'est votre serveur ?

Revendiquez-le sur l'espace créateur (preuve GitHub, domaine ou npm) pour afficher le badge « propriétaire vérifié » et lancer un pentest comportemental à la demande afin d'obtenir le badge « Vérifié ».

Créer un compte / revendiquer →

Source

https://api.codemindhq.dev/mcp?utm_source=mcp-registry&utm_medium=directory&utm_campaign=registry-2026-10-10