HestAI-MCP
Provides tools for posting structured review comments to GitHub Pull Requests.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@HestAI-MCP start a new session for implementing user login"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
HestAI-MCP
Governance and session management layer of the HestAI ecosystem — pre-release, B1 Foundation phase
Overview
HestAI-MCP is the governance and session management layer of the HestAI ecosystem — a five-system stack for AI-assisted software development. It is currently pre-release at B1 (Foundation phase): functional and in daily use, but still discovering its full scope.
Its role in the ecosystem: knows WHO agents are and HOW they should behave — provider-agnostic. It does not spawn CLIs or know which model runs underneath; that is the workbench's job.
What it does today:
Injects system governance (
.hestai-sys/) into projects at runtime — agent constitutions, skills, rules — without copy-pasting between projectsTracks sessions (
clock_in/clock_out) and archives transcripts in OCTAVE formatBootstraps agent binding (
bind)Posts structured review comments to GitHub PRs (
submit_review)
What it's building toward: persistent memory across sessions (the context feedback loop requires context_update, planned Phase 4), Orchestra Map dependency tracking (ADR-0034 MVP validated, automation not yet built), and document routing (document_submit, Phase 4).
Where it fits: built on octave-mcp (document format foundation), works alongside odyssean-anchor-mcp (identity binding ceremony, merger planned), debate-hall-mcp (structured deliberation), and hestai-workbench (execution/UI layer).
Related MCP server: Agent Harness Kit
Architecture
YOUR PROJECT (using HestAI)
├── .hestai-sys/ # TIER 1: SYSTEM (read-only, injected by MCP at runtime, gitignored)
│ ├── CONSTITUTION.md # Immutable laws
│ ├── governance/ # Rules, North Stars
│ ├── library/
│ │ ├── agents/ # Agent definitions
│ │ ├── skills/ # Capability definitions
│ │ └── patterns/ # Reusable solution patterns
│ └── templates/ # Document templates
│
├── .hestai/ # TIER 2: PROJECT GOVERNANCE (committed, PR-controlled)
│ ├── north-star/ # Project North Star
│ ├── decisions/ # Architectural Decision Records
│ ├── rules/ # Project-wide standards
│ └── state/ → .hestai-state/ # TIER 3: WORKING STATE (symlink, gitignored)
│ ├── context/ # Living context files (generated by clock_in)
│ ├── sessions/
│ │ ├── active/ # Current sessions
│ │ └── archive/ # Completed sessions (OCTAVE compressed)
│ └── reports/ # Generated reports
│
├── docs/ # Developer documentation (ADRs, guides)
└── src/ # Your codeNote for AI Agents: Even though .hestai-sys/ is gitignored, you can still read it! Use:
Read .hestai-sys/README.md- Start here for governance overviewGlob .hestai-sys/**/*.md- Discover all governance files
Key Principle: Single Writer
All .hestai/state/ writes go through MCP tools. No direct file creation.
Agent → MCP Tool (clock_in/clock_out/bind) → System Steward → FilesThis prevents:
Multi-agent conflicts
Governance drift
Inconsistent documentation
The Three Tiers
Tier | Location | Git | Mutability |
1: System Governance |
| Gitignored | Read-only (MCP-injected at runtime) |
2: Project Governance |
| Committed | Human via PR |
3: Working State |
| Gitignored | Via MCP tools (clock_in/clock_out) |
For detailed architecture, see docs/ARCHITECTURE.md.
MCP Tools
Tool | Purpose | Status |
| Start session, create session dir, return context paths | Implemented |
| End session, compress transcript to OCTAVE, archive | Implemented |
| Lightweight agent binding bootstrap | Implemented |
| Post structured review comments to GitHub PRs | Implemented |
| Route docs to correct location | Planned (Phase 4) |
| Update context with conflict resolution | Planned (Phase 4) |
Documentation Format
When to use OCTAVE (.oct.md)
Agent constitutions
Governance rules
North Stars
Context files (PROJECT-CONTEXT, etc)
Session archives
When to use Markdown (.md)
Developer guides
ADRs
READMEs
Setup instructions
Decision: Primary audience AI agents? → .oct.md. Human developers? → .md
Quick Start
# Clone and install (uv recommended)
git clone https://github.com/elevanaltd/HestAI-MCP.git
cd hestai-mcp
uv sync --all-extras
# Run tests
.venv/bin/python -m pytest
# Check quality
.venv/bin/python -m ruff check src tests scripts && .venv/bin/python -m mypy src && .venv/bin/python -m black --check src tests scriptsMCP Configuration
Default behavior (simplest): .hestai-sys is created in the current working directory where the server runs:
{
"mcpServers": {
"hestai": {
"command": "python",
"args": ["-m", "hestai_mcp.mcp.server"]
}
}
}Optional override: Control location via HESTAI_PROJECT_ROOT env var:
# .env file (optional - only if you want a custom location)
HESTAI_PROJECT_ROOT=/path/to/shared/locationOpt-in: Governance injection only runs if the project has a
.hestai/directory orHESTAI_GOVERNANCE_ENABLED=truein.env. New projects must opt in explicitly.
Design: Follows the debate-hall pattern - creates governance in CWD by default, just like
./debates/. Each project/worktree gets its own.hestai-sysunless explicitly configured otherwise.
Governance Rules
Documentation placement is governed by rules injected to .hestai-sys/governance/rules/ (source: src/hestai_mcp/_bundled_hub/governance/rules/):
Rule | Document | Purpose |
Visibility |
| Where docs belong (product placement) |
Hub Authoring |
| What goes in system governance ( |
Naming |
| How to name files |
Format | In visibility-rules | When to use OCTAVE vs Markdown |
Development Status
✅ Phase 0-2: Foundation, porting, MCP server
✅ Phase 2.5: Hub architecture, bundled governance
✅ Odyssean Anchor: Agent identity binding (ADR-0036)
✅ Clock tools: Session lifecycle with AI synthesis
✅ Submit review: GitHub PR review comment tool
🚧 Phase 3: Single writer tools (document_submit, context_update)
🚧 Phase 5: Fractal refactor and modularization (ADR-0184)
Related
docs/ARCHITECTURE.md - Detailed architecture
License
Apache License 2.0 - see LICENSE for details.
"Odyssean Anchor" is a registered trademark of Shaun Buswell - see docs/trademarks.md for usage guidelines.
Available Tools
4 toolsoctave_compile_grammarA
Compile OCTAVE schema or contract to constraint grammar. Supports GBNF (llama.cpp) and JSON Schema (vLLM) output formats. Provide either a builtin schema name or inline OCTAVE content.
Inputs: format, schema, content.
octave_ejectA
Eject OCTAVE content with projection modes. Supports canonical, authoring, executive, and developer views. Can generate templates when content is null. Output formats: octave, json, yaml, markdown, gbnf.
Inputs: schema (required), mode, format, content, +1 more.
octave_validateA
Schema check + repair suggestions for OCTAVE content. Validates content against schema, returns canonical form with optional repairs. Focus on I3 (Mirror Constraint) and I5 (Schema Sovereignty).
Inputs: schema (required), fix, compact, content, +5 more.
octave_writeA
Unified entry point for writing OCTAVE files. Handles creation (new files) and modification (existing files). Use content for full payload, changes for delta updates. Omit both content and changes to normalize an existing file in-place. Replaces octave_create and octave_amend.
Inputs: target_path (required), schema, changes, content, +9 more.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 4 tools
Each tool has a distinct, non-overlapping purpose: grammar compilation, content ejection, validation, and writing. No ambiguity.
All tools follow a consistent 'octave_verb' pattern with clear action nouns (compile_grammar, eject, validate, write).
4 tools is well-scoped for a domain-specific server covering compilation, validation, output, and file manipulation.
The tool set covers the core lifecycle of OCTAVE content: compile, validate, output (eject), and write (create/modify/normalize). No obvious gaps.
Maintenance
Related MCP Connectors
The team layer for AI coding agents: shared contracts, collision alerts, E2EE sessions.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Register, deploy, review, and govern internal applications built with coding agents.
Governance copilot for AI-assisted coding. 72 packs, 532 rules, proof bundles.
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables coding agents to run persistent, budgeted work sessions with dependency graphs, human decision queues, required validation, and clean handoffs for autonomous or human-in-the-loop execution.16MIT
- AlicenseNot gradedqualityAmaintenanceEnables AI coding providers to run structured multi-agent workflows with shared documents, tracked tasks, handoffs, and health-gated completion.29 npmMIT
- AlicenseNot gradedqualityAmaintenanceEnables AI coding providers to run structured multi-agent workflows with specs, tracked tasks, handoffs, health gates, and audited repair mode.29 npmMIT
- FlicenseNot gradedqualityAmaintenanceEnables AI coding providers to run structured multi-agent workflows with use cases, specifications, tracked tasks, handoffs, and health-gated completion.-