Skip to main content
Glama
Sign In

Codemind

by dev.codemindhq
OverviewDiscussionsAdmin

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.

Input Schema

NameRequiredDescriptionDefault
reposYes
dryRunNo
deliverNoOpt 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.
specTextYes
maxStoriesNoDefault 20, hard ceiling 50.
webhookUrlNo
webhookSecretNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / repos / items / properties / existingFiles / description
      Previous value: -"OPTIONAL current contents of this repo's files that the spec changes or depends on ({path, content}). Every story for this repo is built with them (a file whose path the story names is edited, the rest are read-only context). With deliver, Ship only overwrites an existing file that is supplied here AND still has exactly this content in the repo at delivery; any other existing file is never overwritten."New value: +"OPTIONAL current contents of this repo's files that the spec changes or depends on ({path, content}). With deliver and the repo attached through the GitHub App you can omit this: Ship reads the files each story names, plus their local imports, from the repo itself. Every story for this repo is built with them (a file whose path the story names is edited, the rest are read-only context). With deliver, Ship only overwrites an existing file that is supplied here AND still has exactly this content in the repo at delivery; any other existing file is never overwritten."
  2. Changed1 schema field changed
    • addedInput schema / properties / repos / items / properties / existingFiles
      Added value: +{
+  "description": "OPTIONAL current contents of this repo's files that the spec changes or depends on ({path, content}). Every story for this repo is built with them (a file whose path the story names is edited, the rest are read-only context). With deliver, Ship only overwrites an existing file that is supplied here AND still has exactly this content in the repo at delivery; any other existing file is never overwritten.",
+  "items": {
+    "properties": {
+      "content": {
+        "type": "string"
+      },
+      "path": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "path",
+      "content"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / deliver
      Added value: +{
+  "description": "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.",
+  "enum": [
+    "pull_request"
+  ],
+  "type": "string"
+}
  4. First observed

TDQS

A4.3/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 delivers real behavioral detail: LLM decomposition, the repo-assignment invariant, dispatch parity with build_batch, and the dry-run non-persistence semantics. It stops short of disclosing auth requirements or the delivery flow (deliver is covered in the schema), so it is strong but not exhaustive.

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

Conciseness4/5

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

Purpose is front-loaded in the first sentence and every sentence carries operational content, but the final sentence about re-decomposition is dense and slightly convoluted. No wasted filler, though it could be tightened.

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 7-parameter tool with no annotations and no output schema, the description covers the core call flow well and the schema fills in deliver, maxStories, and existingFiles. Remaining gaps are the webhook parameters and any auth prerequisites, which keeps it short of a 5.

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 only 29%, so the description must compensate more than it does. It meaningfully explains dryRun and the repos/repo-assignment semantics, but webhookUrl, webhookSecret, and hint receive no explanation anywhere, leaving several parameters underspecified.

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

Purpose5/5

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

The description gives a specific verb and resource – submit raw spec text, decompose it into stories, and dispatch them – and explicitly ties the dispatch to the same path build_batch uses. It also states a distinguishing scope rule (each story assigned to a declared repo, never invented), so an agent can separate it from build_batch without opening either schema.

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

Usage Guidelines5/5

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

It prescribes exactly when to use dryRun, names the alternative (build_batch) for committing an edited story list, and warns that a second build_from_spec call re-decomposes from scratch. This is explicit when/when-not/alternative guidance rather than implied usage.

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