This server exposes LineBreak security/spec gate MCP tools for inspecting and managing approved acceptance criteria and story progress. Tools:
list_stories — List approved stories with id, title, epic, local status (todo/doing/review/done), and number of acceptance criteria.
get_story — Retrieve a full story with all acceptance criteria (id, statement, check type: build/tests/command/manual) before implementing.
next_story — Get the next approved not-done story to prioritize work.
set_story_status — Update local story status (doing/review/done) with optional comment; never modifies approved criteria.
check_story — Run a story’s acceptance criteria against the working tree using the CI gate engine, returning pass/fail/needs-signoff per criterion.
spec_status — Check whether an approved spec bundle exists, with approval version, source, approver, story count, and signature verification state (verified/invalid/signed-unverified/unsigned).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@com.linebreakapp/linebreak-gate list all approved stories for this sprint"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A real pull request, blocked for real: the gate is a required check, so the merge button goes gray until the CVE is fixed or a named human records an override.
See it live — a public PR you can open right now →
A real recording, no mock: the scan blocks a critical CVE fail-closed, the pin gets fixed, the gate opens.
The spec loop: a named human approves the criteria, check blocks until the manual criterion carries a sign-off, then everything passes.
Blocks merges that carry known vulnerabilities. One tool, two detectors — dependency scanning is free; the AI review is the Pro upgrade:
Dependency CVE scan — free, no key — osv-scanner
across every ecosystem (npm, PyPI, Go, Cargo, Maven, …), with an npm audit
fallback for npm projects (npm-only coverage and no installed-version data —
the GitHub Action fails closed if osv-scanner can't be installed instead of
degrading to it).
AI SAST — Pro — an LLM security review of first-party source (injection,
broken auth, secret exposure, SSRF, unsafe deserialization, crypto misuse)
with adversarial verification, enabled by LINEBREAK_LICENSE_KEY (hosted,
uses credits) or ANTHROPIC_API_KEY (your own key, takes precedence). Without
a key the dependency scan still runs and this pass is skipped with a notice.
The gate blocks and can propose; it never auto-clears on an agent's say-so. A human approves the fix or records an override — with a reason and an approver — in a git-committed audit file.
This is the same scanner core that powers the rest of LineBreak's in-product security gate (the desktop backend imports this package), but it is fully standalone: a team that has never touched anything else from LineBreak can add the gate to their repo and get real enforcement.
Contributing & license. This repo is the published source of
linebreak-gate(Apache-2.0): every release lands here and on PyPI from our CI, and every change passed our own gate first — CVE scan and human-approved criteria, the same discipline we sell. Bug reports and feature requests: open an issue or discussion here; we read everything. Direct PRs to this repo can't be merged (releases flow through our review pipeline), so start with an issue and we'll take it from there.
Related MCP server: Sprintra
# .github/workflows/security-gate.yml
name: Security gate
on:
pull_request:
permissions:
contents: read
pull-requests: write # for the summary comment
jobs:
gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: Baktun-Studio/linebreak-gate@v1
with:
# fail-on: high # blocking floor; default: critical
# Optional today; required once license enforcement is enabled.
license-key: ${{ secrets.LINEBREAK_LICENSE_KEY }}
# Enables the AI code review; leave unset for dependency scan only.
anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }}The action runs linebreak-gate scan, always runs report, posts one PR
comment (updated in place on every push, never spammed), uploads the JSON
report + audit artifacts as a workflow artifact, and fails the check per the
scan's exit code.
A CI job that can be ignored is a dashboard, not a gate. In your repo:
Settings → Branches → Branch protection rules → your default branch →
"Require status checks to pass before merging" → add the gate job (the
name of the job that runs this action). From then on a PR carrying a critical
CVE cannot be merged through the GitHub UI.
The CLI is a plain Python package with strict exit codes — 0 pass, 1
blocking findings, 2 tool/config error (fail closed: a scanner crash
fails the pipeline, it is never a clean pass). Any CI that respects exit codes
gets the same enforcement:
# .gitlab-ci.yml
security-gate:
image: python:3.11
script:
- pip install linebreak-gate
- curl -fsSL -o /usr/local/bin/osv-scanner
"$(curl -fsSL https://api.github.com/repos/google/osv-scanner/releases/latest
| python -c "import json,sys;print(next(a['browser_download_url'] for a in json.load(sys.stdin)['assets'] if a['name'].endswith('linux_amd64')))")"
- chmod +x /usr/local/bin/osv-scanner
- linebreak-gate scan
- linebreak-gate reportMark the job as required (no allow_failure) and protect the branch.
The gate also enforces approved acceptance criteria, and the whole loop is tool-agnostic — no LineBreak account, no desktop app, no server:
linebreak-gate spec new # scaffold a draft — fill it with any tool (your
# editor, Claude Code, ChatGPT), or distill it
# from the PRD you already have in Notion/Jira
linebreak-gate spec approve .linebreak/spec-draft.yml \
--approver "Ana Lopez <ana@example.com>" # a human on the record; commits
linebreak-gate mcp install --editor claude-code # or: cursor · codexlinebreak-gate mcp serves the approved bundle (.linebreak/spec/) over
MCP (stdio) to Claude Code, Cursor, Codex, or any MCP client. Six tools:
list_stories, get_story (criteria as agent context BEFORE code is
written), next_story, set_story_status, check_story (the same
evaluation engine CI runs, scoped to one story), and spec_status (approval +
offline signature state). Git is the transport — no network, no account,
works on a bare clone — and nothing in the bridge can write, edit, or
invalidate an approved criterion: criteria change only by editing the draft
and re-approving, with a human on the record.
Then linebreak-gate check enforces the same criteria in CI: machine checks
run for real, manual criteria block until a recorded sign-off. Guided first
run with the why of every step:
linebreakapp.com/en/start.
linebreak-gate init [--path .] [--fail-on critical|high|medium|low] [--force] [--non-interactive]
linebreak-gate scan [--path .] [--fail-on critical|high|medium|low] [--format summary|json]
linebreak-gate report [--path .] [--format summary|json]
linebreak-gate override --finding <id> --reason "…" --approver <name/email> [--path .]
linebreak-gate override --criterion <id> --reason "…" --approver <name/email> [--path .]
linebreak-gate check [--path .] [--format summary|json]
linebreak-gate signoff --criterion <id> --approver <name/email> --note "…" [--path .]
linebreak-gate spec new [--path .] [--out <file>] [--force]
linebreak-gate spec approve <draft> --approver <name/email> [--role architect] [--path .]
linebreak-gate spec list|next [--path .]
linebreak-gate spec show|check <story-id> [--path .]
linebreak-gate mcp [--path .] # serve the approved spec over stdio
linebreak-gate mcp install [--editor claude-code|cursor|codex] [--print]
linebreak-gate badge [--format markdown|html|url]init sets a repo up in one command: writes the workflow file (never
clobbers an existing one without --force), optionally writes
.linebreak/gate.yml, offers to store the secrets via the GitHub CLI and to
require the gate check — and prints the exact settings links for anything
it can't do for you.
scan runs both detectors, writes git-native audit artifacts under
.linebreak/audit/, and exits 0/1/2.
report renders the recorded scan: counts by severity and every finding
with CVE id, CVSS, advisory link, and override status. --format json for
machines.
override records a human-approved acknowledgment of one exact finding
— the package + installed version + CVE tuple. A different CVE, a bumped
version, or a new finding still blocks. --reason and --approver are
required; the record lands in the artifact's approval trail. Commit the
updated .linebreak/audit/*.json so CI sees it.
check evaluates the approved acceptance criteria (.linebreak/spec/,
landed by spec approve) against
the working tree: build/tests/command run for real, manual requires
a recorded sign-off. Exit 0 all satisfied (or no bundle — a clean no-op), 1
blocking (fail or needs-signoff), 2 tool/config/bundle error (fail closed).
Writes .linebreak/audit/criteria.json.
signoff records an attributed human sign-off for one manual criterion
under .linebreak/spec/signoffs/ (additive; --approver and --note
required). It binds to the criterion as approved — editing the criterion
and re-approving the spec makes prior sign-offs stale. Commit the record.
override --criterion records a human-approved override for one failed
machine criterion in .linebreak/audit/criteria.json — same philosophy as
CVE overrides: possible, always attributed, stale once the criterion is
edited. Other blocking criteria still block.
spec new / spec approve — the tool-agnostic authoring path (see the
spec-loop section above): scaffold a draft, fill it with any tool, land it
as the approved bundle with an attributed human approval, committed.
Unsigned local approvals are marked identity_source: client; cryptographic
signatures come from the governance service (license key).
spec list prints the approved acceptance criteria bundle: each story, its
criteria with check types, and the approver attribution. Read-only. Exit 0
on a valid bundle or when none exists; exit 2 on a malformed bundle (fail
closed on structure). spec next / show / check are the CLI twins of
the MCP bridge tools.
Show visitors the repo is gated. linebreak-gate badge prints a ready-to-paste
README snippet (no network calls — the shields.io static badge is fully encoded
in its URL); --format html|url for the tag or bare-URL variants:
[](https://www.linebreakapp.com/en/gate).linebreak/gate.ymlThe gate's strictness is governance, so it lives in the repo — changing the threshold is itself a PR: visible, reviewable, attributable in git history.
# .linebreak/gate.yml
fail_on: critical # critical (default) | high | medium | low
exclude_paths: # optional: root-relative globs excluded from scanning
- fixtures
- "sandbox/*"
code_scan: auto # auto (run when model credentials are set) | on (required) | off
criteria:
enforce: true # default: true whenever a spec bundle exists; false disables
# criteria checking only (the security scan is unaffected)Precedence: explicit --fail-on flag / Action input → .linebreak/gate.yml →
built-in default (critical). An invalid config is a tool error (exit 2) —
a broken governance file never silently falls back to a default.
Every scan and every override is recorded in .linebreak/audit/security.json
(dependencies) and .linebreak/audit/code.json (AI SAST) — the same versioned
document format the LineBreak tools write, carrying findings (CVE id,
CVSS, advisory link), scanner engine, timestamp, actor, and the approval trail
with each override's reason + approver. Who relaxed the gate, and when, is
itself auditable.
Free, forever: the dependency CVE scan and the whole spec loop — authoring, human approval, MCP serving, and CI enforcement. No key, no account.
Pro — $99/month per team (pricing):
cryptographically signed, tamper-evident approvals (Ed25519, verifiable
offline), required-key enforcement mode, and hosted AI code review with no
API key to manage. Buy on the pricing page — your LINEBREAK_LICENSE_KEY
arrives by email within seconds (it's the Action's license-key input).
Prefer your own model key? ANTHROPIC_API_KEY also enables the AI review;
Pro's hosted review is the zero-config path.
The gate runs open by default: it works without a key and prints a notice
when no LINEBREAK_LICENSE_KEY is set (suppressed for BYOK users). That's
freemium — the dependency scan runs free. Teams that want to require a valid
Pro key for the gate to run at all can opt into
LINEBREAK_ENTITLEMENTS_PROVIDER=remote, which checks the entitlement before
any scan and fails closed on a missing/invalid/revoked key, wrong plan, or
unreachable service — blocking the whole gate, dependency scan included.
Run this story's acceptance criteria against the working tree with
the SAME engine as the merge gate (linebreak-gate check). Returns
pass | fail | needs-signoff per criterion — verify your work here
BEFORE pushing instead of discovering failures at the merge.
| Name | Required | Description | Default |
|---|---|---|---|
| story_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions the engine equivalence and return values (pass|fail|needs-signoff), but does not explicitly state whether it modifies anything or any prerequisites, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and engine, and contains no filler words. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, no annotations, and an output schema present, the description adequately covers purpose, return format, and usage timing. It lacks minor details like prerequisites or edge cases, but remains complete for a simple check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the only parameter story_id is 0%, and the description only refers to 'this story' without explaining the ID format or how to obtain it. Since the schema lacks descriptions, the description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a story's acceptance criteria using the same engine as the merge gate, specifying the verb 'Run' and the resource 'acceptance criteria'. It distinguishes itself from sibling tools like get_story or spec_status by focusing on the local check before pushing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it before pushing to avoid discovering failures at the merge, providing clear temporal context. It doesn't name alternatives but the instruction is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One approved story in full: title, epic, and every acceptance criterion with its id, statement, and check type (build | tests | command | manual). Read this BEFORE implementing the story — the criteria are the approved definition of done.
| Name | Required | Description | Default |
|---|---|---|---|
| story_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the returned fields and the key behavioral fact that the criteria are the approved definition of done. However, it does not explicitly state read-only behavior, potential errors, or authorization requirements, though 'Read this' implies a non-mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded output summary and a clear usage directive. Every sentence adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key output fields and usage timing, and an output schema exists for return details. It stops short of explaining error/not-found behavior or explicitly comparing to sibling tools, but for a simple single-id retrieval tool it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required story_id with 0% schema description coverage. The description does not elaborate on the parameter, leaving the agent to infer that story_id identifies the story. This adds no meaning beyond the parameter name, so it does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'One approved story in full' with title, epic, and every acceptance criterion. This specifies a verb (retrieve/get), resource (story), and the detailed scope, distinguishing it from sibling tools like list_stories which would provide a listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to read this tool 'BEFORE implementing the story,' establishing the intended usage context. It does not name alternatives or exclusions, but the emphasis on 'approved definition of done' implies this is the authoritative source for implementation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All approved stories in this repository: id, title, epic, local status (todo|doing|review|done), and how many acceptance criteria each carries. The list IS the approved scope — nothing else is in spec.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses output fields, includes the local status enum, and reveals the key behavioral trait that this list is the sole approved scope. It does not explicitly state read-only behavior or ordering, but the scope is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the most important information front-loaded ('All approved stories'), and no filler. Every word contributes to understanding the tool's output and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an existing output schema, the description fully covers purpose, return fields, status semantics, and the concept of approved scope, making it complete without needing to explain return values or parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%, so no parameter clarification is needed. The baseline for no-parameter tools is 4 and the description adds no unnecessary parameter noise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('approved stories in this repository'), enumerates the exact fields and status values returned, and clarifies that it represents the approved scope, clearly distinguishing it from sibling tools like get_story or spec_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'The list IS the approved scope' provides clear context for when this tool is appropriate, but it does not explicitly name alternatives or state when not to use it, falling just short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The next approved story that is not yet done, per local story state. Use this to pick up work without guessing at priorities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions the dependency on 'local story state' and the selection logic, but it does not explicitly state whether the operation is read-only or has side effects (e.g., marking the story as in progress). This ambiguity is a notable gap for an agent deciding whether to call this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first sentence defines the output and selection criteria; the second provides usage guidance. Every word earns its place, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters) and presence of an output schema, the description covers the essential aspects: what is returned (next approved, not done), the dependency (local state), and the use case (picking up work). It lacks explicit edge-case behavior (e.g., behavior when no approved story exists) but this is a minor omission for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty. The description correctly focuses on behavior rather than parameters. According to the calibration, a zero-parameter tool gets a baseline of 4, and the description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: returning 'the next approved story that is not yet done, per local story state.' This specific selection criteria (approved and not done) distinguishes it from siblings like list_stories (all stories) and get_story (a specific story). The verb 'pick up work' implies retrieval of a single next item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this to pick up work without guessing at priorities.' This provides a clear use case and implies this tool is preferable over manual priority guessing from list_stories. However, it does not explicitly name alternative tools or exclude when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record story progress: status is doing | review | done. Writes LOCAL story state only (the repo's tracker-sync artifact) — never a configured external tracker, and never the approved criteria.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| comment | No | ||
| story_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that this tool writes only the local tracker-sync artifact and never external trackers or criteria. This reveals side-effect scope clearly, though it does not detail permissions, reversibility, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every word adds value. It avoids redundancy and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with an output schema, the description adequately covers scope, status values, and side-effect limitations. It does not mention prerequisites (e.g., story must exist) or error cases, but these are not critical for basic usage given the output schema exists and sibling tools are available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds crucial semantics by restricting status to 'doing | review | done', which is not in the schema as an enum. However, it does not explain the optional comment parameter or clarify the story_id format beyond its obvious meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Record story progress', which is a specific verb+resource pairing. It also enumerates the valid status values (doing | review | done) and explicitly scopes the tool to local story state, distinguishing it from sibling tools like check_story or spec_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when this tool is appropriate (recording local story progress) and provides explicit exclusions: 'never a configured external tracker, and never the approved criteria.' However, it does not name sibling alternatives explicitly, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is there an approved spec bundle: version, source phase, approver, story count, and the approval signature state (verified | invalid | signed-unverified | unsigned), verified entirely offline.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that verification is done entirely offline, which is useful contextual behavior. However, it does not explicitly state whether the operation is read-only or if it has side effects, though 'status' implies a safe query. More explicit disclosure of non-mutating behavior and authorization needs would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently packs the purpose and the returned fields. It is front-loaded with the main query, but the list of fields makes it slightly dense. Still, every word contributes to the meaning, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has zero parameters and an output schema exists, the description provides enough context about the core purpose and included attributes. It does not mention any prerequisites or failure scenarios, but for a simple status query, the description is sufficiently complete within the existing structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameters to document. According to the rubric, zero parameters earns a baseline score of 4, and the description adds no irrelevant parameter information. No compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool checks for and reports on an approved spec bundle, listing specific fields (version, source phase, approver, story count, approval signature state). It distinguishes itself from sibling tools by focusing on bundle approval status rather than individual stories. However, the question format ('Is there...?') is slightly less direct than a verb like 'Get' or 'List'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verifying the state of an approved spec bundle, but it does not explicitly state when to use this tool versus siblings like check_story or list_stories. There are no exclusions or alternative tool references. The 'verified entirely offline' hint suggests a context but not comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0check_storyget_storylist_storiesnext_storyset_story_statusspec_statusEach tool targets a distinct function: listing stories, picking the next one, retrieving full story details, updating status, checking acceptance criteria, and inspecting spec status. There is no overlap in purpose, making selection unambiguous.
Most tools follow a clear verb_noun pattern (list_stories, get_story, set_story_status, check_story), but 'next_story' and 'spec_status' deviate from this pattern. Still, all names are readable and consistent in style (lowercase underscores), with only minor deviations.
Six tools is well within the ideal range and each tool earns its place, covering the core lifecycle of story selection, status updates, and gate verification without redundancy.
The set covers the entire local workflow: enumerate stories, pick next, get full details, update status, run acceptance checks, and verify spec approval. No obvious dead ends or missing operations for its stated purpose.
Roadmap, tasks, releases and user feedback your coding agent reads and writes over MCP.
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Baktun-Studio/linebreak-gate'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
