frontier-mcp
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
} |
| resources | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_effortsA | List the Efforts in a repo, each with its Ticket count and which header docs it holds. |
| get_boardA | An Effort's Destination, then one line per Ticket — id, title, kind, status, Edges — with the Frontier marked. Never returns bodies; fetch those with get_tickets. |
| get_ticketsA | Full bodies for a list of Ticket ids, in one call. Use after get_board, only for the Tickets you actually work. |
| create_ticketsA | Publish a whole breakdown in one call. Edges may name a sibling by a temporary key you choose; the server mints repo-unique ids, numbers the files, and resolves the keys atomically — a partial failure creates nothing. Cycles are refused. An unknown Effort needs create. |
| update_ticketA | Change one Ticket. Lifecycle: claim, resolve with a one-line gist, drop with a reason, reopen with a reason, or release a claim — at most one of those per call. Graph: replace the Edges, refused if they close a cycle. Identity: title, kind, and type. Annotations: triage role, a comment, ticking acceptance criteria; these touch no part of the graph. Any of the four groups may accompany the others or stand alone. |
| edit_mapA | Read a Map's Destination and Notes, or edit one typed section — set Destination or Notes, add or graduate a fog patch, rule something out of scope — without rewriting the others. Decisions-so-far is generated from resolved Tickets and never accepted as input. Mutations pass expected_revision from a prior read so concurrent sessions cannot clobber each other. |
| specA | Get or put a Spec as a whole opaque document (conventionally with YAML frontmatter). Nothing edits a Spec section by section — an Effort may hold both a Map and a Spec. Puts pass expected_revision from a prior read so concurrent sessions cannot clobber each other. |
| migrate_effortA | Normalize Legacy Tickets in an Effort: schema frontmatter, preserve existing ids, mint ids for Tickets that have none, turn prose Edges into blocked_by. Preview writes nothing. Filename rewriting is opt-in. Unrecognized files in the Effort directory are ignored. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| tracker-doc | Tracker conventions and FrontierMCP tool mapping. Read once at setup; file conventions work as fallback without the server. |
TDQS
Scored across 8 tools
Each tool targets a distinct resource or action: get_tickets fetches bodies, get_board provides an overview, create_tickets does batch creation, update_ticket handles single modifications, edit_map and spec manage different document types, and migrate_effort is a utility for normalization. No two tools have overlapping purposes.
Most tools follow a consistent verb_noun snake_case pattern (get_tickets, list_efforts, create_tickets, update_ticket, edit_map, migrate_effort). The lone exception is 'spec', which uses a bare noun instead of a verb, creating a minor inconsistency but remaining clear and predictable.
With 8 tools, the server is well-scoped for its purpose of managing efforts, tickets, maps, and specs. Each tool serves a distinct function without redundancy, and the count is squarely within the optimal 3-15 range.
The core ticket lifecycle is covered (batch create, single update, read via board and bodies), along with map and spec editing and migration. The main gap is the lack of a delete or archive tool for tickets, and there is no explicit create_effort tool, though create_tickets references needing one. These are minor gaps given the planning-centric focus.