Skip to main content
Glama

scaffold_test

Generate a pending test stub from a post-incident lesson to document behavioural mistakes. The stub carries incident provenance and returns the sensor arming command.

Instructions

Generate a PENDING post-incident test from a lesson (attempt/gotcha) — the on-ramp to a command sensor. A command sensor routes YOUR test as its oracle, but someone has to write it; this writes the skeleton so you only fill in the assertion.

USE THIS right after mem_tried when the mistake is behavioural (a regex can't express it): it writes a stub carrying the incident's provenance and returns the exact sensors propose --kind test command to arm it.

It DOES NOT arm a sensor — propose_sensor stays the sole validated writer, and the stub is left PENDING (todo/skip) so the suite stays green until you write the assertion. Monorepo-aware: the framework and location come from the package that owns the lesson's anchor paths.

PARAMETERS: memory_id — the attempt/gotcha to scaffold from framework — vitest | jest | pytest | gotest (auto-detected when omitted) out_path — override the test file path (repo-relative) write — write the file (default true); false returns the content for preview

RETURNS: { ok, path, run_command, propose_command, content, written, already_exists, notice }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
styleNoTest shape (default 'example'): 'property' states the invariant once and checks it over many generated inputs (fast-check/Hypothesis); 'differential' asserts the subject agrees with a `reference` implementation for all inputs. Both lower the cost of expressing the invariant.
writeNoWrite the file to disk (default). false = return the content for preview without writing.
red_refNoPre-fix incident commit/ref. When set, the scaffold names the symbols the fix (<red_ref>..HEAD) touched within the lesson's anchor scope and pre-fills the example around them, so the assertion is a targeted edit rather than a blank page. A bad ref falls back to the generic template.
out_pathNoOverride the generated test file path (repo-relative).
frameworkNoTest framework. Auto-detected from the package that owns the lesson's anchor paths when omitted.
memory_idYesId of the attempt/gotcha lesson to scaffold a post-incident test from.
referenceNoRequired for style='differential': import specifier of the reference implementation to compare against.
Behavior4/5

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

Despite having no annotations, the description discloses key behaviors: it produces a PENDING stub, does not arm a sensor, keeps the suite green, and is monorepo-aware. It also notes the dry-run 'write' parameter behavior. However, it doesn't discuss potential errors or overwrite semantics, so a 4 rather than 5.

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?

The description is well-structured: a clear opening sentence, a bolded usage directive, a non-goal clarification, and a concise parameter summary. It is longer than a single sentence but every line adds value; the only slight redundancy is repeating 'framework auto-detected' which already exists in the schema.

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?

The description covers the tool's role, its place relative to propose_sensor, the pending-test behavior, and the return shape. It leaves out explanation of the 'style' and 'red_ref' parameters, but those are fully defined in the schema, so the agent can rely on the schema. Given no output schema, the return field list could be more detailed, but it's sufficient.

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?

The input schema already documents all 7 parameters at 100% coverage, so the baseline is 3. The description adds only a brief list of four key params and some narrative around their purpose, but does not add meaning beyond the schema for the omitted ones (style, red_ref, reference). It does reinforce that framework auto-detects and write has a preview mode, matching the schema.

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 opens with 'Generate a PENDING post-incident test from a lesson (attempt/gotcha)' — a specific verb, resource, and state. It also distinguishes from propose_sensor by explicitly stating it does NOT arm a sensor, making its scope unambiguous.

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?

The description provides explicit when-to-use guidance ('USE THIS right after mem_tried when the mistake is behavioural') and a clear exclusion ('It DOES NOT arm a sensor — propose_sensor stays the sole validated writer'). This gives an agent clear decision criteria among siblings.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Doucs91/hivelore'

If you have feedback or need assistance with the MCP directory API, please join our Discord server