@elixium.ai/mcp-server 0.4.0 → 0.6.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -7,6 +7,7 @@ This server implements the [Model Context Protocol (MCP)](https://modelcontextpr
7
7
  - **Create Story**: Add new stories directly from your editor.
8
8
  - **Update Story**: Move stories between lanes and update fields.
9
9
  - **Iteration Context**: Provide the AI with the full context of your Current and Backlog lanes for better planning.
10
+ - **Board Context** (new in 0.6.0): One-call grounding tool (`get_board_context`) that returns a time-balanced workspace snapshot — in-flight work, queued/icebox/recently-completed stories and epics, recent decisions, objectives, learnings, and workspace configuration — so agents ground themselves before drafting or updating content. Requires a backend release that includes `GET /api/board-context` (SaaS: live since 2026-05-17; self-hosted: update to a matching release). Falls back gracefully with a usable message if the backend is older.
10
11
 
11
12
  ## Quick Start
12
13
 
@@ -125,6 +126,30 @@ If you're using multiple MCP servers, combine them in the same config:
125
126
  > If you set `ELIXIUM_BOARD_SLUG`, the MCP server will only read/write stories for that board.
126
127
  > The server resolves the board slug to a boardId on startup, so the slug must match an existing board.
127
128
 
129
+ ## Required Scopes (for Scoped API Keys)
130
+
131
+ If you generate a **scoped** API key (via the Command Center → Integrations → *Advanced: Key Scopes*), the key must include the scopes below to use the corresponding MCP tools. An **unscoped** key (all scopes picker collapsed when generating) has full access and works with every tool.
132
+
133
+ | Tool category | Tools | Required scopes |
134
+ |---|---|---|
135
+ | **Read stories** | `list_stories`, `get_story`, `get_iteration_context`, `prepare_implementation`, `estimate_cost` | `stories:read` |
136
+ | **Write stories** | `create_story`, `update_story`, `start_story`, `propose_test_plan`, `submit_for_review`, `record_learning`, `create_hypothesis` | `stories:read` + `stories:write` |
137
+ | **Read epics** | `list_epics`, `get_epic_cost_rollup` | `epics:read` |
138
+ | **Write epics** | `create_epic`, `update_epic`, `prioritize_epic` | `epics:read` + `epics:write` |
139
+ | **Read boards** | `list_boards`, `select_board` | `boards:read` |
140
+ | **Write boards** | `create_board` | `boards:read` + `boards:write` |
141
+ | **Read workspace config** | `get_feature_config`, `get_infrastructure_profile` | `workspace:read` |
142
+ | **Team decisions** | `list_decisions`, `search_decisions` | `stories:read` |
143
+ | **Team decisions (write)** | `record_decision` | `stories:read` + `stories:write` |
144
+ | **Objectives** | `list_objectives` | `stories:read` |
145
+
146
+ **Recommended baseline for full MCP functionality:**
147
+ ```
148
+ stories:read, stories:write, epics:read, epics:write, boards:read, workspace:read
149
+ ```
150
+
151
+ If a scoped key is missing a scope, the MCP server surfaces an actionable error message naming the missing scope and directing you to regenerate the key with the required scope. You do NOT need to restart the MCP server after regenerating — just update `ELIXIUM_API_KEY` in your config and reload the server.
152
+
128
153
  ## Usage
129
154
  Once configured, your AI agent will have access to tools like:
130
155
  - `list_stories` - View all stories on the board
@@ -0,0 +1,30 @@
1
+ /**
2
+ * Error-fallback feature config used by the mcp-server when the backend
3
+ * `/config/features` endpoint is unreachable. Extracted from `src/index.ts`
4
+ * so it can be imported into tests without triggering the entrypoint's
5
+ * top-level await (`startStdioServer` / `startSseServer`).
6
+ *
7
+ * `useDeliveredState` defaults to `false` (3-state simple) per story 16f8ede4
8
+ * — matches the backend smart default, so a transient fetch failure won't
9
+ * silently re-introduce 4-state behavior on the agent side.
10
+ */
11
+ export const MCP_FEATURE_CONFIG_ERROR_FALLBACK = {
12
+ features: {
13
+ balancedTeam: false,
14
+ learningLoop: false,
15
+ tddWorkflow: true,
16
+ aiTools: true,
17
+ teamDecisions: false,
18
+ ragKnowledgeBase: false,
19
+ useDeliveredState: false,
20
+ },
21
+ source: {
22
+ balancedTeam: "error-fallback",
23
+ learningLoop: "error-fallback",
24
+ tddWorkflow: "error-fallback",
25
+ aiTools: "error-fallback",
26
+ teamDecisions: "error-fallback",
27
+ ragKnowledgeBase: "error-fallback",
28
+ useDeliveredState: "error-fallback",
29
+ },
30
+ };
@@ -0,0 +1,59 @@
1
+ /**
2
+ * Canonical workflow model labels for MCP tool responses.
3
+ *
4
+ * Story 69c3a615 — surfaces the active workflow model in `start_story` and
5
+ * `submit_for_review` responses so agents (and through them, users) know
6
+ * what state transitions to expect. Story 79f641d5 (Team Profile UI) will
7
+ * import the same constants to keep terminology aligned across layers.
8
+ *
9
+ * AC: "model name matches the Team Profile UI's label exactly (no
10
+ * terminology drift between layers)" — this module is the single source.
11
+ */
12
+ export const WORKFLOW_MODEL_NAMES = {
13
+ /** Pivotal-style 4-state model with explicit `delivered` step. */
14
+ pivotal4State: "4-state (Pivotal)",
15
+ /** Trunk-based 3-state model — no delivered step, finished → accepted. */
16
+ trunk3State: "3-state (simple)",
17
+ };
18
+ /** Per-state parenthetical explanations under each model. */
19
+ export const WORKFLOW_MODEL_STATE_EXPLANATION = {
20
+ pivotal4State: {
21
+ delivered: "work is on main, awaiting acceptance",
22
+ finished: "PR pending merge, advances to delivered when merged",
23
+ },
24
+ trunk3State: {
25
+ finished: "story moves directly to accepted on human review",
26
+ },
27
+ };
28
+ /** At-start (no state yet) explanations — used by `start_story`. */
29
+ export const WORKFLOW_MODEL_START_EXPLANATION = {
30
+ pivotal4State: "submit will set delivered (auto-merge) or finished (PR pending)",
31
+ trunk3State: "submit advances to finished, accept moves to accepted",
32
+ };
33
+ /**
34
+ * Formats the canonical "Workflow Model:" line for MCP tool responses.
35
+ *
36
+ * Examples:
37
+ * { useDeliveredState: true, state: "delivered" }
38
+ * → "4-state (Pivotal — work is on main, awaiting acceptance)"
39
+ * { useDeliveredState: false, state: "finished" }
40
+ * → "3-state (simple — story moves directly to accepted on human review)"
41
+ * { useDeliveredState: true } (no state — start_story case)
42
+ * → "4-state (Pivotal — submit will set delivered (auto-merge) or finished (PR pending))"
43
+ *
44
+ * Single-line output guarantee: the returned string never contains a newline
45
+ * — callers can safely interpolate it as one row in a markdown response.
46
+ */
47
+ export function formatWorkflowModelLine(args) {
48
+ const modelKey = args.useDeliveredState ? "pivotal4State" : "trunk3State";
49
+ const baseName = args.useDeliveredState ? "4-state" : "3-state";
50
+ const typeLabel = args.useDeliveredState ? "Pivotal" : "simple";
51
+ let explanation = WORKFLOW_MODEL_START_EXPLANATION[modelKey];
52
+ if (args.state) {
53
+ const stateExplanations = WORKFLOW_MODEL_STATE_EXPLANATION[modelKey];
54
+ const found = stateExplanations[args.state];
55
+ if (found)
56
+ explanation = found;
57
+ }
58
+ return `${baseName} (${typeLabel} — ${explanation})`;
59
+ }