MCP server for Claude Code · v0.2.1

The ticket review that happens before the sprint.

Five deterministic product-thinking tools inside Claude Code. Hand over a ticket, by key or pasted, and we check it against your project charter for clarity, scope, value and breakdown. Every context-based claim quotes its source.

Get access See how it works

No API keys·Runs locally over stdio·No LLM calls in the server

claude code · ~/docs-assistant

> /mcp__mentis-work__brainstorm-ticket VAN-604

✓ jira MCP · VAN-604 fetched through your connector

title: Stream answers from the assistant endpoint

desc: …engineers assume it hung and retry. Also put the same chatbot on the public marketing site.

criteria: none · estimate: none

Confirm these fields before I triage?

> yes

✓ mentis://charter · grounded on mentis.project.md

✓ interrogate_ticket · rank-1 question

"What breaks, or what cost keeps being paid, if this is never built?"

> Engineers assume it hung and retry, which doubles load.

⚠ assess_ticket_readiness · not-ready

out-of-scope-overlap · no-acceptance-criteria · missing-rationale · no-estimate

⚠ check_definition_of_done · 0 covered, 4 missing

⚠ score_ticket_value · no score, 4 questions

verdict: clarify first (4 findings, 1 cited)

GROUNDED AGAINST

goal: "Let Northwind engineers get a correct answer…"

epics: [retrieval, answer-quality]

outOfScope: ["A public-facing chatbot for customers"]

definitionOfDone: 4 items

rice.bands: { high: 8, … }

NEXT ACTIONS

Split the public chatbot out, it is out of scope

Add acceptance criteria and an estimate

Answer the 4 RICE questions, then re-score

5deterministic toolsplain functions, same answer twice

1prompt to typebrainstorm-ticket chains the rest

1file makes it yoursmentis.project.md, versioned in your repo

0LLM calls in the serverno keys, no egress, no surprise bills

HOW IT WORKS

Three things happen on every call.

The server supplies frameworks and facts. The model does the reasoning. Neither is asked to do the other’s job.

It reads your charter

Every call re-reads mentis.project.md from your repo. Edit it mid-conversation and the next answer already reflects it. No restart, and nothing rides on what the model still remembers.

It runs plain checks

The INVEST rubric, definition-of-done coverage, question ranking and RICE arithmetic are ordinary functions. No model call, no network, no randomness. The same ticket and charter always give the same findings.

You get cited evidence

Structured JSON that names the charter it used, and quotes the ticket or charter line behind every context-based claim. Gaps come back as questions, never as assumptions.

THE LOOP

You are the connector.

It never talks to your tracker. No credentials, no network calls, no writes to your board. By design, not by omission.

It isn’t a Jira tool

The inputs are plain ticket fields, so Linear, GitHub issues, or a description someone typed in Slack all work the same way.

Grounding lives on your disk

Your tracker knows what the ticket says. The charter knows what your project is for. Only one side of that ever lived in Jira.

You hand over the ticket

Paste the whole thing as one blob and the prompt pulls the fields out. Only a title is required. With a Jira MCP server connected you can pass the key instead and let it fetch the ticket for you.

It checks against your charter

mentis.project.md on your disk: your goal, epics, out-of-scope list, definition of done, RICE bands. That comparison is the whole product.

You carry the result back

Findings, questions and a decomposition come back as proposals with citations. You decide what lands on the board. Every write is a human act, on purpose.

Prefer fetching tickets by key? Connect Atlassian’s own MCP server alongside this one. MCP servers compose in a single session, so you can pass a key like PROJ-123 and brainstorm-ticket fetches the ticket, shows you the fields, and waits for you to confirm them. /start-task prefers the same connected tool. The fetch runs through your connector under your own login, never through this server.

THE CHARTER

One file makes every answer yours.

Drop mentis.project.md in your repo: YAML frontmatter plus prose, versioned next to your code. It’s what makes the answers about your project instead of software in general.

Epics add a middle layer, so goal-fit is asked as a chain: ticket → epic → project goal. An epic your charter doesn’t know gets flagged rather than quietly accepted. No charter at all? The tools still run and tell you.

✓Every context-based claim quotes its source
✓One question at a time, highest value first
✓Missing inputs become questions, never numbers
✓Model-proposed estimates graded A/B/C, marked provisional

mentis.project.md

---

goal:

statement: "Let Northwind engineers get a correct answer from the internal docs in under a minute, without asking a teammate."

northStar: "Median time-to-answer"

users: ["Northwind engineers", "Northwind support engineers on call"]

epics:

- name: "retrieval"

statement: "Find the passages that actually answer the question"

- name: "answer-quality"

statement: "Turn retrieved passages into answers engineers trust"

outOfScope:

- "Training or fine-tuning our own base model"

- "A public-facing chatbot for customers"

definitionOfDone:

- "Tests written and passing"

- "Eval suite run and no regression"

- "Docs / changelog updated"

- "Deployed to staging and QA-signed"

rice:

bands: { high: 8, medium: 3 }

---

WHAT YOU GET

