* fix(plugins): discover MCP servers from spec-mandated mcp.json at plugin root MCP config was declared via an extensions.com.github.awesome-copilot.mcpServers pointer to a .mcp.json file. That namespace is stripped from the served manifest, so nothing carried the MCP declaration through materialization. Per Agent Plugins v1.0.0 the fixed location is mcp.json at the plugin root, which already ships as-is. Drop the pointer, rename both .mcp.json files, and validate mcp.json (schema, closed top-level fields, server transport variants). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Validate mcp.json against the full v1.0.0 schema with Ajv Replace the hand-rolled MCP checks with Ajv validation against the canonical Agent Plugins v1.0.0 MCP schema, so non-spec configs (empty command/url, non-string args, reserved PLUGIN_ROOT/PLUGIN_DATA env keys, invalid cwd, unknown server fields) are rejected. Per-server errors are re-derived from the matching discriminated branch to avoid unhelpful oneOf output. Also reject a top-level extensions.mcpServers placement, which slipped through because the manifest schema allows arbitrary object-valued extension keys. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 764c5bb4-2811-4dc1-b61d-56c4a5597cc9 * Strengthen mcpServers and stdio semantic validation Reject mcpServers under any extensions namespace in plugin.json so inline MCP config cannot bypass root-level mcp.json enforcement. Also run stdio semantic checks after schema validation to reject absolute command paths and cwd values that escape the plugin root, with regression tests for both cases. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 764c5bb4-2811-4dc1-b61d-56c4a5597cc9 * Enforce MCP path containment across platform path styles Resolve plugin-relative commands and placeholder-rooted cwd values against the plugin root, normalize Windows separators, and reject lexical or symlink escapes. Add regression coverage for traversal, placeholders, Windows paths, and symlink targets. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 764c5bb4-2811-4dc1-b61d-56c4a5597cc9 * Align MCP semantics with the v1.0.0 specification Restore the canonical cwd pattern and literal ./ command prefix. Validate remote HTTP URLs and headers, including HTTPS requirements, header syntax, control characters, and case-insensitive duplicates. Keep PLUGIN_DATA checks lexical-only so it is not conflated with the plugin filesystem root. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 764c5bb4-2811-4dc1-b61d-56c4a5597cc9 * Reject unsafe MCP symlink paths Resolve mcp.json through the filesystem and require a regular file inside the real plugin root, reporting dangling links explicitly. Harden command and PLUGIN_ROOT containment checks to inspect symlink ancestors with lstat and realpath instead of treating unresolved paths as ordinary missing segments. Add regression coverage for outside, dangling, and ancestor symlink cases. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 764c5bb4-2811-4dc1-b61d-56c4a5597cc9 * Handle mixed separators in MCP data paths Split PLUGIN_DATA traversal checks on both slash types so mixed separators cannot bypass lexical containment on Windows clients. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 764c5bb4-2811-4dc1-b61d-56c4a5597cc9 * Reject credentials in MCP package headers MCP headers are visible package data, so reject credential-bearing headers including authorization, proxy authorization, cookies, and common API-key or token names. Preserve ordinary custom headers and add focused regression coverage. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 764c5bb4-2811-4dc1-b61d-56c4a5597cc9 --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 764c5bb4-2811-4dc1-b61d-56c4a5597cc9
5.1 KiB
name, description, argument-hint
| name | description | argument-hint |
|---|---|---|
| create-canvas-extension | Create or register a canvas extension in the awesome-copilot repository. Use when asked to scaffold a new canvas extension, create its plugin.json, add a reusable extension to one or more plugins, or migrate extension metadata. Extensions are reusable source under extensions/; shippable plugin manifests belong under plugins/. | [optional extension name or description] |
Create a canvas extension
Use this skill only for the github/awesome-copilot repository. Canvas extensions are reusable source components. They do not have a plugin.json under extensions/.
Required decisions
Before creating files, ask for each missing value:
- Extension ID: lowercase kebab-case, matching the source folder and plugin name.
- Display metadata:
- description
- version (default
1.0.0) - author name and optional URL
- keywords (lowercase, hyphenated, maximum 10)
- repository and license (default to the repository URL and
MITwhen appropriate)
- Canvas entrypoint: confirm whether the extension already has
extension.mjs. If not, create a minimal entrypoint only when the user provides enough implementation details; otherwise create the directory and leave an explicit TODO. - Preview image: obtain an existing
assets/preview.pngpath or ask the user to add it. Do not invent a binary image or silently use a misleading placeholder. - Plugin registration:
- For a standalone installable canvas plugin, create
plugins/<extension-id>. - For an extension that belongs to an existing plugin, ask for the parent plugin ID and add
./extensions/<extension-id>to that plugin'sextensions.com.github.awesome-copilot.extensions. - If the extension should be shipped by multiple plugins, collect all plugin IDs and add the same extension ID to each mapping file.
- For a standalone installable canvas plugin, create
Files to create
For a new extension plugin, create this structure:
extensions/<extension-id>/
├── extension.mjs
└── assets/
└── preview.png
plugins/<extension-id>/
├── plugin.json
└── README.md
The extension source may contain additional files such as package.json, canvas assets, or supporting modules. Keep all reusable implementation files under extensions/<extension-id>/.
Create plugins/<extension-id>/plugin.json with this shape:
{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "<extension-id>",
"description": "<description>",
"version": "1.0.0",
"author": {
"name": "<author>"
},
"repository": "https://github.com/github/awesome-copilot",
"license": "MIT",
"keywords": [
"<keyword>"
],
"extensions": {
"com.github.copilot": {
"logo": "assets/preview.png"
},
"com.github.awesome-copilot": {
"extensions": [
"./extensions/<extension-id>"
]
}
}
}
Keep Agent Plugins fields at the manifest top level. Repository composition belongs only under extensions.com.github.awesome-copilot; do not put agents, commands, hooks, or skills at the top level or directly under extensions. MCP servers are declared in mcp.json at the plugin root, never in plugin.json. Do not add x-awesome-copilot, standalone, or other repository-specific top-level fields.
For an existing parent plugin, create or update:
plugins/<parent-plugin>/plugin.json (`extensions.com.github.awesome-copilot.extensions`)
Its extensions property must contain sorted repository-relative paths:
{
"extensions": [
"./extensions/<extension-id>"
]
}
Do not copy the extension source into the parent plugin. Materialization resolves the IDs from the root extensions/ directory, so the same source can be bundled by multiple plugins.
Workflow
-
Inspect the repository before editing:
- confirm
extensions/<extension-id>andplugins/<extension-id>do not already conflict - inspect the target parent plugin, if any
- check whether a preview image and entrypoint already exist
- confirm
-
Ask only the missing required questions from the decisions above.
-
Create the source and plugin directories with the required files.
-
If creating a new entrypoint, keep it minimal and clearly mark implementation TODOs rather than fabricating behavior.
-
Add or update
extensions.com.github.awesome-copilot.extensionsfor every parent plugin that should ship the extension. Keep paths alphabetically sorted and unique. -
Ensure there is no
extensions/<extension-id>/.github/plugin/plugin.json. -
Run:
npm run plugin:validate npm run build npm run website:data -
Report the created paths, the plugins that ship the extension, and any missing user-provided assets or TODOs.
Existing extension migration
When migrating an existing extension:
- Move its existing manifest to
plugins/<extension-id>/plugin.json. - Update the manifest to the namespace-based
extensions.com.github.copilot.logoshape. - Remove the old manifest from
extensions/<extension-id>. - Register the extension in any parent plugin's
extensions.com.github.awesome-copilot.extensions. - Run the validation and build commands above.