feat: Plugins Spec#64
Conversation
youssefea
commented
Jun 2, 2026
youssefea
commented
- Creating a spec for new plugins
- Conforming the existing plugins to the spec
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
🟡 Heimdall Review Status
|
…mance # Conflicts: # skills/base-mcp/SKILL.md # skills/base-mcp/plugins/avantis.md
…ance - requires.shell value `never` → `none` across the 4 http/external-mcp plugins and plugin-spec.md (clearer wording; same three-way semantics). - plugin-spec.md now self-contained for an agent: per-field decision guidance, Runtime Routing Primitives, per-section content rules, and a "How to Adapt an Existing Plugin" migration procedure. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add a `tags` frontmatter field (capability/category keywords) to all 7 plugins and the spec, placed under `description`. Surface tags in the SKILL.md plugins table so the agent routes a user request to a plugin by matching tags first. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
| | `name` | string | Lowercase slug (e.g. `morpho`). Used for cross-links and the SKILL.md table. | | ||
| | `version` | string | Plugin doc version, semver (e.g. `0.2.0`). Bump on meaningful changes (a spec-conformance restructure counts). | | ||
| | `integration` | enum | See [Integration Types](#integration-types). | | ||
| | `chains` | string[] | Base MCP chain strings the plugin targets (e.g. `[base]`, `[base, optimism]`). | |
There was a problem hiding this comment.
should be chain ids in hex imo -- is standard across dev tools / specs
There was a problem hiding this comment.
we should also limit to supported chains
There was a problem hiding this comment.
Done — chains now uses hex chain IDs (0x2105, 0xa) across the spec, all 7 plugins, the conformance table, and the SKILL.md discovery table. Noted in the spec that the body still passes Base MCP's string chain param (e.g. chain: "base") to send_calls — that's the MCP's runtime param, distinct from this declarative frontmatter signal.
There was a problem hiding this comment.
Done — the chains field description and the authoring guidance now both say to limit to chains Base MCP supports (intersect the protocol's networks with Base MCP's).
There was a problem hiding this comment.
FYI Base MCP doesn't use hex chain IDs in tool calls
| 4. The plugin only composes Base MCP's own higher-level tools (`swap`, `send`) with no external service → `semantic-base-tool`. | ||
| 5. It needs two or more of the above depending on the surface (e.g. a CLI when a shell exists, an MCP/HTTP fallback otherwise) → `hybrid`. Document the per-surface paths in `## Surface Routing`. | ||
| - **`chains`** — list the Base MCP chain strings (e.g. `base`, `optimism`) the plugin actually targets: intersect the protocol's supported networks with Base MCP's supported chains. If the plugin never routes an onchain transaction through Base MCP (e.g. an external MCP that only uses a Base MCP signature to log in), use `[]`. | ||
| - **`tags`** — 3–5 lowercase, hyphenated keywords describing *what the user can do* — capability and category, not the protocol name (the `name` already covers that). These drive routing: the agent reads the SKILL.md tags column to decide which plugin matches a request. Reuse existing tags where they fit so similar plugins cluster. Current vocabulary: `lending`, `borrowing`, `yield`, `vaults`, `dex`, `swap`, `liquidity`, `perps`, `leverage`, `derivatives`, `trading`, `token-launches`, `memecoins`, `discovery`, `ai-agents`, `agent-commerce`, `payment-cards`, `email`. Add a new tag only when none fit. |
There was a problem hiding this comment.
should "new" tags also be added to this list when created? i think can be clearer
There was a problem hiding this comment.
Clarified — guidance now reads "add new tags as you see fit … when you introduce a new tag, add it to this list so the vocabulary stays shared."
- chains frontmatter now uses hex chain IDs (0x2105, 0xa), limited to Base MCP supported chains, across all plugins, the spec, conformance table, and SKILL.md (per @lukasrosario). Body send_calls still uses the string `chain` param; noted in the spec. - tags guidance: drop "only when none fit" → "add new tags as you see fit", and clarify that new tags should be added to the shared list. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Review Error for lukasrosario @ 2026-06-02 16:02:53 UTC |
| | Prepare a lend/borrow action | Harness HTTP tool or `web_request` (GET or POST) → calldata → `send_calls`. | | ||
|
|
||
| Steps in `transactions[]` are ordered — `approve` and `enter-market` come before the protocol action. Execute them as a single `send_calls` batch. | ||
| **Prerequisite:** `api.moonwell.fi` must be in the MCP server's `web_request` allowlist. If requests to that hostname are rejected and no harness HTTP tool is available, inform the user that the Moonwell API is not yet whitelisted on this MCP instance. |
There was a problem hiding this comment.
why does this need to be in the skill?
| --- | ||
| title: "Morpho Plugin" | ||
| description: "Skill plugin reference for lending on Morpho with Morpho CLI when available, or Morpho MCP on chat-only surfaces." | ||
| description: "Lending on Morpho — Morpho CLI when a shell is available, else Morpho MCP — preparing unsigned calls submitted via Base MCP send_calls." |
There was a problem hiding this comment.
this seems like an instruction that should be in the body of the skill, not the description
| --- | ||
| title: "Uniswap Plugin" | ||
| description: "Skill plugin reference for swapping and LPing on Uniswap through Base MCP." | ||
| description: "Swapping (proxy-approval, no Permit2) and V2/V3/V4 LP on Uniswap via the Uniswap API → send_calls on Base." |
There was a problem hiding this comment.
once again this feels like information that belongs in the skill body, not fit for a description of the plugin
| name: morpho | ||
| version: 0.2.0 | ||
| integration: hybrid | ||
| chains: [0x2105] |
There was a problem hiding this comment.
should be the chain name, not hex id to be consistent with MCP
4 participants
