com.linebreakapp/linebreak-gate
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_storiesA | 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. |
| get_storyA | 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. |
| next_storyA | The next approved story that is not yet done, per local story state. Use this to pick up work without guessing at priorities. |
| set_story_statusA | 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. |
| check_storyA | Run this story's acceptance criteria against the working tree with
the SAME engine as the merge gate ( |
| spec_statusA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each 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.