Skip to main content
Glama

eazy-ba

A personal Business Analyst as an MCP server.

eazy-ba fills the BA role for solo engineers and small teams: it captures requirements, keeps them organized as plain markdown, and tracks the relationships between personas, requirements, use cases, and user stories so the documentation stays coherent as a project evolves.

Markdown files are the single source of truth — everything lives under docs/ba/, is human-readable, git-diffable, and hand-editable. Relationships are stored in YAML frontmatter, so traceability is always derived, never hand-maintained.

Status: Phase A (interrogative loop). eazy-ba now conducts structured BA interviews before writing anything — every requirement traces back to a decision you made.

Install

Add it to Claude Code with one command — no global install needed:

claude mcp add eazy-ba -- npx -y eazy-ba

That's it. npx fetches and runs the latest version on demand.

Register it as a stdio MCP server:

{
  "mcpServers": {
    "eazy-ba": {
      "command": "npx",
      "args": ["-y", "eazy-ba"]
    }
  }
}

Related MCP server: Requirement Graph MCP

The docs structure

Running ba_init scaffolds:

docs/ba/
├── _index.md                  # status dashboard
├── _config.yml                # docs root + id conventions
├── 01-vision/                 # vision.md, glossary.md
├── 02-stakeholders/personas/  # PER-001-*.md
├── 03-requirements/
│   ├── functional/            # FR-001-*.md
│   └── non-functional/        # NFR-001-*.md
├── 04-use-cases/              # UC-001-*.md
├── 05-stories/                # US-001-*.md (story + Gherkin acceptance criteria)
├── 06-analysis/               # traceability, gap-report, risks, assumptions
└── 07-changelog/              # requirement change history

Stable IDs (FR-001, US-001, PER-001, …) are the backbone; cross-links live in frontmatter (implements, satisfies, refines).

How it works — the interrogation loop

eazy-ba behaves like a Business Analyst: it asks before it writes, and never assumes.

  1. ba_session_start — begin discovery (new project) or stabilize (tighten an existing one).

  2. ba_assess — returns the questions to ask you. It writes nothing.

  3. You answer; ba_record_answers saves each answer as a traceable decision (DEC-###).

  4. ba_apply — turns those decisions into documents. Every document cites the decisions behind it; nothing is written without a recorded answer.

  5. Repeat until ba_status reports stable (no open questions, no gaps).

Every requirement, story, and acceptance criterion traces back to a decision you made.

Tools

Tool

Purpose

ba_init

Scaffold the docs/ba/ tree in a project.

ba_session_start

Start or resume a BA session (mode: discovery | stabilize).

ba_assess

Analyze current state; return prioritized questions to ask the user. Creates nothing.

ba_record_answers

Save the user's answers as traceable decisions (DEC-###).

ba_apply

Materialize/update documents from recorded decisions. Rejects artifacts with no derived_from.

ba_status

Report open questions, gaps, pending decisions, and overall stability.

ba_get

Fetch one artifact by ID.

ba_list

List/filter artifacts by type, status, priority, or tag.

Each artifact carries MoSCoW priority (must / should / could / wont) and a status (draft → reviewed → approved → implemented / obsolete).

Configuration

docs/ba/_config.yml:

docsRoot: docs/ba   # relative to the project root, or an absolute path
idStart: 1          # first numeric ID

Roadmap

  • Phase 2 — Analysis: deterministic structural gap detection + shipped BA checklists, requirement quality linting, traceability matrix generation, change impact analysis.

  • Phase 3 — Smoothers: intake from brain dumps, adaptive elicitation interviews, codebase grounding, and Mermaid visualizations.

Development

npm install
npm test        # vitest, TDD throughout
npm run build   # tsc -> dist/

License

MIT

Available Tools

12 tools
ba_applyB

Materialize/update documents from recorded decisions. Every artifact must cite derived_from decisions.

Inputs: artifacts (required), projectRoot (required).

ba_assessB

Analyze current state and return the questions to ask the user. Writes no BA documents (it only updates session state).

Inputs: projectRoot (required).

ba_finalizeA

Promote every draft BA document (persona/fr/nfr/use-case/story/glossary/tech-surface) to status 'reviewed' in one batch — the clean 'here are your docs' step. Idempotent and repeatable: a second call with nothing in draft is a no-op, and it promotes again after a change loop re-opens work. Only changes status; never touches backing. Returns what was promoted.

Inputs: projectRoot (required).

ba_getC

Get one artifact by id.

Inputs: id (required), projectRoot (required).

ba_groundA

Ground flow (ground session only): record code observations the host agent read. Each is { fact_kind, claim, anchors }. Auto-accepts ONLY existence facts the server can re-verify (entity-exists | dependency-present) whose anchors resolve on disk and sit inside the session read scope — recorded as confirmed/code-verified. Everything else (route/middleware/config-key, anything mislabeled, out-of-scope or unresolvable anchors) is recorded as an inferred+open observation that the user must confirm. Idempotent by (anchors+claim).

Inputs: projectRoot (required), observations (required).

ba_impactA

For a mid-project change: report blast radius, conflicts, severity, consequences, and change questions for the given target ids. Creates nothing.

Inputs: targets (required), projectRoot (required).

ba_initD

Scaffold the docs/ba BA docs tree.

Inputs: projectRoot (required).

ba_listC

List artifacts filtered by type/status/priority/tag.

Inputs: projectRoot (required), tag, type, status, +1 more.

ba_planA

Declare or retire agent/user coverage topics (the visible, steerable coverage plan on top of the floor). Declaring is idempotent; retiring stops a topic from gating stability. Returns the current open plan.

Inputs: operations (required), projectRoot (required).

ba_record_answersC

Record the user's answers as traceable decisions.

Inputs: items (required), projectRoot (required), bulk.

ba_session_startA

Start or resume a BA session (mode: discovery | stabilize | change | ground). For ground mode, pass readScope: the user-supplied paths/globs (relative to projectRoot) the BA may read; it is persisted to the session and bounds what ba_ground can auto-accept.

Inputs: mode (required), projectRoot (required), readDeny, readScope.

ba_statusB

Report open questions, gaps, pending decisions, the open coverage plan, and stability.

Inputs: projectRoot (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    B3.3/5.0

    Scored across 12 tools

    Disambiguation5/5

    Each tool has a distinct purpose: e.g., ba_assess queries state, ba_record_answers stores user decisions, ba_impact analyzes change effects. No two tools overlap in functionality, making selection unambiguous.

    Naming Consistency5/5

    All tools follow a consistent 'ba_verb_noun' pattern with snake_case (e.g., ba_session_start, ba_record_answers). No mixing of conventions or inconsistent verb styles.

    Tool Count5/5

    With 12 tools covering multiple BA modes (discovery, stabilize, change, ground), the count is well-scoped. Each tool serves a clear step in the workflow without bloat or missing essentials.

    Completeness4/5

    The set covers the full BA lifecycle: session management, assessment, decision recording, artifact materialization, finalization, querying, planning, and impact analysis. Minor gap: no explicit tool for direct manual artifact creation, but the workflow via decisions and finalization covers it.

    Related MCP Connectors

    Related MCP Servers