Activity

1. markuswondrak

   changed the title [-]Add explicit MCP inventory parity for workflow CLI commands[/-] [+][Feature]: Add explicit MCP inventory parity for workflow CLI commands[/+] on Oct 10, 2026
2. mnriem

   added

   feature-assessRun the Spec Kit idea-assessment pipeline on this feature requestRun the Spec Kit idea-assessment pipeline on this feature request

   triage-nice-to-haveVerdict: evidence-backed fix or greenlit feature — land after reviewVerdict: evidence-backed fix or greenlit feature — land after review

   on Oct 12, 2026
3. github-actions commented on Oct 12, 2026

   

   github-actionsBot

   on Oct 12, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — workflow-mcp-parity · Stage 1/5: Intake

   Idea Intake: Explicit MCP inventory parity for workflow CLI commands

   • Slug: workflow-mcp-parity
   • Created: 2026-10-12T12:17:14Z
   • Source: [Feature]: Add explicit MCP inventory parity for workflow CLI commands #4913 (host: github.com; URL Trust Policy: allowlisted)
   • Type: improvement

   Idea (as captured)

   The MCP architecture requires every CLI leaf to have exactly one hierarchy-owned MCP inventory disposition. The workflow hierarchy has no _mcp.py inventory today, so a new workflow leaf can be added without a reviewable decision about MCP exposure. Adding an entry only for workflow.definition would still leave every existing workflow leaf unaccounted for.

   Create workflow-owned MCP inventory and parity coverage for every registered specify workflow CLI leaf. For each operation, record whether it is available, unavailable, or excluded, with an explicit reason whenever it is not available.

   Do not create MCP adapters merely to satisfy inventory parity. Add first-class typed adapters only where the underlying shared operation and MCP contract are ready. workflow.definition is CLI-only today and must receive its explicit disposition as part of the complete hierarchy inventory.

   The issue also identifies use cases around maintainer visibility, parity tests, and incremental future workflow MCP tools, and cites design/mcp.md:203-243 and design/cli.md:409-432 plus a Copilot review discussion on PR #4912.

   Restated

   The workflow CLI hierarchy should maintain an explicit, hierarchy-owned MCP inventory that accounts for every registered leaf exactly once. The inventory should distinguish available, unavailable, and excluded operations, while adapters are added only when their shared operation and MCP contract are ready.

   Origin & Context

   • Raised by: Markus Wondrak, GitHub issue contributor
   • Trigger: A review finding on PR feat: add specify workflow definition for run-scoped definitions #4912 identified that workflow commands lack the explicit MCP inventory and parity coverage required by the architecture.

   First-Glance Unknowns

   • [NEEDS CLARIFICATION: What is the complete set of workflow CLI leaves at assessment time, including nested catalog, step-catalog, and overlay commands?]
   • [NEEDS CLARIFICATION: Which workflow operations already have shared-operation contracts suitable for first-class MCP adapters?]
   • [NEEDS CLARIFICATION: What exact parity-test interfaces and failure messages should maintainers rely on?]
   • [NEEDS CLARIFICATION: Are any workflow leaves intentionally excluded for reasons beyond workflow.definition being CLI-only?]

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4913 · copilot · gpt52codex · 4.64 AIC · ⌖ 0.767 AIC · ⊞ 24.3K · ◷
4. github-actions commented on Oct 12, 2026

   

   github-actionsBot

   on Oct 12, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — workflow-mcp-parity · Stage 2/5: Research

   Idea Research: Explicit MCP inventory parity for workflow CLI commands

   • Slug: workflow-mcp-parity
   • Created: 2026-10-12T12:17:14Z
   • Evidence confidence (overall): medium

   Users & Demand

   • The request is a direct maintainer/reviewer signal: issue [Feature]: Add explicit MCP inventory parity for workflow CLI commands #4913 reports that workflow CLI leaves can be added without a reviewable MCP exposure decision, and asks for parity coverage. [source: [Feature]: Add explicit MCP inventory parity for workflow CLI commands #4913] (confidence: high)
   • The stated users are maintainers adding workflow commands, reviewers checking architecture compliance, and future MCP clients that need explicit exposure semantics. These are stated use cases rather than observed usage telemetry. [source: [Feature]: Add explicit MCP inventory parity for workflow CLI commands #4913] (confidence: medium)
   • No support-ticket volume, usage metrics, or independent user interviews were supplied. [NEEDS CLARIFICATION: quantify workflow-command additions, review findings, or MCP consumer demand.] (confidence: high)

   Prior Art

   • The MCP architecture requires a hierarchy-owned inventory, one disposition per CLI leaf, explicit reasons for unavailable/excluded records, and parity failures for missing, duplicate, stale, or unexplained entries. [source: design/mcp.md:203-243] (confidence: high)
   • The artifact hierarchy is the cited reference implementation; src/specify_cli/artifacts/_mcp.py contains typed inventory records and explicit registration of available tools, while unavailable records carry a reason. [source: src/specify_cli/artifacts/_mcp.py] (confidence: high)
   • The current MCP server catalog is intentionally minimal and its tests assert only the version command, so workflow exposure is not currently represented in the server catalog. [source: src/specify_cli/mcp_server/catalog.py; tests/specify_cli/mcp_server/test_catalog.py] (confidence: high)
   • The workflow CLI has a broad hierarchy of root, catalog, overlay, step, and step-catalog command modules under src/specify_cli/workflows/, with mirrored tests under tests/specify_cli/workflows/. This supports the issue's concern that a partial inventory would leave many leaves unaccounted for. [source: src/specify_cli/workflows/; tests/specify_cli/workflows/] (confidence: high)

   Market & Context

   • For this repository, the relevant context is internal architecture governance rather than a commercial market. Without an inventory, maintainers must infer MCP coverage from separate CLI and MCP surfaces; the issue identifies that as a reviewability and drift risk. [source: [Feature]: Add explicit MCP inventory parity for workflow CLI commands #4913; design/mcp.md:203-243] (confidence: medium)
   • The current alternative is to rely on review-time inspection and the existing minimal MCP catalog. This avoids adding workflow adapters, but does not provide a machine-checkable disposition for every workflow leaf. [source: src/specify_cli/mcp_server/catalog.py; tests/specify_cli/mcp_server/test_catalog.py] (confidence: high)

   Data & Constraints

   • The architecture names exactly three static dispositions: available, unavailable, and excluded; non-available records require concrete reasons, and every CLI leaf must appear exactly once. [source: design/mcp.md:203-243] (confidence: high)
   • The issue explicitly constrains the work: parity must not justify creating MCP adapters without a ready shared operation and contract. [source: [Feature]: Add explicit MCP inventory parity for workflow CLI commands #4913] (confidence: high)
   • Workflow command behavior is spread across nested modules and tests, so a parity test needs a reliable definition of the registered CLI leaf set without replacing explicit registration with filesystem scanning. [source: design/mcp.md:203-243; src/specify_cli/workflows/] (confidence: medium)
   • No baseline count of workflow leaves, adapter readiness, test runtime, or compatibility constraints is recorded. [NEEDS CLARIFICATION: establish the exact inventory population and expected registration boundary.] (confidence: high)

   Evidence Against the Idea

   • The request adds inventory and test maintenance across a large hierarchy, and the current MCP server intentionally supports only version; if no workflow MCP consumers or near-term adapters exist, the immediate user value may be limited. [source: tests/specify_cli/mcp_server/test_catalog.py; [Feature]: Add explicit MCP inventory parity for workflow CLI commands #4913] (confidence: medium)
   • A poorly scoped parity mechanism could duplicate CLI registration logic or encourage adapters created solely for symmetry, the exact failure mode the issue warns against. [source: design/mcp.md:203-243; [Feature]: Add explicit MCP inventory parity for workflow CLI commands #4913] (confidence: high)
   • Demand is supported by one issue/review signal, but there is no independent usage or incident data. [NEEDS CLARIFICATION: validate whether workflow MCP parity has recurring maintainer or consumer impact.] (confidence: high)

   Gaps & Open Questions

   • [NEEDS CLARIFICATION: What exact workflow CLI leaves are registered, including nested groups?]
   • [NEEDS CLARIFICATION: Which leaves can be available now, and which must be unavailable or excluded?]
   • [NEEDS CLARIFICATION: What shared operations and typed MCP contracts already exist or are planned?]
   • [NEEDS CLARIFICATION: What parity test API and registration ownership best fit the existing artifact pattern?]
   • [NEEDS CLARIFICATION: What measurable reduction in review drift or missed MCP decisions defines success?]

   Sources

   • [Feature]: Add explicit MCP inventory parity for workflow CLI commands #4913 (host: github.com, policy: allowlisted)
   • design/mcp.md:203-243 (repository source)
   • design/cli.md:409-432 (repository source)
   • src/specify_cli/artifacts/_mcp.py (repository source)
   • src/specify_cli/mcp_server/catalog.py and tests/specify_cli/mcp_server/test_catalog.py (repository source)
   • src/specify_cli/workflows/ and tests/specify_cli/workflows/ (repository source)

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4913 · copilot · gpt52codex · 4.64 AIC · ⌖ 0.767 AIC · ⊞ 24.3K · ◷
5. github-actions commented on Oct 12, 2026

   

   github-actionsBot

   on Oct 12, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — workflow-mcp-parity · Stage 3/5: Problem

   Problem Definition: Explicit MCP inventory parity for workflow CLI commands

   • Slug: workflow-mcp-parity
   • Created: 2026-10-12T12:17:14Z
   • Inputs used: intake.md | research.md

   Problem Statement

   Maintainers and reviewers cannot currently see or mechanically verify a complete MCP exposure decision for the workflow CLI hierarchy. As workflow leaves evolve across nested command groups, the absence of a single hierarchy-owned accounting surface creates a risk that MCP availability, intentional exclusion, or unavailability is omitted or drifts from the CLI.

   Affected Users & Stakeholders

   • Users: Workflow command maintainers — need a clear, reviewable record when adding or changing a CLI leaf.
   • Users: Architecture reviewers — need parity failures that identify missing, duplicate, stale, or unexplained MCP decisions.
   • Stakeholders: MCP maintainers and consumers — need explicit exposure semantics without adapters being created solely for symmetry.
   • Stakeholders: Project maintainers — own compatibility, test-maintenance cost, and alignment with the MCP architecture.

   Goals

   • Make every registered workflow CLI leaf have exactly one explicit MCP disposition.
   • Make missing, duplicate, stale, and unexplained dispositions detectable during tests or review.
   • Preserve the distinction between exposure accounting and readiness to implement a first-class MCP adapter.
   • Keep command-specific ownership within the workflow hierarchy and align it with the existing artifact precedent.

   Non-Goals

   • Implementing MCP adapters for workflow operations whose shared operation and contract are not ready.
   • Designing MCP schemas, APIs, data models, or execution semantics.
   • Replacing explicit command registration with filesystem or runtime introspection.
   • Expanding MCP exposure beyond what the architecture and available contracts support.

   Success Metrics

   • Every workflow CLI leaf is represented exactly once in the hierarchy-owned inventory (baseline: unknown; target: 100%).
   • Every non-available record has a concrete reason, and parity tests fail for missing, duplicate, stale, or unexplained records (baseline: no workflow inventory/parity coverage identified).
   • No adapter is introduced solely to satisfy parity (baseline: unknown; target: zero parity-only adapters).
   • Reviewers can identify the disposition of a workflow leaf from the owning hierarchy without tracing unrelated central code (qualitative; baseline: current workflow inventory absent).

   Cost of Inaction

   New or changed workflow leaves can continue to lack an explicit MCP decision, leaving review-time discovery as the control and allowing CLI/MCP architecture drift. Future adapters may be added inconsistently or partial inventories may create false confidence. The magnitude of that cost is not quantified beyond the cited review finding.

   Open Questions

   • [NEEDS CLARIFICATION: What is the authoritative complete set of workflow CLI leaves, including nested catalog, overlay, step, and step-catalog groups?]
   • [NEEDS CLARIFICATION: Which workflow leaves have ready shared operations and typed MCP contracts today?]
   • [NEEDS CLARIFICATION: What exact parity test boundary and failure messages should be treated as the contract?]
   • [NEEDS CLARIFICATION: Are any leaves intentionally excluded for reasons other than the CLI-only workflow definition operation?]
   • [NEEDS CLARIFICATION: What baseline and target review-drift or missed-decision measure will validate impact?]

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4913 · copilot · gpt52codex · 4.64 AIC · ⌖ 0.767 AIC · ⊞ 24.3K · ◷
6. github-actions commented on Oct 12, 2026

   

   github-actionsBot

   on Oct 12, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — workflow-mcp-parity · Stage 4/5: Concept

   Concept: Explicit MCP inventory parity for workflow CLI commands

   • Slug: workflow-mcp-parity
   • Created: 2026-10-12T12:17:14Z
   • Recommended option: Option A — Inventory and parity gate

   Options

   Option A — Inventory and parity gate

   +- Sketch: Add a workflow-owned accounting surface that names every workflow CLI leaf once and records available, unavailable, or excluded with reasons where required. Add focused parity coverage that compares the inventory with the registered workflow leaf set and validates the inventory's uniqueness and explanation rules, while leaving adapter implementation to only those operations with ready contracts.
   +- Appetite: small
   +- Trade-offs: Wins architectural visibility and drift detection with the smallest commitment; sacrifices immediate MCP functionality for most workflow commands and depends on defining the authoritative leaf set clearly.
   +- Rabbit holes: Recreating command registration in the test, classifying operations inconsistently across nested groups, or expanding the work into MCP schema design.

   Option B — Inventory, parity gate, and initial adapter tranche

   +- Sketch: Establish the same complete inventory and parity gate, then expose a narrowly selected set of workflow operations through first-class MCP adapters where shared operations and contracts are already mature.
   +- Appetite: medium
   +- Trade-offs: Wins immediate MCP capability for selected operations and exercises the full path; sacrifices focus and increases contract, side-effect, compatibility, and test-maintenance risk before adapter readiness is confirmed.
   +- Rabbit holes: Treating parity as a reason to implement adapters, broadening execution semantics, and discovering that nested workflow operations need additional shared abstractions.

   Option C — Defer until workflow MCP demand is quantified

   +- Sketch: Keep the current workflow and MCP surfaces unchanged while collecting a baseline of workflow command changes, review findings, and consumer demand; revisit inventory parity after that evidence is available.
   +- Appetite: small
   +- Trade-offs: Wins no near-term implementation cost and avoids premature classification; sacrifices reviewability and leaves the identified architecture gap in place.
   +- Rabbit holes: Evidence collection becoming indefinite, inconsistent local conventions continuing, and future adapter work starting without an inventory foundation.

   Recommendation

   Proceed with Option A. It directly addresses the stated problem and the architecture's explicit-inventory rule, targets the measurable 100% accounting and parity goals, and honors the constraint against parity-only adapters. The medium-confidence evidence supports the governance need but does not yet justify a broader adapter tranche; adapter candidates can be evaluated separately once the inventory exposes them.

   Out of Scope (for the recommended option)

   • Implementing workflow MCP adapters without an already-ready shared operation and typed contract.
   • Defining detailed MCP schemas, transport behavior, execution permissions, or workflow side-effect semantics.
   • Refactoring workflow command registration or redesigning nested command groups.
   • Establishing external market or product demand beyond the repository's maintainer/reviewer need.

   Assumptions to Validate

   • The workflow CLI registration boundary can be enumerated deterministically without filesystem scanning or duplicated command logic.
   • The artifact hierarchy's inventory and parity approach is reusable without importing artifact-specific contracts.
   • workflow.definition and any other currently unsupported leaves can be represented with honest, concrete non-available dispositions.
   • The maintainers agree that inventory parity is valuable independently of immediate workflow MCP adapters.

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4913 · copilot · gpt52codex · 4.64 AIC · ⌖ 0.767 AIC · ⊞ 24.3K · ◷
7. github-actions commented on Oct 12, 2026

   

   github-actionsBot

   on Oct 12, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — workflow-mcp-parity · Stage 5/5: Decision — verdict needs-clarification

   Decision: Explicit MCP inventory parity for workflow CLI commands

   • Slug: workflow-mcp-parity
   • Decided: 2026-10-12T12:17:14Z
   • Verdict: needs-clarification
   • Artifacts reviewed: intake.md | research.md | problem.md | concept.md

   Scorecard

   Criterion	Rating	Justification
   Problem validity	adequate	The issue and architecture document a concrete reviewability gap: workflow leaves lack a complete explicit MCP disposition.
   Evidence strength	adequate	The architecture and artifact precedent are strong repository evidence, but demand is primarily one issue/review signal with no usage baseline.
   Value vs. inaction	adequate	A complete inventory would make drift and omissions testable; the cost of missed decisions is real but not quantified.
   Feasibility / appetite	adequate	The recommended inventory-and-parity option is small and explicitly avoids premature adapters, but the authoritative workflow leaf boundary is unresolved.
   Strategic fit	strong	The proposal directly implements the hierarchy-owned inventory and parity rules in the MCP architecture.
   Risk posture	weak	The main risks are identified, but classification of every nested leaf, adapter readiness, and the parity-test boundary remain open.

   Verdict & Rationale

   Needs clarification. The problem is credible and Option A is appropriately scoped, but the assessment should not hand off to specification until the complete workflow leaf set, each operation's initial disposition, and the deterministic parity boundary are confirmed. The evidence also lacks a baseline showing how often this gap causes review drift or affects MCP consumers. Revisit research and shape after those questions are answered; do not implement adapters merely to fill the inventory.

   If needs-clarification

   • Blocking questions:
     • [NEEDS CLARIFICATION: What is the authoritative complete set of registered workflow CLI leaves, including nested catalog, overlay, step, and step-catalog groups?]
     • [NEEDS CLARIFICATION: Which leaves have ready shared operations and typed MCP contracts, and which require unavailable or excluded dispositions with concrete reasons?]
     • [NEEDS CLARIFICATION: What exact parity-test boundary and registration API will detect missing, duplicate, stale, and unexplained entries without duplicating CLI registration logic?]
     • [NEEDS CLARIFICATION: What baseline of review findings, workflow changes, or MCP consumer demand demonstrates the value of this work?]
       +- Revisit stage: research, then shape

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4913 · copilot · gpt52codex · 4.64 AIC · ⌖ 0.767 AIC · ⊞ 24.3K · ◷
8. github-actions

   added

   feature-needs-clarificationFeature assessment verdict: needs clarificationFeature assessment verdict: needs clarification

   on Oct 12, 2026
9. mnriem commented on Oct 12, 2026

   

   mnriem

   on Oct 12, 2026

   Collaborator

   More actions

   I am marking it as a "Go", but please do address some of the clarification questions asked for so we know what we are working towards more specifically. Thanks!
10. mnriem

    added

    feature-goFeature assessment verdict: go — ready to hand off to /speckit.specifyFeature assessment verdict: go — ready to hand off to /speckit.specify

    and removed

    feature-needs-clarificationFeature assessment verdict: needs clarificationFeature assessment verdict: needs clarification

    on Oct 12, 2026
11. n1shanthb commented on Oct 21, 2026

    

    n1shanthb

    on Oct 21, 2026

    More actions

    Hi! I'd like to work on #4913.

    I investigated the current main branch (505781d7) and identified 29 registered workflow CLI leaves across the root, catalog, step, step-catalog, and overlay groups.

    I also tested a recursive traversal of the actual Typer CLI registration tree. A disposable proof of concept confirmed that parity checks can detect a newly registered command without maintaining a second handwritten command list.

    My proposed scope is:

    • Add a workflow-owned MCP inventory covering all registered workflow leaves.
    • Initially classify the 29 existing leaves as unavailable, with concrete per-command reasons, since none currently has a complete typed shared-operation and MCP adapter contract.
    • Add deterministic tests for missing, duplicate, stale, and invalid inventory entries, including nested commands.
    • Avoid introducing new MCP adapters or changing existing workflow behavior.

    I noticed that #4912 may add workflow.definition as another leaf. If that PR merges, I'd update the inventory accordingly.

    Would this inventory-first approach match your expectations? Also, would you prefer a workflow registration entry point that currently registers no tools in the MCP server now or should that wait until the first workflow adapter is available?

    AI disclosure: OpenAI Codex (GPT-6.1 sol [medium reasoning]) assisted with source inspection, CLI enumeration, proof-of-concept tests and drafting the investigation. I reviewed the findings and proposed approach before posting.

    👍React with 👍2Reacted by Markus Wondrak and Manfred Riem
12. mnriem commented on Oct 21, 2026

    

    mnriem

    on Oct 21, 2026

    Last edited by mnriem

    Collaborator

    More actions

    @n1shanthb Go for it and do so with smal targeted PRs linked back to this issue to get it done. E.g one per command. Thanks!
13. n1shanthb commented on Oct 21, 2026

    

    n1shanthb

    on Oct 21, 2026

    More actions

    Thanks @mnriem! I'll keep the changes small and link each PR back to #4913.

    Since the inventory/parity checks need to cover the workflow hierarchy as a whole, Im planning to start with a focused foundational PR for the inventory and parity tests without adding any MCP adapters. After that, any command specific MCP support can go into separate PRs.

    Hope that split sound good!

    👍React with 👍1Reacted by Manfred Riem