mcp-chain-of-draft-server/build/tools/architectureDecisionRecorderParams.d.ts

A Model Context Protocol server which provides Chain of Draft style thinking

import { z } from "zod";
export declare const TOOL_NAME = "architecture-decision-recorder";
export declare const TOOL_PARAM_DESCRIPTIONS: {
    id: string;
    title: string;
    status: string;
    context: string;
    decision: string;
    consequences: string;
    alternatives: string;
    related_decisions: string;
    draft_number: string;
    total_drafts: string;
    is_critique: string;
    critique_focus: string;
    revision_instructions: string;
    is_final_draft: string;
};
export declare const TOOL_SCHEMA: {
    id: z.ZodString;
    title: z.ZodString;
    status: z.ZodEnum<["proposed", "accepted", "rejected", "deprecated", "superseded"]>;
    context: z.ZodString;
    decision: z.ZodString;
    consequences: z.ZodArray<z.ZodString, "many">;
    alternatives: z.ZodArray<z.ZodObject<{
        option: z.ZodString;
        pros: z.ZodArray<z.ZodString, "many">;
        cons: z.ZodArray<z.ZodString, "many">;
    }, "strip", z.ZodTypeAny, {
        option: string;
        pros: string[];
        cons: string[];
    }, {
        option: string;
        pros: string[];
        cons: string[];
    }>, "many">;
    related_decisions: z.ZodArray<z.ZodString, "many">;
    draft_number: z.ZodNumber;
    total_drafts: z.ZodNumber;
    is_critique: z.ZodOptional<z.ZodBoolean>;
    critique_focus: z.ZodOptional<z.ZodString>;
    revision_instructions: z.ZodOptional<z.ZodString>;
    is_final_draft: z.ZodOptional<z.ZodBoolean>;
};
export declare const TOOL_DESCRIPTION = "\n    # Architecture Decision Recorder: Structured Decision Management\n\n    A tool that facilitates the creation, evaluation, and refinement of Architecture Decision Records (ADRs) through iterative critique and revision cycles.\n\n    ## When to Use This Tool:\n    - **Key Design Decisions:** When making significant architectural choices that impact multiple components\n    - **Technology Selection:** Evaluating and selecting frameworks, libraries, or platforms\n    - **Pattern Application:** Deciding which architectural patterns to implement\n    - **Trade-off Analysis:** Balancing competing concerns (performance, maintainability, security)\n    - **Cross-cutting Concerns:** Handling authentication, logging, caching strategies\n    - **API Design:** Establishing API boundaries and communication patterns\n\n    ## Key Capabilities:\n    - **Decision Templating:** Provides structured templates for documenting decisions\n    - **Alternative Analysis:** Systematically evaluates multiple approaches against criteria\n    - **Consequence Mapping:** Identifies impacts of decisions on different system aspects\n    - **Context Preservation:** Records the circumstances and constraints influencing decisions\n    - **Iterative Refinement:** Supports critique and revision cycles for decision records\n    - **Historical Context:** Maintains decision history with evolving understanding\n    - **Traceability:** Links decisions to requirements, constraints, and other decisions\n\n    ## Parameters Explained:\n    - **id:** Unique identifier for the architecture decision record.\n    \n    - **title:** Concise title that summarizes the architectural decision being made.\n    \n    - **status:** Current status of the architecture decision:\n      * \"proposed\": Under consideration, not yet accepted\n      * \"accepted\": Approved and in effect\n      * \"rejected\": Considered and explicitly declined\n      * \"deprecated\": Once accepted but no longer recommended\n      * \"superseded\": Replaced by a newer decision\n    \n    - **context:** Background information explaining the forces at play and the problem being solved.\n    \n    - **decision:** The current decision statement describing the selected architectural approach.\n    \n    - **consequences:** Array of resulting consequences from applying this decision, including benefits, trade-offs, and risks.\n    \n    - **alternatives:** Array of alternative options that were considered, each with pros and cons.\n    \n    - **related_decisions:** Array of identifiers for related architecture decisions that influenced or are influenced by this one.\n    \n    - **draft_number:** Integer tracking the current iteration (starting from 1). Increments with each critique or revision.\n    \n    - **total_drafts:** Estimated number of drafts needed for completion. This can be adjusted as the decision process evolves.\n    \n    - **is_critique:** Boolean indicating the current mode:\n      * true = Evaluating previous decision draft\n      * false = Implementing revisions\n    \n    - **critique_focus:** (Required when is_critique=true) Specific aspect being evaluated, such as:\n      * \"completeness\": Ensuring all relevant factors are considered\n      * \"consistency\": Checking for alignment with other decisions and principles\n      * \"feasibility\": Evaluating practical implementation challenges\n      * \"risks\": Identifying potential negative consequences\n    \n    - **revision_instructions:** (Required when is_critique=false) Detailed guidance for improving the decision based on the preceding critique.\n    \n    - **is_final_draft:** (Optional) Boolean indicating whether this is the final iteration of the decision.\n\n    ## Best Practice Workflow:\n    1. **Start with Initial Draft:** Begin with a first-pass decision record and set a reasonable total_drafts (typically 3-5).\n    \n    2. **Alternate Critique and Revision:** Use is_critique=true to evaluate the decision, then is_critique=false to implement improvements.\n    \n    3. **Focus Each Critique:** Choose a specific critique_focus for each evaluation cycle rather than attempting to address everything at once.\n    \n    4. **Provide Detailed Revision Guidance:** Include specific, actionable revision_instructions based on each critique.\n    \n    5. **Consider Multiple Perspectives:** Ensure critiques come from different stakeholder perspectives (developers, operators, users).\n    \n    6. **Document Alternatives Thoroughly:** Even rejected alternatives should be well-documented with their pros and cons.\n    \n    7. **Mark Completion Appropriately:** Set is_final_draft=true only when the decision record is complete and ready for implementation.\n    \n    8. **Revisit as Needed:** Architecture decisions can be reopened if circumstances change significantly.\n\n    ## Example Application:\n    - **Initial Draft:** Basic decision outline with context and preliminary choice\n    - **Critique #1:** Focus on completeness and identify missing considerations\n    - **Revision #1:** Address gaps in the decision context and rationale\n    - **Critique #2:** Focus on risks and identify potential negative consequences\n    - **Revision #2:** Add risk mitigation strategies to the decision\n    - **Final Critique:** Holistic review of consistency with other architectural decisions\n    - **Final Revision:** Refine presentation and ensure alignment with overall architecture\n\n    Architecture Decision Recorder is particularly effective for capturing and refining significant design decisions in a collaborative environment. By providing structure and promoting iterative improvement, it leads to better-reasoned and better-documented architectural choices.\n";