Five tools, one prompt, one resource.

Each one answers a question that usually gets a shrug in refinement.

Every panel below is real output for VAN-604, the ticket the terminal above sends back, after its questions were answered. Epic answer-quality, graded against the charter that ships in the package. Nothing here is written by hand.

interrogate_tickettool

Turns what the ticket verifiably lacks into ranked questions, then asks you only the top one. No form to fill in.

"summary": "5 question(s) selected from what the
 ticket is missing, in priority order."

rank 1 · goal-fit
  trigger: "Goal-fit is never explicit in tickets;
   it must be argued, not assumed."
  cite:    charter goal

rank 2 users · 3 success · 4 evidence · 5 validation

assess_ticket_readinesstool

INVEST rubric plus overlap with your out-of-scope list, banded into ready · needs-work · not-ready.

"readiness": "ready"
"findings": []
"summary": "No blocking gaps from the deterministic
 checks. Apply the INVEST checklist for a
 qualitative pass."

checklist: Independent · Negotiable · Valuable
 Estimable · Small · Testable · Epic-fit

check_definition_of_donetool

Walks your DoD item by item and marks each one covered, unclear or missing, with the evidence behind the call.

"verdict": "gaps"
"summary": "4 of 4 definition-of-done item(s) are
 not clearly addressed. \"Done\" is ambiguous
 until they are."

missing  Tests written and passing
missing  Eval suite run and no regression
missing  Docs / changelog updated
missing  Deployed to staging and QA-signed

score_ticket_valuetool

RICE = (Reach × Impact × Confidence) ÷ Effort, banded by your charter’s thresholds (documented defaults if you haven’t set any). You also get an A/B/C evidence grade and a value/effort quadrant.

"score": 192        (120 × 2 × 0.8) ÷ 1
"band": "high"      bandSource: "charter"
"evidenceGrade": "B"
"quadrant": "quick-win"
"proposedInputs": ["impact", "confidence"]

PROVISIONAL: impact, confidence are LLM
 proposals, not user-stated facts.

decompose_tickettool

Seeds subtasks from signals actually present in the ticket, plus the guardrails a finished 3 to 7 subtask proposal should meet. Read-only, so nothing reaches Jira.

"summary": "3 seed subtask(s) derived from
 verifiable signals."

1  Validate the need: Stream answers from the
   assistant endpoint
2  Stream answers from the assistant endpoint
3  Finish per the Definition of Done

guardrail: "Every subtask needs 2+ acceptance
 criteria a reviewer can check pass/fail."

brainstorm-ticketprompt

A prompt that chains all five in order, grounds every claim, and ends on one composite verdict.

interrogate → readiness → definition of done
 → value → decompose

ends on one verdict:
  build now | clarify first | don't build

Invoke it bare and paste the ticket when asked,
or pass a key (PROJ-123) to fetch it instead.

mentis://charterYour parsed charter, readable on demand, so you can see exactly what the tools are grounding against.

QUICKSTART

Four steps to your first triage.

Access is by request rather than a public registry. Ask, and the built package comes back by email. Nothing to clone, nothing to compile.

01
Install the package
Request access first. Node 22.12+.
```
$ npm install -g ./mcp-mentis-work-0.2.1.tgz
```
02
Register the server
Paste this into .mcp.json at your project root, then restart Claude Code and approve the trust prompt.
.mcp.json
```
{
  "mcpServers": {
    "mentis-work": {
      "command": "mentis-work"
    }
  }
}
```

Write your charter

Fill in goal, epics, scope and DoD.

$ cp "$(npm root -g)/mcp-mentis-work/mentis.project.example.md" ./mentis.project.md

04
Triage your first ticket
Run it bare and paste the ticket when it asks. Or pass a ticket key and let a connected Jira MCP tool fetch it.
```
> /mcp__mentis-work__brainstorm-ticket
```

Ships with two workflow skills. Copy them from the package into your project’s .claude/skills/

/start-task

Triage before you code; on a build verdict it becomes your session todo list, scope-creep watchdog armed.

/finish-task

Checks what you actually built against the definition of done and lists the gaps first.

FAQ

Questions you might have

Does it write to Jira?

No, and it cannot. It holds no credentials and never writes. It proposes; you copy across what survives your review. If you connect a Jira MCP server it can read a ticket by key, but that is your connector doing the reading, under your login. This server still touches nothing.

Where does my ticket text go?

The server runs locally over stdio and makes no network calls of its own. Your text goes exactly where it already goes: your Claude Code session. Connect a Jira MCP server and the fetch happens there instead, on your own credentials, in a separate server you approve and can remove.

Do I need a charter to start?

No, but it is where most of the value comes from. Without one the tools still run and tell you they are ungrounded. With one, the answers are tied to your scope, DoD and thresholds.

Why not just ask Claude directly?

You can, and you will get a fluent answer that does not know your out-of-scope list and may invent a RICE score. This keeps the checks deterministic and the grounding mandatory.

Stop building the wrong ticket well.

Write a charter, then let the next ticket get a proper look before it reaches your editor.

See the setup