Koskamo

Conducted MCP

A stateless advisor and validator MCP server for the Conducted Development methodology. It provides kickoff assistance, artifact validation, and mechanical rule checks for rituals like standups and decision logs. The server serves methodology guides, templates, and conventions as read-only resources, allowing agents to learn rules in-band without side effects or data storage.

Endpoint and access

No sign-in to connect and list tools. Individual tools may still need a vendor account, credentials, or permissions; check the documented prerequisites.

Conducted MCP logo, by Jonathan MostovCommunity listingStreamable HTTPNo sign-inEndpoint checked 2026-11-07Published by Jonathan Mostov
MCP endpoint (Streamable HTTP)
https://conducted-mcp.jonathanmostov.workers.dev/mcp
Vendor documentation

What its tools do

7 tools, grouped by the hints the server advertises. Hints are self-declared, not verified behavior.

Not annotated (7)

7 of 7 have a description · 0 of 7 declare behavior hints · 5 of 7 with parameters document them all

Checks and signals

Each line is separate evidence, not a trust score.

  • Passed Endpoint answered the live check ·
  • Availability 1 of 1 checks passed in 30 days

What you can do with it

  • Run the Conducted kickoff for a project
  • Perform mechanical rule checks on standups and gates
  • Access methodology guides and templates
  • Validate artifacts against development conventions

Source and maintenance

Community listingRegistry 0.1.1
mcp-registry: io.github.Mostov82/conducted-mcp@0.1.1Source repository
Maintenance checked

Protocol and capabilities

Server
conducted-mcp 0.1.0
MCP protocol negotiated in check
2025-11-25
Tools
7 advertised
Resources
12 advertised
Resource templates
0 advertised
Prompts
1 advertised
Server-advertised capabilities
{
  "tools": {
    "listChanged": true
  },
  "prompts": {
    "listChanged": true
  },
  "resources": {
    "listChanged": true
  }
}

Tools

7 advertised

validate_artifact — Validate a methodology artifact
Advertised by the server during the last successful anonymous check.

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.

validate_artifact input schema
{
  "type": "object",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "required": [
    "artifact_type",
    "content"
  ],
  "properties": {
    "content": {
      "type": "string",
      "description": "The full markdown text of the artifact to validate."
    },
    "artifact_type": {
      "enum": [
        "goal_brief",
        "intent_doc",
        "session_log",
        "standup"
      ],
      "type": "string",
      "description": "Which artifact to validate."
    }
  },
  "additionalProperties": false
}
kickoff_questions — Get the kickoff interview question set
Advertised by the server during the last successful anonymous check.

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.

kickoff_questions input schema
{
  "type": "object",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "required": [
    "project_type"
  ],
  "properties": {
    "detected": {
      "type": "object",
      "properties": {
        "ci": {
          "type": "string"
        },
        "language": {
          "type": "string"
        },
        "framework": {
          "type": "string"
        },
        "project_name": {
          "type": "string"
        },
        "existing_docs": {
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "test_framework": {
          "type": "string"
        },
        "package_manager": {
          "type": "string"
        }
      },
      "description": "Facts the agent detected by inspecting the repo (brownfield only).",
      "additionalProperties": false
    },
    "project_type": {
      "enum": [
        "greenfield",
        "brownfield"
      ],
      "type": "string",
      "description": "'greenfield' or 'brownfield'."
    }
  },
  "additionalProperties": false
}
kickoff_plan — Assemble the kickoff file plan
Advertised by the server during the last successful anonymous check.

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).

kickoff_plan input schema
{
  "type": "object",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "required": [
    "project_type",
    "answers"
  ],
  "properties": {
    "answers": {
      "type": "object",
      "description": "Confirmed interview answers keyed by token id (e.g. PROJECT_NAME, LOCKED_DOCS).",
      "additionalProperties": {
        "anyOf": [
          {
            "type": "string"
          },
          {
            "type": "array",
            "items": {
              "type": "string"
            }
          }
        ]
      }
    },
    "detected": {
      "type": "object",
      "properties": {
        "ci": {
          "type": "string"
        },
        "language": {
          "type": "string"
        },
        "framework": {
          "type": "string"
        },
        "project_name": {
          "type": "string"
        },
        "existing_docs": {
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "test_framework": {
          "type": "string"
        },
        "package_manager": {
          "type": "string"
        }
      },
      "description": "Facts the agent detected by inspecting the repo (brownfield only).",
      "additionalProperties": false
    },
    "existing": {
      "type": "object",
      "properties": {
        "files": {
          "type": "array",
          "items": {
            "type": "string"
          }
        }
      },
      "description": "Agent inventory of files already present in the target (for idempotent re-runs).",
      "additionalProperties": false
    },
    "project_type": {
      "enum": [
        "greenfield",
        "brownfield"
      ],
      "type": "string",
      "description": "'greenfield' or 'brownfield'."
    }
  },
  "additionalProperties": false
}
next_procedure — Get the procedure for a methodology phase
Advertised by the server during the last successful anonymous check.

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.

next_procedure input schema
{
  "type": "object",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "required": [
    "phase"
  ],
  "properties": {
    "facts": {
      "type": "object",
      "properties": {
        "ticket": {
          "type": "string"
        },
        "work_dir": {
          "type": "string"
        },
        "goal_brief": {
          "type": "string"
        }
      },
      "description": "Optional facts to weave into the procedure (e.g. ticket id, work dir).",
      "additionalProperties": false
    },
    "phase": {
      "enum": [
        "kickoff",
        "goal_brief",
        "intent_doc",
        "session_open",
        "session_active",
        "session_close",
        "standup"
      ],
      "type": "string",
      "description": "Which phase of the methodology loop the agent is in."
    }
  },
  "additionalProperties": false
}
standup_due — Judge whether a standup is due
Advertised by the server during the last successful anonymous check.

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 }.

standup_due input schema
{
  "type": "object",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "properties": {
    "today": {
      "type": "string"
    },
    "gate_reached": {
      "type": "boolean"
    },
    "last_standup_date": {
      "type": "string"
    },
    "dependency_intersection": {
      "type": "boolean"
    },
    "working_days_since_last_standup": {
      "type": "number"
    }
  },
  "additionalProperties": false
}
evaluate_gate — Evaluate whether a goal brief's gates are resolved
Advertised by the server during the last successful anonymous check.

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.

evaluate_gate input schema
{
  "type": "object",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "properties": {
    "gates": {
      "type": "array",
      "items": {
        "type": "object",
        "required": [
          "id",
          "resolved"
        ],
        "properties": {
          "id": {
            "type": "string"
          },
          "resolved": {
            "type": "boolean"
          }
        },
        "additionalProperties": false
      },
      "description": "Structured gate list."
    },
    "content": {
      "type": "string",
      "description": "A goal-brief markdown string whose GATE LIST is parsed."
    }
  },
  "additionalProperties": false
}
decision_log_guidance — Judge whether a situation belongs in the Decision Log
Advertised by the server during the last successful anonymous check.

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.

decision_log_guidance input schema
{
  "type": "object",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "properties": {
    "escalation_fired": {
      "type": "boolean"
    },
    "override_architectural": {
      "type": "boolean"
    },
    "confined_to_one_session": {
      "type": "boolean"
    },
    "affects_multiple_tickets": {
      "type": "boolean"
    },
    "gate_resolved_cross_cutting": {
      "type": "boolean"
    }
  },
  "additionalProperties": false
}

Prompts

1 advertised

kickoff — Guided project kickoff

Advertised by the server during the last successful anonymous check.

Walk the connecting agent through bootstrapping a project's Conducted planning structure: read/inspect the project (greenfield vs brownfield), call kickoff_questions, interview the human, call kickoff_plan, write the files, then verify (no stray {{ tokens) and surface the human-judgment items. The server advises; the agent does all I/O (Model C).

project_path
Optional path to the project being set up, for the agent's reference.

Resources

12 advertised

guide-kickoff — Guide: Kickoff

Advertised by the server during the last successful anonymous check.

How to bootstrap a project under the Conducted Development methodology.

guide-kickoff URI
conducted://guide/kickoff

MIME type: text/markdown

guide-goal-brief — Guide: Goal Brief

Advertised by the server during the last successful anonymous check.

How to author a Goal Brief (business goal → intent → DoD → gates → decomposition).

guide-goal-brief URI
conducted://guide/goal-brief

MIME type: text/markdown

guide-intent-doc — Guide: Intent Document

Advertised by the server during the last successful anonymous check.

How to author an intent document (the per-ticket contract).

guide-intent-doc URI
conducted://guide/intent-doc

MIME type: text/markdown

guide-session — Guide: Session

Advertised by the server during the last successful anonymous check.

How to run and log a working session under the methodology.

guide-session URI
conducted://guide/session

MIME type: text/markdown

guide-standup — Guide: Standup

Advertised by the server during the last successful anonymous check.

How and when to run a standup (the ritual that lets the methodology learn).

guide-standup URI
conducted://guide/standup

MIME type: text/markdown

template-goal-brief — Template: Goal Brief

Advertised by the server during the last successful anonymous check.

Fill-in template for a Goal Brief.

template-goal-brief URI
conducted://template/goal-brief

MIME type: text/markdown

template-intent-doc — Template: Intent Document

Advertised by the server during the last successful anonymous check.

Fill-in template for an intent document.

template-intent-doc URI
conducted://template/intent-doc

MIME type: text/markdown

template-session-log — Template: Session Log

Advertised by the server during the last successful anonymous check.

Fill-in template for a session log.

template-session-log URI
conducted://template/session-log

MIME type: text/markdown

template-standup — Template: Standup

Advertised by the server during the last successful anonymous check.

Fill-in template for a standup.

template-standup URI
conducted://template/standup

MIME type: text/markdown

template-decision-log — Template: Decision Log

Advertised by the server during the last successful anonymous check.

Fill-in template for the append-only decision log.

template-decision-log URI
conducted://template/decision-log

MIME type: text/markdown

template-agent-conventions — Template: Agent Conventions

Advertised by the server during the last successful anonymous check.

Fill-in template for a project's AGENT_CONVENTIONS.md.

template-agent-conventions URI
conducted://template/agent-conventions

MIME type: text/markdown

conventions — Conducted MCP — Agent Conventions

Advertised by the server during the last successful anonymous check.

This project's filled-in AGENT_CONVENTIONS.md.

conventions URI
conducted://conventions

MIME type: text/markdown

90-day uptime

A lightweight connection check about every six hours, sampled on hosts with many listings. It shows the server answered, not that its tools work.

Too few checks for a percentage yet (1 of 1 answered).

  1. 2026-11-07: 1 of 1 checks answered

30-day availability

Aggregated from read-only remote checks; this is not a tool-execution or security guarantee.

Successful checks
1 of 1 (100%)
Average latency
436 ms
95th percentile latency
436 ms

Maintenance history

Public check and source-refresh events. Editorial and ownership records remain private.

  • · probe · passed · 436 ms · metadata changed · 7 tool(s), 12 resource(s), 0 resource template(s), 1 prompt(s)

Connect from your client

Each snippet registers the same endpoint; pick the client you use.

This server is operated by the named third party. Listing and endpoint checks are not an endorsement or a security audit. Review the operator's permissions, terms, and data handling before connecting. How listings are checked and corrected.

Claude Code

Run this once in a terminal. It registers the remote server. Use --scope project to write .mcp.json for the repo.
Claude Code configuration
claude mcp add --transport http conducted-mcp-workers https://conducted-mcp.jonathanmostov.workers.dev/mcp

Codex

Run this once. Codex stores MCP servers in ~/.codex/config.toml (or .codex/config.toml in a trusted project).
Codex configuration
codex mcp add conducted-mcp-workers --url https://conducted-mcp.jonathanmostov.workers.dev/mcp

Cursor

Merge this server into .cursor/mcp.json in your project, then enable conducted-mcp-workers in your MCP settings.
Cursor configuration
{
  "mcpServers": {
    "conducted-mcp-workers": {
      "url": "https://conducted-mcp.jonathanmostov.workers.dev/mcp"
    }
  }
}

Cline

Merge this into cline_mcp_settings.json (Cline → MCP Servers → Configure).
Cline configuration
{
  "mcpServers": {
    "conducted-mcp-workers": {
      "type": "streamableHttp",
      "url": "https://conducted-mcp.jonathanmostov.workers.dev/mcp",
      "disabled": false
    }
  }
}

VS Code

Merge this server into .vscode/mcp.json. Use MCP: List Servers to start conducted-mcp-workers and inspect its tools.
VS Code configuration
{
  "servers": {
    "conducted-mcp-workers": {
      "type": "http",
      "url": "https://conducted-mcp.jonathanmostov.workers.dev/mcp"
    }
  }
}

Gemini CLI

Run this once. It writes .gemini/settings.json in the current project; pass --scope user for ~/.gemini/settings.json.
Gemini CLI configuration
gemini mcp add --transport http conducted-mcp-workers https://conducted-mcp.jonathanmostov.workers.dev/mcp

Claude Desktop

Open Claude Settings > Connectors > Add custom connector, enter this server URL and enable it for the conversation. This is a manual remote-connector handoff, not a desktop JSON configuration.
Claude Desktop configuration
https://conducted-mcp.jonathanmostov.workers.dev/mcp

Windsurf

Merge this into ~/.codeium/windsurf/mcp_config.json, then refresh MCP in Cascade. Windsurf remote servers use serverUrl, not url.
Windsurf configuration
{
  "mcpServers": {
    "conducted-mcp-workers": {
      "serverUrl": "https://conducted-mcp.jonathanmostov.workers.dev/mcp"
    }
  }
}

Let your agent find its tools

Find servers like Conducted MCP from your agent. Add Koskamo once to search the index for endpoints, access requirements, and client setup. Public discovery needs no key.

Connect Koskamo Explore workflows
See all 8,313