projax-mcp: register as Claude MCP server for project management + task admin #3

New Issue

mAi · 2026-05-16T13:22:18Z

mAi commented

2026-05-16 13:22:18 +00:00

Request

m (2026-05-16, PWA chat): "File mal ein projax issue: projax-mcp, für Projektmanagement und Task-Verwaltung."

(EN: "File a projax issue: projax-mcp, for project management and task admin.")

Current state

projax already has an mcp/ package with 10 tools wired up (see mcp/tools.go):

list_items, get_item, create_item, update_item, delete_item
list_links, add_link, remove_link
search, tree

Good coverage of the items + links surface. What's missing is registering this MCP server so heads and workers can actually call mcp__projax__* from their Claude sessions.

Scope

Phase A — Register the MCP server

Confirm the MCP server is reachable: a local socket / HTTP endpoint. Where does the binary live, who runs it, what's the connect string?

Add an entry to ~/.claude/mcp.json (or the per-project .mcp.json where appropriate) so Claude Code picks it up:

{
  "projax": {
    "command": "<path-to-binary>",
    "args": ["mcp"],
    "env": { "PROJAX_DB_URL": "..." }
  }
}

Smoke-test from a head: mcp__projax__list_items(kind: "project", status: "active") should return the existing 30+ project rows.
Document in m/projax:docs/ how to invoke each tool from a Claude session.

Phase B — Task-admin coverage

"Task-Verwaltung" might mean either:

(a) the existing items model (kind=task) — does create_item + update_item already cover task creation + status transitions? If yes, document the workflow.
(b) a richer task layer, e.g. assignment, due dates, dependencies, recurrence — needs separate design.

The initial researcher should confirm which interpretation matches m's intent and either document the (a) path or stub a design doc for (b) with open questions.

Phase C — Lifecycle tools

m's [[concept-promotion-demotion-projects]] in mBrian (2026-05-15) describes a Promote/Demote lifecycle for items. Existing update_item can probably implement this if status changes are allowed. Two specific helpers would be nicer:

mcp__projax__promote(id) — move an item up the hierarchy (sub-project → top-level, idea → project)
mcp__projax__demote(id, parent) — opposite

These would map onto existing logic but make the lifecycle semantics explicit at the MCP surface.

Phase D — Sub-project use-cases

Three concrete sub-project requests already on hold (originally tracked under projax#1 before we realised the schema already exists via multi_parent):

Mental (alias Psychologie) under Health
Finanzplanung under Finances
NewHomeSpecs under mHome

Once the MCP is registered, the head can create these directly. (Or the worker on this issue creates them as part of validation.)

Out of scope

Multi-tenancy / public MCP. Single-user, single-host for now.
CalDAV-side MCP (separate concern, projax already proxies CalDAV but that surface stays in the projax web UI).
Auth / token rotation in the MCP layer. Local-only, trusted clients.
Replacing mcp__mai__* task surface — projax-mcp is for projax items; mai.tasks remains the runtime task layer for worker dispatch.

Refs

m/projax:mcp/ — existing MCP package with handler.go + tools.go.
mBrian: [[concept-promotion-demotion-projects]] — lifecycle semantics.
m/projax#1 — the sub-project schema issue that turned out to be already-implemented (multi_parent in migration 0010 + aliases since 0001). Probably status:done now.
m/mAi#230 — the heads CLI; once projax-mcp is wired, the head can use mcp__projax__list_items for cross-project sweeps that complement mai heads.

Role: coder (Phase A is the smallest viable slice — wire + smoke-test). Phase B + C + D can spawn as follow-up issues once A lands.

## Request m (2026-05-16, PWA chat): "File mal ein projax issue: projax-mcp, für Projektmanagement und Task-Verwaltung." (EN: "File a projax issue: projax-mcp, for project management and task admin.") ## Current state projax already has an `mcp/` package with 10 tools wired up (see `mcp/tools.go`): - `list_items`, `get_item`, `create_item`, `update_item`, `delete_item` - `list_links`, `add_link`, `remove_link` - `search`, `tree` Good coverage of the items + links surface. What's missing is registering this MCP server so heads and workers can actually call `mcp__projax__*` from their Claude sessions. ## Scope ### Phase A — Register the MCP server 1. Confirm the MCP server is reachable: a local socket / HTTP endpoint. Where does the binary live, who runs it, what's the connect string? 2. Add an entry to `~/.claude/mcp.json` (or the per-project `.mcp.json` where appropriate) so Claude Code picks it up: ```json { "projax": { "command": "<path-to-binary>", "args": ["mcp"], "env": { "PROJAX_DB_URL": "..." } } } ``` 3. Smoke-test from a head: `mcp__projax__list_items(kind: "project", status: "active")` should return the existing 30+ project rows. 4. Document in `m/projax:docs/` how to invoke each tool from a Claude session. ### Phase B — Task-admin coverage "Task-Verwaltung" might mean either: - (a) the existing `items` model (kind=task) — does `create_item` + `update_item` already cover task creation + status transitions? If yes, document the workflow. - (b) a richer task layer, e.g. assignment, due dates, dependencies, recurrence — needs separate design. The initial researcher should confirm which interpretation matches m's intent and either document the (a) path or stub a design doc for (b) with open questions. ### Phase C — Lifecycle tools m's `[[concept-promotion-demotion-projects]]` in mBrian (2026-05-15) describes a Promote/Demote lifecycle for items. Existing `update_item` can probably implement this if status changes are allowed. Two specific helpers would be nicer: - `mcp__projax__promote(id)` — move an item up the hierarchy (sub-project → top-level, idea → project) - `mcp__projax__demote(id, parent)` — opposite These would map onto existing logic but make the lifecycle semantics explicit at the MCP surface. ### Phase D — Sub-project use-cases Three concrete sub-project requests already on hold (originally tracked under `projax#1` before we realised the schema already exists via `multi_parent`): - `Mental` (alias `Psychologie`) under `Health` - `Finanzplanung` under `Finances` - `NewHomeSpecs` under `mHome` Once the MCP is registered, the head can create these directly. (Or the worker on this issue creates them as part of validation.) ## Out of scope - Multi-tenancy / public MCP. Single-user, single-host for now. - CalDAV-side MCP (separate concern, projax already proxies CalDAV but that surface stays in the projax web UI). - Auth / token rotation in the MCP layer. Local-only, trusted clients. - Replacing `mcp__mai__*` task surface — projax-mcp is for projax items; mai.tasks remains the runtime task layer for worker dispatch. ## Refs - `m/projax:mcp/` — existing MCP package with handler.go + tools.go. - mBrian: `[[concept-promotion-demotion-projects]]` — lifecycle semantics. - `m/projax#1` — the sub-project schema issue that turned out to be already-implemented (multi_parent in migration 0010 + aliases since 0001). Probably status:done now. - m/mAi#230 — the heads CLI; once projax-mcp is wired, the head can use `mcp__projax__list_items` for cross-project sweeps that complement `mai heads`. Role: **coder** (Phase A is the smallest viable slice — wire + smoke-test). Phase B + C + D can spawn as follow-up issues once A lands.

mAi self-assigned this 2026-05-16 13:27:35 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: m/projax#3