Conducted MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 4.3/5 across 7 of 7 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![conducted-mcp MCP server](https://glama.ai/mcp/servers/Mostov82/conducted-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Mostov82/conducted-mcp)

Score Badge

Copy to your README.md:

[![conducted-mcp MCP server](https://glama.ai/mcp/servers/Mostov82/conducted-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Mostov82/conducted-mcp)

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