Skip to content

Design: bundle the first MCP server / custom agent (cross-tool prove-out)Β #39

Description

@devantler

πŸ€– Generated by the Daily AI Assistant

Part of #38 (Theme 1 β€” realize "not skills-only").

Problem

AGENTS.md commits the marketplace to bundling any agent resource β€” "agent skills today; MCP servers and custom agents as they prove out across the supported tools" β€” and this is standing maintainer direction (devantler-tech/agent-plugins#15 was closed "I do not want this [skills-only scoping]"). Today all 6 plugins are skills-only, so the marketplace's defining cross-tool capability is unrealized.

Proposed direction (design-first, then prove out one)

  1. Cross-tool capability matrix. Document how each supported tool consumes a bundled MCP server and a custom agent:
    • Claude Code plugins support .mcp.json (MCP servers), agents/ (custom agents), and commands/ within the plugin source dir.
    • GitHub Copilot CLI / VS Code agent-plugin format β€” determine its MCP/agent support and manifest shape.
    • Identify the common subset that stays tool-neutral (the marketplace's contract) vs. tool-specific extras.
  2. Manifest & CI implications. Decide whether plugin.json / both marketplace.json manifests need new fields (e.g. an mcpServers / agents declaration) and how validate-manifests.sh should validate a non-skill plugin (today it assumes skills/). Keep the two manifests in parity.
  3. Prove out the first one. Ship a single, real, useful bundle as the proof β€” strongest candidate: an MCP server paired with an existing plugin where the skills already assume it, e.g. the Flux MCP alongside gitops-kubernetes (the gitops-cluster-debug skill already drives a live Flux MCP), or the ksail MCP. A custom agent is the alternative first artifact if an MCP bundle proves tool-divergent.

Scope update (2026-06-30): the design split it (as anticipated below), so this issue now tracks
only the design (AC#1 + AC#2), delivered by PR #43 (ADR 0001). The concrete bundle (AC#3) is the
follow-up child #42.

Acceptance criteria

Size

M–L β€” start with the design note + manifest/CI decision (this issue, closed by PR #43), then the first concrete bundle as the follow-up child #42.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions