How do I use Conducted MCP?

1. Click on "Install 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 Related Servers Score Discussions

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

A3.7/5.0

Behavior4/5

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

Without annotations, the description carries full burden. It discloses the return structure (should_log, reason, entry_template) and behavior when should_log is true. It does not cover auth or side effects, but the tool appears non-destructive and the description provides sufficient behavioral context for an agent.

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

Conciseness4/5

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

The description is a single paragraph that efficiently conveys purpose, usage, and behavior. It is front-loaded with the main action. While it could be broken into clearer sections, there is minimal wasted text.

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

Completeness2/5

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

Given 5 parameters, no annotations, and no output schema, the description is incomplete. It explains the return object but does not detail how the conditions interact, what values are valid for reason, or provide a complete example. The agent would need additional context to use this tool effectively.

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?

The input schema has 5 boolean parameters with 0% description coverage. The description lists all parameter names and explains they are conditions to 'set whichever apply', adding some meaning. However, it does not provide detailed semantics for each parameter, so the description only partially compensates for the schema gap.

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 function: to encode decision-log rules and judge if a situation belongs in the Decision Log. It lists specific conditions and outputs, distinguishing it from sibling tools like evaluate_gate or next_procedure.

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 implicitly gives usage guidance by listing the conditions and noting that a decision confined to one session does not need an entry. However, it does not explicitly compare to alternative tools or state when not to use it beyond that one condition.

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.4/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It explains return shape ({ all_resolved, unresolved, may_begin }) and notes the server reads no files (no side effects). Could add more on error handling or required permissions.

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?

Description is concise and well-structured: purpose first, then input methods, then output details, then a note on server behavior. Every sentence adds value without redundancy.

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 simplicity and lack of output schema, the description adequately covers inputs, outputs, and key behavioral traits. Could mention behavior when both inputs are provided or neither.

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%, but description adds value by explaining how 'content' is parsed for gate checkboxes and clarifying the return logic. This goes beyond the schema definitions.

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?

Description clearly states the tool's purpose: encoding the rule that no session may begin while gates are open. It distinguishes from sibling tools (e.g., decision_log_guidance, kickoff_plan) by focusing on gate evaluation.

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?

Description specifies the two input options (gates list or content string) and how they are used. It does not explicitly state when to avoid using the tool, but the context of sibling tools implies it is specific to gate evaluation.

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.5/5.0

Behavior5/5

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

No annotations are provided, so the description carries full burden. It clearly discloses that the server writes nothing (Model C, D2/D6), only returns content and paths. It explains idempotent behavior (already-present files get 'review'/'skip', never overwritten), and reports missing, open_questions, warnings. This is thorough and transparent.

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

Conciseness4/5

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

