Skip to main content
Glama
Sign In

NextConstraint

by app.nextconstraint
OverviewDiscussionsAdmin

Mark fix shipped

mark_fix_done
Idempotent

Record that a fix has shipped: the current constraint's fix (omit issue_id) or one alert's fix. Give commit_sha (and optionally branch) when the fix was a code change: NextConstraint waits for that exact commit to reach a production deploy before starting the re-check, so the window starts from when the fix actually went live, not from this call (see the fix-workflow prompt). Omit commit_sha to start the re-check immediately instead - this only changes NextConstraint's own record and never touches the founder's code, payments or analytics. There is no undo here, so confirm with the founder that the fix is live (or, with a SHA, that it has been merged and will deploy) first.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "mark_fix_done"
  }
}

Input Schema

NameRequiredDescriptionDefault
branchNoOptional: the branch the commit is on, for reference only (not matched against).
issue_idNoAn alert id from list_alerts. Omit to mark the current constraint's fix.
commit_shaNoThe git commit that contains the fix. Wait for it to reach a production deploy before the re-check starts, instead of starting immediately.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing downstream timing behavior (NextConstraint waits for the exact commit to reach a production deploy, so the window starts at go-live, not at call time) and blast radius ("only changes NextConstraint's own record and never touches the founder's code, payments or analytics"). The "no undo" warning adds real consequence information that destructiveHint=false does not convey; the only mild tension is that irreversibility sits alongside destructiveHint=false, though these are compatible claims.

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 the action, then the commit_sha branch, then safety. Dense but nearly every clause carries new information; a few phrases (commit/branch handling) duplicate the schema descriptions and could be trimmed.

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?

For a zero-required-parameter mutation with no output schema, the description supplies what an agent actually needs: which target is affected, what happens next in the workflow, whether external systems are touched, and the irreversibility caveat.

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 the baseline is 3 and the schema already documents all three fields. The description nonetheless adds meaning the schema lacks: why commit_sha matters (the re-check window is anchored to the deploy, not to this call) and the consequence of omitting it (immediate re-check).

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?

States a specific verb+resource ("Record that a fix has shipped") and immediately enumerates the two targeting modes: the current constraint's fix via omitting issue_id, or one alert's fix via issue_id. A reader can tell exactly what state change happens and against which object, and it is the only mutating sibling among get_*/list_* tools.

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 branches on the key decision: pass commit_sha when the fix was a code change (deploy-gated re-check), omit it to start the re-check immediately. It also states a precondition ("confirm with the founder that the fix is live") and points to the fix-workflow prompt for deeper context.

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

All NextConstraint toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources