How do I use Conducted MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Conducted MCP validate my goal brief" 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.

Conducted MCP

by Mostov82

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

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.

Related MCP server: vibe-guard

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

{
  "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:

{
  "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

npm install
npm run build     # bundles the methodology text, then strict tsc
npm test          # vitest
npm run lint      # eslint + prettier
npm 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

work/goal-briefs/ — the goal briefs that drove this build
work/intent-docs/ — one per ticket, the per-session contracts
work/standups/ — cycle-gate standups
work/decision-log.md — the append-only record of decisions
AGENT_CONVENTIONS.md — how every session runs, model- and tool-agnostic

License

Available Tools

7 tools

decision_log_guidanceJudge whether a situation belongs in the Decision LogAInspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`escalation_fired`	No
`override_architectural`	No
`confined_to_one_session`	No
`affects_multiple_tickets`	No
`gate_resolved_cross_cutting`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the return structure (should_log, reason, entry_template) and the rule that confined_to_one_session means no entry needed. Since no annotations are provided, the description carries the full burden; it adequately describes the behavior without contradicting any structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences: purpose, input flags, and output structure. It is front-loaded with the core purpose and provides necessary details without extraneous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description covers the essential aspects: input flags, output fields, and the special case for confined_to_one_session. It lacks detailed explanation of each flag's definition but is sufficient for understanding the tool's role.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It lists all five parameters as 'whichever apply' but does not define what each condition (e.g., gate_resolved_cross_cutting) means. This adds minimal semantics beyond the parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool encodes rules for deciding whether a situation belongs in the Decision Log. It lists the boolean flags and explains the return value, making the purpose specific and distinct from sibling tools which involve gates, plans, or validation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use: when you need to evaluate if a decision should be logged. It provides a specific guideline that a decision confined to one session does not need an entry. However, it does not explicitly exclude use cases or compare with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

evaluate_gateEvaluate whether a goal brief's gates are resolvedAInspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`gates`	No	Structured gate list.
`content`	No	A goal-brief markdown string whose GATE LIST is parsed.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that the server reads no files (agent-supplied content) and details the return shape. Without annotations, it carries the burden well, though it does not mention idempotency or side effects (likely none). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core rule, no unnecessary words. Every sentence adds critical information: rule, input options, output shape, and server behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all essential aspects: purpose, input alternatives, parsing behavior, output structure, and server constraint. Without an output schema, the description fully defines return values. Complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions are present for both parameters (100% coverage). The description adds value by explaining the parsing of markdown checkboxes and the mutual exclusivity implicit in the alternatives, going beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the verb (evaluate), resource (goal brief gates), and the rule it encodes. Distinguishes from sibling tools like kickoff_plan or decision_log_guidance by specifying gate resolution for session starts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides two input alternatives (structured gates list or content string) and explains the parsing behavior. Implies usage context via the rule about session start, but does not explicitly state when not to use or what alternatives exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kickoff_planAssemble the kickoff file planAInspect

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

ParametersJSON Schema

Name	Required	Description
`answers`	Yes	Confirmed interview answers keyed by token id (e.g. PROJECT_NAME, LOCKED_DOCS).
`detected`	No	Facts the agent detected by inspecting the repo (brownfield only).
`existing`	No	Agent inventory of files already present in the target (for idempotent re-runs).
`project_type`	Yes	'greenfield' or 'brownfield'.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: it assembles files from templates, replaces tokens, reports missing tokens, never overwrites (idempotent), and returns files with actions without writing to disk. This is comprehensive and addresses safety (no writes) and constraints (D5 strict).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph with every sentence providing essential information—purpose, inputs, output structure, idempotency, and conditions. It is efficient and front-loads the main action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description fully explains the return value structure (files, missing, open_questions, warnings) and the success condition. All input parameters are contextualized, and behavioral nuances (idempotency, token resolution) are covered, making it complete for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description adds value by explaining that answers are keyed by token id, detected holds brownfield facts, and existing is the agent's file inventory, providing context beyond the schema field names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific verb 'Assemble' and lists exactly which files are produced (four _template.md copies, decision-log.md, AGENT_CONVENTIONS.md), clearly distinguishing from siblings like kickoff_questions (for gathering answers) or decision_log_guidance (for format guidance).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It indicates required inputs (project_type, answers) and optional ones (detected, existing), implying use after interview answers are collected. It also states the ready condition (missing empty) and idempotency, but does not explicitly exclude alternatives or mention when not to use this tool versus siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kickoff_questionsGet the kickoff interview question setAInspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`detected`	No	Facts the agent detected by inspecting the repo (brownfield only).
`project_type`	Yes	'greenfield' or 'brownfield'.

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses nondestructive behavior (server reads no files), explains the branching logic, and describes the return fields. It could be improved by explicitly stating there are no side effects, but overall it is informative.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph but packs essential information: main purpose, branching logic, special case, return type, and a behavioral note. Every sentence adds value, and the structure is logical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description explains the return fields (project_type, questions, inferred, notes). It also covers the logic for both project types and notes the server reads no files. This is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, but the description adds meaning beyond the schema. It explains how project_type affects behavior, that detected is for brownfield only, and that LOCKED_DOCS is always asked. This provides significant context for parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the branched kickoff interview questions based on project_type. It specifies behavior for greenfield vs brownfield and mentions the return object structure. It is distinct from siblings like decision_log_guidance or kickoff_plan, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use greenfield vs brownfield and notes the special case of LOCKED_DOCS always being asked. It provides clear context for usage but does not explicitly mention when not to use the tool or discuss alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

next_procedureGet the procedure for a methodology phaseAInspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`facts`	No	Optional facts to weave into the procedure (e.g. ticket id, work dir).
`phase`	Yes	Which phase of the methodology loop the agent is in.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and exceeds expectations. It discloses that the server reads no files (safe, fast), the output originates from bundled guides and conventions, and the exact return structure. No destructive or hidden behaviors are omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero waste. The first sentence states the core purpose; the second packs in parameter guidance, output shape, source, and a behavioral guarantee. Essential information is front-loaded and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 2 parameters and no output schema, the description fully compensates by specifying the return shape, sourcing, and behavior. It covers all relevant aspects: what the tool does, when to use it, what parameters mean, what output to expect, and a safety guarantee (no file reads). No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by listing the enum values inline, providing an example fact (ticket id), and explaining that facts 'tailor the output.' This extra context helps the agent understand parameter usage beyond the schema's descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the ordered procedure for a methodology phase. It lists the valid phases, the output structure, and distinguishes from sibling tools like validate_artifact by noting it is 'the procedure half of advisor + validator.' The verb 'Return' plus resource 'ordered procedure for a methodology phase' is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use the tool: when the agent needs the procedure for their current phase in the methodology loop. It provides context about the tool's role as the procedure half of advisor/validator, implying complementarity with sibling tools. However, it does not explicitly state when not to use it or name alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

standup_dueJudge whether a standup is dueAInspect

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

ParametersJSON Schema

Name	Required	Description	Default
`today`	No
`gate_reached`	No
`last_standup_date`	No
`dependency_intersection`	No
`working_days_since_last_standup`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully bears the transparency burden. It discloses the priority logic for triggers, clarifies that working days are an input not a computation, and specifies the return structure ({ due, reason, detail }). No contradictions or hidden behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences, each serving a distinct purpose: purpose statement, logic explanation, and caveat about working days. No fluff, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description covers the core logic, output shape, and a key behavioral note. It omits error handling or input validation details, but for a judgment tool without required fields, it is adequately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains the role of each parameter (e.g., gate_reached triggers 'gate', working_days_since_last_standup triggers 'weekly') and clarifies that working_days_since_last_standup is an input. Though date formats are unspecified, the description adds significant meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Given agent-supplied facts, decide whether a standup is due.' It specifies the verb (decide) and resource (standup due) and differentiates from siblings by detailing the exact logic and output format, leaving no ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the decision logic but does not explicitly state when to use this tool over siblings like 'evaluate_gate' or 'decision_log_guidance'. Usage is implied (when needing to determine if a standup is due), but no exclusions or alternatives are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_artifactValidate a methodology artifactAInspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	The full markdown text of the artifact to validate.
`artifact_type`	Yes	Which artifact to validate.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description fully handles disclosure. Explains return structure (valid, missing, warnings) and behavior: missing is blocking, warnings advisory, server never reads files. Could mention sync/async or performance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Compact yet thorough. Sentences are front-loaded with primary action, followed by usage note, then detailed return format. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema or annotations, description fully explains tool's purpose, input, return values, and behavioral semantics (blocking vs warning). No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers parameters at 100%, but description adds context: 'full text' and 'server never reads files', clarifying input requirements and file-handling behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb 'check' and resource 'artifact's text'. Clearly states it validates Conducted Development artifacts against methodology structure. Distinct from sibling tools like evaluate_gate or kickoff_plan.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains how to use: supply artifact_type and full text. Implicitly differentiates from siblings but does not explicitly compare or state when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

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

7 tool updatesv0.1.0Jul 7, 2026
- First observeddecision_log_guidance
- First observedevaluate_gate
- First observedkickoff_plan
- First observedkickoff_questions
- First observednext_procedure
- First observedstandup_due
- First observedvalidate_artifact

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-07-07 21:35 across 7 tools

Disambiguation5/5

Each tool serves a distinct function within the methodology: decision logging, gate evaluation, kickoff planning, interview questions, procedure guidance, standup detection, and artifact validation. There is no overlap in purpose.

Naming Consistency4/5

All tools use snake_case consistently. Most follow a verb_noun pattern (evaluate_gate, validate_artifact), with minor exceptions like 'next_procedure' and 'standup_due'. The pattern is predictable.

Tool Count5/5

7 tools is well-scoped for the domain of a development methodology. Each tool covers an essential aspect: kickoff, gates, decisions, standups, artifact validation, and general procedure. Neither too few nor too many.

Completeness4/5

The tool surface covers the core methodology lifecycle: kickoff, decision logging, gate evaluation, standup detection, artifact validation, and procedure guidance. Missing direct creation tools for some artifacts (beyond kickoff plan), but validation and guidance are present.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

PlanExe A
io.github.PlanExeOrg
MCP server for generating rough-draft project plans from natural-language prompts.
Autonomous Agents Developer Tools Project Management
113401
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

Arthur
moechehabb
-
license
Not graded
quality
Not graded
maintenance
An MCP server that enables developers to summon AI development team agents directly from their IDE to help with tasks like PR reviews, security evaluation, and CI/CD deployment setup.
Updated a year ago (2025-10-12 01:37 UTC)
-
vibe-guard
Developer Tools Project Management Agent Orchestration
sikuai2333
A
license
Not graded
quality
D
maintenance
MCP server that provides project guardrails including prior art research, project status checks, next task retrieval, and quality gate enforcement for AI-assisted development.
Updated 3 months ago (2026-06-07 03:39 UTC)
19 npm
MIT
Architect-to-Product (A2P)
Developer Tools CI/CD & DevOps Software Architecture
BernhardJackiewicz
A
license
Not graded
quality
C
maintenance
An MCP server that adds engineering discipline to AI-assisted development, enforcing evidence-gated TDD, security review, backup strategy, and deployment generation to turn AI-generated code into production-ready software.
Updated 15 days ago (2026-09-01 10:26 UTC)
8 npm
12
MIT
ForgeSwarm
Autonomous Agents Project Management
H2SO4620
A
license
A
quality
C
maintenance
An MCP server that turns independent AI agents into a coordinated engineering team with shared task board, context, review loop, and enforced plan-implement-review-iterate workflow.
Updated 3 months ago (2026-06-14 09:23 UTC)
24
MIT