The description is relatively concise, packing key details (files assembled, parameters, return fields, idempotency, server behavior) into a few sentences. It is front-loaded with the main purpose. Minor redundancy (e.g., 'Returns { files: [...] }' is clear but could be slightly tighter, but overall well-structured.

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 complexity (4 parameters including nested objects, no output schema), the description covers the essential aspects: what files are produced, conditions for readiness, idempotency, and the return object structure (files, missing, open_questions, warnings). It could briefly mention the bundled templates source, but it's sufficiently complete for an agent to use.

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 description coverage is 100%, but the description adds meaningful context: 'answers keyed by token id', 'detected as brownfield pre-fill fallback', 'existing as agent inventory for idempotent re-runs'. It also explains the return structure beyond schema. This adds significant value over the schema alone.

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 explicitly states the tool assembles multiple template files (four _template.md copies, decision-log.md, AGENT_CONVENTIONS.md) from bundled templates, with specific steps 2–5. The verb 'assemble' is precise, and the resource (kickoff plan files) is clearly identified. It naturally distinguishes from siblings like kickoff_questions (gathering answers) or evaluate_gate (evaluation).

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 indicates when to supply parameters like project_type, answers, detected (brownfield), and existing (inventory). It also explains the readiness condition (missing empty) and idempotency behavior. Although it doesn't explicitly state when not to use this tool, the context is clear within the sibling set, and usage guidance is adequate.

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.1/5.0

Behavior4/5

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

With no annotations provided, the description compensates by disclosing important behaviors: 'the server reads no files' (no side effects), 'LOCKED_DOCS always asked', and the conditional logic. It explains what the return object contains, though it could mention auth or error conditions.

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

Conciseness4/5

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

Two sentences that front-load the main purpose ('Return the branched kickoff interview') and then pack details. No filler, but the dense second sentence could be split for readability. Still efficient and 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 moderate complexity (two modes, nested parameters, no output schema), the description covers the return structure, key behavioral rules, and parameter usage. It does not mention error handling or prerequisites (e.g., inspected repo for brownfield), but is largely 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 100% (both 'project_type' and 'detected' have descriptions), so baseline is 3. The description adds value by explaining how 'detected' facts are used for brownfield to pre-fill and drop inferable questions, and that 'project_type' controls the mode. This goes beyond the 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 uses a specific verb ('Return') and resource ('branched kickoff interview'), and clearly distinguishes behavior for 'greenfield' vs 'brownfield' project types. It adds context with 'DECISIONS.md D3/D4' and avoids 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?

It states when to use the tool (to get kickoff questions) and explains the branching logic for different project types, but does not mention when not to use it or contrast with sibling tools like 'kickoff_plan' or 'next_procedure'. The guidance is clear but incomplete.

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.4/5.0

Behavior4/5

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

The description explicitly states 'the server reads no files', indicating a read-only, side-effect-free operation. It also describes the return shape and source. No annotations are provided, so the description carries the full burden and does well.

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 concise sentences. The first sentence front-loads the purpose, and the second adds details without redundancy. Every word 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 no output schema, the description covers the return shape and source. It explains both parameters well. Missing details like error handling or behavior without facts, but for the tool's simplicity it is adequate.

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 value by listing the enum values for 'phase' and explaining that 'facts' can tailor the output, going beyond the schema's basic description.

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 the current methodology phase. It specifies the exact phases and distinguishes itself as 'the procedure half of advisor + validator', differentiating from sibling tools like validate_artifact.

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 says to supply 'phase' (with enumerated values) and optional 'facts' to tailor output. It provides context that this is the procedure half, implying use over validation tools, but does not explicitly state when not to use it.

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.6/5.0

Behavior5/5

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

With no annotations, the description fully carries the burden of behavioral disclosure. It explains the priority order, that working days are an input not computed, and the return format, ensuring agents understand what the tool does and its limitations.

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 and well-structured: a brief purpose statement, a bullet-like list of trigger conditions in priority order, a critical note about working days, and the return format. Every sentence is informative.

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 5 parameters, zero annotations, and no output schema, the description covers the logic and return values adequately. However, it lacks explicit parameter format details (e.g., date format for 'today').

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?

Although schema coverage is 0%, the description gives meaning to parameters by referencing them in the logic (e.g., gate_reached, dependency_intersection, today, last_standup_date, working_days_since_last_standup). It clarifies their role without defining formats.

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 verb ('Judge whether a standup is due') and resource ('standup'). It details the priority logic, distinguishing it 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?

The description provides clear context on when the tool should be used (to determine standup due based on triggers) but does not explicitly state when not to use it or name alternatives.

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.6/5.0

Behavior5/5

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

Even with no annotations, the description fully discloses the return structure ({valid, missing, warnings}) and explains the logic for 'missing' and 'warnings' fields, including handling of template placeholders. No contradictory behavior is implied.

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 well-structured sentences, the first stating purpose and usage, the second detailing output. Every sentence adds value with no extraneous words.

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?

With only two parameters and no output schema, the description provides sufficient detail about inputs and the return object. It covers validation logic and edge cases (template placeholders). A slight improvement could include an example, but it is already complete enough.

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 clarifying that 'content' must be the full text (not a file path) and explaining how missing detects template placeholders, which improves parameter understanding.

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 explicitly states the tool validates an artifact's text against a methodology's required structure, using the verb 'check' and naming the resource 'artifact'. It clearly distinguishes from sibling tools like 'evaluate_gate' or 'kickoff_plan' which have 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 tells users to supply artifact type and full text, and notes the server never reads files. It does not explicitly state when not to use it, but the context implies it's for validation only, which is sufficient for most agents.

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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
113398
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)
8
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 2 months ago (2026-07-12 18:40 UTC)
21
10
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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mostov82/conducted-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server