Conducted MCP

io.github.Mostov82Published by GitHub account Mostov82v0.1.1Updated Oct 24, 2026

Stateless advisor + validator for Conducted Development: kickoff, artifact validation, rule checks.

VerifiedStreamable HTTPWeb executableProductivity & WorkflowDeveloper Tools

Overview

AI-generated overview

Stateless advisor and validator that guides an AI agent through the Conducted Development project methodology: kickoff, artifact checks and rule judgments.

What you can do
  • Run a branched kickoff interview and assemble planning templates, decision log and agent conventions for new or existing codebases
  • Validate goal briefs, intent docs, session logs and standups against required structure and report missing sections and warnings
  • Get ordered phase procedures with what to read first and escalation points
  • Check whether a standup is due, whether all gates are resolved before a session begins, and whether a decision belongs in the decision log
  • Read the methodology's guides, templates and conventions as read-only resources
When to use it
Useful when an agent is planning and tracking a software project and you want consistent rituals: structured kickoff, per-session intent docs, standups and a decision log. It suits solo developers or small teams who want the methodology's rules checked rather than enforced.
Requirements
Runs either as a local process via npx (Node.js) or as a hosted Streamable HTTP endpoint connected by URL. No accounts, API keys, environment variables or headers are declared. The agent supplies all artifact text and facts itself; the server reads no files.
Before you install
The server is advisory only and cannot enforce anything, so an agent with file access can ignore its judgments. Artifact text and project facts you pass in are sent to the server, and to the hosted endpoint if you use it. It does not write, send or delete data itself.

Installation

In SourceWeft

  1. Open Conducted MCP in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/io.github.Mostov82%2Fconducted-mcp/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "conducted": {
      "type": "http",
      "url": "https://conducted-mcp.jonathanmostov.workers.dev/mcp"
    }
  }
}

README

Conducted MCP

An MCP server that helps an AI agent plan and track a software project the way a disciplined team would — and it was built using the very methodology it ships.

Conducted MCP exposes Conducted Development — a lightweight, intent-driven methodology — to any MCP-capable agent (Claude Desktop, Cursor, and others). It is a stateless advisor + validator: it holds no project data and touches no files or git. The agent does all the I/O; the server supplies judgment — validate this artifact, is a standup due, what's the procedure for this phase, does this decision belong in the log.

The differentiator: this repository's own work/ folder — goal briefs, intent docs, a decision log, and cycle standups — was produced under the methodology the tool implements. It is the proof of process, not a sample.

What it does

A connecting agent gets, on demand:

  • A guided kickoff (kickoff prompt + kickoff_questions / kickoff_plan tools) — a branching Q&A that bootstraps a project's planning structure for greenfield or existing codebases. For existing code the agent inspects the repo and the server pre-fills answers so the human confirms rather than authors from scratch.
  • Strict artifact validation (validate_artifact) — submit a goal brief / intent doc / session log / standup, get back { valid, missing, warnings }.
  • Phase procedures (next_procedure) — the ordered steps, what to read first, and the escalation points for wherever the agent is in the loop.
  • Mechanical rule checks (standup_due, evaluate_gate, decision_log_guidance) — the rituals a solo practitioner most often lets slide, as stateless judgments over supplied facts.

The methodology's guides, templates, and conventions are served as read-only resources (conducted://guide/*, conducted://template/*, conducted://conventions) so an agent can learn the rules in-band.

Why it's built this way (Model C)

The server cannot enforce — an agent always has direct file access. So instead of pretending to be a gatekeeper, it is an advisor: pure functions returning judgments and procedures, no side effects, nothing to host with no data and no auth-to-data. That makes it portable, trivially testable, and cheap to run locally or remotely. The reasoning is written up in docs/DESIGN_SKETCH.md and the resolved trade-offs in DECISIONS.md.

Quick start

Published on npm as conducted-mcp — runs with zero install via npx.

Add the server to your MCP client. Claude Desktop (claude_desktop_config.json) or Cursor (.cursor/mcp.json):

json
{  "mcpServers": {    "conducted": {      "command": "npx",      "args": ["-y", "conducted-mcp"]    }  }}

Then ask your agent to "run the Conducted kickoff for this project," or call any tool directly.

Or connect to the hosted endpoint (no install)

A stateless Streamable HTTP endpoint runs live on Cloudflare Workers — connect by URL, nothing to install:

json
{  "mcpServers": {    "conducted": {      "url": "https://conducted-mcp.jonathanmostov.workers.dev/mcp"    }  }}

Because the server is stateless and holds no data (Model C), the endpoint is safe to run unauthenticated, guarded by rate limiting.

Demo

See docs/DEMO.md for a real transcript of the kickoff flow — the front-door prompt, the branched interview, and the phase procedures — captured verbatim from the running server.

Development

bash
npm installnpm run build     # bundles the methodology text, then strict tscnpm test          # vitestnpm run lint      # eslint + prettiernpm start         # run the stdio server

The server is TypeScript on the official @modelcontextprotocol/sdk, ESM, strict mode. See CONTRIBUTING.md for the layout and conventions.

The methodology, in the repo

License

MIT © 2026 Jonathan Mostov

Source: README.md at commit 6d2ed66

Tools

7

validate_artifact

Validate a methodology artifact

Strictly check whether a Conducted Development artifact's text satisfies the methodology's required structure. Supply the artifact's type and its full text (the server never reads files). Returns { valid, missing, warnings }: `missing` lists required sections that are absent, empty, or contain only unmodified template placeholder text (blocking); `warnings` lists sections that are present but look thin (advisory, non-blocking). `valid` is true iff `missing` is empty.

Parameterscontentrequiredartifact_typerequired

kickoff_questions

Get the kickoff interview question set

Return the branched kickoff interview (DECISIONS.md D3/D4). Supply `project_type`: 'greenfield' asks the full set; 'brownfield' uses the agent-supplied `detected` facts (language, framework, tests, CI, existing docs) to pre-fill candidates and drop fully-inferable questions — except LOCKED_DOCS, which is always asked because it is human judgment. Returns { project_type, questions, inferred, notes }; the server reads no files.

Parametersdetectedproject_typerequired

kickoff_plan

Assemble the kickoff file plan

Assemble, from the bundled templates, the four `_template.md` copies (front-matter tokens replaced), `decision-log.md`, and a filled `AGENT_CONVENTIONS.md` (kickoff guide Steps 2–5). Supply `project_type`, the interview `answers`, optional `detected` (brownfield pre-fill fallback), and optional `existing` (the agent's inventory of files already present). Returns { files: [{ path, content, action }], missing, open_questions, warnings }. The plan is ready iff `missing` is empty (D5 strict); a file with any unresolved {{…}} token is reported in `missing`. Idempotent: already-present files are 'review'/'skip', never overwritten. The server returns content + paths only — it writes nothing (Model C, D2/D6).

Parametersanswersrequireddetectedexistingproject_typerequired

next_procedure

Get the procedure for a methodology phase

Return the ordered procedure for where the agent is in the methodology loop. Supply `phase` (one of: kickoff, goal_brief, intent_doc, session_open, session_active, session_close, standup) and optional `facts` (e.g. a ticket id) to tailor the output. Returns { steps, reads_first, escalation_points, notes? } sourced from the bundled guides and conventions — the procedure half of advisor + validator. The server reads no files.

Parametersfactsphaserequired

standup_due

Judge whether a standup is due

Given agent-supplied facts, decide whether a standup is due. Triggers in priority order: a deliverable gate reached → 'gate'; else a dependency intersection → 'intersection'; else more than five working days since the last standup → 'weekly'; else 'none'. Working days are an input (the working week varies by team), never computed from a calendar. Returns { due, reason, detail }.

Parameterstodaygate_reachedlast_standup_datedependency_intersectionworking_days_since_last_standup

evaluate_gate

Evaluate whether a goal brief's gates are resolved

Encode the goal-brief rule that no session may begin while any gate is open. Supply either a structured `gates` list ([{ id, resolved }]) or a goal-brief `content` string, in which case the GATE LIST checkboxes (- [ ] / - [x]) are parsed. Returns { all_resolved, unresolved, may_begin } where may_begin === all_resolved. The server reads no files — the content is agent-supplied.

Parametersgatescontent

decision_log_guidance

Judge whether a situation belongs in the Decision Log

Encode the Decision-Log 'when to use it' rules. Set whichever apply: `escalation_fired`, `gate_resolved_cross_cutting`, `affects_multiple_tickets`, `override_architectural`, `confined_to_one_session`. Returns { should_log, reason, entry_template? }; when should_log is true the Context/Trigger/Decision/Rationale/Affects skeleton is returned. A decision confined to one session does not need an entry — the session notes suffice.

Parametersescalation_firedoverride_architecturalconfined_to_one_sessionaffects_multiple_ticketsgate_resolved_cross_cutting

Version history

1
  1. v0.1.1LatestSep 16, 2026

Score

100% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts