Skip to main content
Glama

Codemind

by dev.codemindhq.api
OverviewDiscussionsAdmin

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
examplesNoOPTIONAL 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.
projectIdNoOpaque identifier grouping related builds for CIL codebase context — omit to skip CIL entirely.
stackTypeYesRuntime 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.
storyTitleYesShort title used to organize this build.
webhookUrlNoHTTPS URL to POST a signed payload to when the build reaches a terminal state (completed/failed). Must be supplied together with webhookSecret.
skipTestsForNoRepo-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.
existingFilesNoPATCH MODE — pass current content of files being modified. Without this, codegen creates new files instead of editing existing ones.
webhookSecretNoShared 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.
acceptanceCriteriaYesDetailed requirements — function signatures, file paths, edge cases. Used verbatim to generate the implementation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does disclose meaningful traits: the operation is asynchronous (returns a buildId immediately), verification runs against the acceptance criteria before returning, and there is an explicit error-handling contract. It omits the repo side effects (that it writes implementation/test files into the project) and any auth or rate-limit expectations, leaving a gap for a mutating build tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose and workflow in the first sentence, then follow-up routing, then the critical failure-mode warning. Every sentence earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, no-output-schema tool, the description covers the workflow, the immediate return value (buildId), and error behavior, and the schema handles parameter detail. It leaves the eventual build outputs and repo-write side effects to be inferred, which is the only notable gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 9 parameters in depth. The description only restates that it takes a story title plus acceptance criteria, adding no format or constraint detail beyond the schema; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource (generate a feature) and enumerates the pipeline: generate implementation and tests, run checks against acceptance criteria, return a buildId. It clearly distinguishes itself from read siblings like get_build/get_test, but never contrasts itself with the closest build siblings (build_batch, build_from_spec), so it falls short of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit follow-up routing (call stream_build with the returned buildId; call get_usage_guide for details) and a clear failure-mode instruction (surface the error, do NOT implement the code yourself). It never states when to prefer this tool over build_batch or build_from_spec, so no exclusions are offered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Codemind toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources