Skip to main content
Glama
lockstep-team-agent

lockstep

by lockstep-team-agent
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

propose_decision

Propose a decision for a scope—rule, architecture, or principle—with rationale, rejected alternatives, and review date. Uses version checks to prevent conflicting updates.

Instructions

Propose a decision (rule, architecture or principle) for a scope, with optional rationale, rejected alternatives and review date. Uses optimistic concurrency: baseVersion must equal the decision's current version (0 for a new decision), otherwise the call fails with a conflict. Owner-scoped decisions bind immediately; shared or cross-cutting ones stay open until acknowledged.

Input Schema

NameRequiredDescriptionDefault
reviewAtNoISO date when the decision should be revisited, for example 2026-12-01. An invalid date is rejected.
ruleTextYesThe decision itself, stated as a clear rule others can follow.
scopeRefYesIdentifier within that kind, for example http:POST /session for a surface, a repo name, or a topic name.
rationaleNoWhy, in one or two sentences (the ADR context).
scopeKindYesWhat kind of thing the decision is about. Kinds used by the ledger are surface, repo, topic, project, capability, shared and contract; the value is not validated here.
baseVersionYesCurrent version of the decision for this scope, or 0 when proposing a new one. A stale value fails with a conflict; read decisions first to get it.
alternativesNoOptions considered and rejected, one string each.
decisionTypeNoKind of decision. Defaults to rule when omitted.
capabilityRefNoCapability or feature reference to attach. Defaults to the one set with set_feature_context.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.1.3
    • addedInput schema / properties / alternatives / description
      Added value: +"Options considered and rejected, one string each."
    • addedInput schema / properties / baseVersion / description
      Added value: +"Current version of the decision for this scope, or 0 when proposing a new one. A stale value fails with a conflict; read decisions first to get it."
    • addedInput schema / properties / capabilityRef / description
      Added value: +"Capability or feature reference to attach. Defaults to the one set with set_feature_context."
    • addedInput schema / properties / decisionType / description
      Added value: +"Kind of decision. Defaults to rule when omitted."
    • addedInput schema / properties / rationale / description
      Added value: +"Why, in one or two sentences (the ADR context)."
    • addedInput schema / properties / reviewAt / description
      Added value: +"ISO date when the decision should be revisited, for example 2026-12-01. An invalid date is rejected."
    • addedInput schema / properties / ruleText / description
      Added value: +"The decision itself, stated as a clear rule others can follow."
    • addedInput schema / properties / scopeKind / description
      Added value: +"What kind of thing the decision is about. Kinds used by the ledger are surface, repo, topic, project, capability, shared and contract; the value is not validated here."
    • addedInput schema / properties / scopeRef / description
      Added value: +"Identifier within that kind, for example http:POST /session for a surface, a repo name, or a topic name."
  2. First observedv0.1.0

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 does well: it discloses optimistic concurrency, the explicit conflict failure mode, and the binding semantics that differ by scope kind. It stops short of stating permissions/auth needs or what the proposal returns on success.

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?

Three tight sentences with no filler; the core action comes first, followed by the concurrency constraint and the lifecycle consequence. Every sentence carries information an agent needs.

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 mutation tool with no output schema and no annotations, it covers the risky parts well (versioning, conflicts, binding). The main gap is that nothing is said about what a successful call yields (identifier, resulting version), which an agent may need to follow up.

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 each of the 9 parameters is already documented, including baseVersion's conflict behavior and capabilityRef's default. The description adds only the version-conflict angle already echoed in the schema, so baseline 3 applies.

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?

States a specific verb and resource ('Propose a decision') and enumerates the decision types (rule, architecture, principle) plus the scope it applies to. It is clearly distinguishable from read-side siblings like decisions/check_decisions, though it never names those siblings explicitly.

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 concrete preconditions for calling: baseVersion must match the current version, use 0 for a new decision, and a stale value fails with a conflict. It also explains the post-call lifecycle (owner-scoped bind immediately; shared ones stay open until acknowledged), which tells the agent what proposing actually accomplishes.

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

Deploy Server

Other Tools