Skip to main content
Glama
lockstep-team-agent

lockstep

by lockstep-team-agent
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

notify

Publishes project changes to a shared change feed so other teams' agents can see them; attach a surface or contract delta, with shared and contract changes awaiting confirmation.

Instructions

Publish a change to the project's change feed so other teams' agents see it. Use for something that already changed or is about to; use ask to pose a question and propose_decision to record a rule. Optionally tied to a surface (for example http:POST /session) with a contract delta. Risk tier owned publishes immediately; shared and contract changes wait for confirmation. Changes with a surface are delivered to repos that declared a dependency on it. Returns the change id, publish state, delivered count and impact (number of consuming repos).

Input Schema

NameRequiredDescriptionDefault
summaryYesOne-sentence description of what changed, written for other teams' agents.
surfaceNoSurface the change touches, for example http:POST /session. Repos that declared a dependency on it are notified.
diffHashNoOptional hash of the diff this change describes, stored for traceability.
riskTierNoowned (default) publishes immediately. shared and contract wait for confirmation before they are delivered.
verifiedNoTrue if you checked the delta against running code or tests. Default false, recorded as asserted but unverified.
capabilityRefNoCapability or feature reference to attach. Defaults to the one set with set_feature_context.
contractDeltaNoOptional JSON describing the contract change (for example old and new request or response shape). Stored with the change as given.
verifiedAgainstNoWhat you verified against, for example a test name or commit. Only meaningful with verified.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.1.3
    • 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 / contractDelta / description
      Added value: +"Optional JSON describing the contract change (for example old and new request or response shape). Stored with the change as given."
    • addedInput schema / properties / diffHash / description
      Added value: +"Optional hash of the diff this change describes, stored for traceability."
    • addedInput schema / properties / riskTier / description
      Added value: +"owned (default) publishes immediately. shared and contract wait for confirmation before they are delivered."
    • addedInput schema / properties / summary / description
      Added value: +"One-sentence description of what changed, written for other teams' agents."
    • addedInput schema / properties / surface / description
      Added value: +"Surface the change touches, for example http:POST /session. Repos that declared a dependency on it are notified."
    • addedInput schema / properties / verified / description
      Added value: +"True if you checked the delta against running code or tests. Default false, recorded as asserted but unverified."
    • addedInput schema / properties / verifiedAgainst / description
      Added value: +"What you verified against, for example a test name or commit. Only meaningful with verified."
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses the confirmation gating per risk tier, the conditional fan-out to dependent repos, and what the call returns. It stops short of auth/permission requirements, idempotency, or what happens if a waiting change is never confirmed.

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?

Front-loaded with purpose in the first clause, then alternatives, then gating, then return shape – a sensible order with no filler. It is dense; the surface/delivery sentence partly restates the surface property description, which keeps it from a 5.

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

Completeness5/5

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

Eight parameters but all fully described in the schema, and the description supplies what the schema cannot: the publish lifecycle, confirmation gating, delivery fan-out, and the return payload (change id, publish state, delivered count, impact) despite there being no output schema.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds cross-parameter meaning the schema does not: surface plus contractDelta are 'optionally tied', and a present surface changes delivery behavior to dependent repos. It also reinforces the riskTier default/confirmation split, going beyond the per-field text.

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?

Names a specific verb+resource ('Publish a change to the project's change feed') plus the beneficiary ('so other teams' agents see it'). It also differentiates itself from the two nearest siblings by name, so an agent can choose without opening any 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?

Explicitly states when to use this tool ('something that already changed or is about to') and routes the two alternative cases to ask and propose_decision. The riskTier sentence further defines the gating condition (owned publishes immediately; shared/contract wait).

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