| name | engineer-plugin-mcp |
| description | Build AI-IDE plugin MCP elements - stdio JSON-RPC servers, tool schemas, host wiring for Claude Code/Codex, event-name mapping, and validation. Use when adding an MCP server to a plugin. |
Plugin MCP Engineer
Use this skill for MCP tools inside an AI IDE plugin. Keep server implementation host-neutral and generate host-specific wiring separately.
Official Docs First
Do not treat this skill as a full MCP protocol or host configuration
specification. Protocol versions, SDK APIs, host config fields, approval
policies, and validation commands can change. Before implementation, open the
current official docs for the MCP protocol and every requested host, then cite
or link the pages used in the output.
Fetch only the sections needed for the current task. For any host not listed,
find its official MCP, plugin, extension, or connector docs first. If no
official docs exist, say so and separate verified behavior from assumptions.
Workflow
- Classify the request.
- Design, plan, evaluate, or "help me design" -> output an MCP design only;
do not create files or run tests.
- Create, implement, scaffold, write files, or modify this repo -> implement
after the protocol docs, host docs, and validation path are clear.
- A concrete server or tool name does not make a request an implementation
request. The verbs decide.
- Define the tool contract.
- Server name, tool names, input schema, result shape, errors.
- Whether calls read, write, or trigger external side effects.
- Choose the transport and implementation path from current docs.
- Prefer official MCP SDKs or the current MCP specification for protocol
details instead of copying method schemas into this skill.
- Use stdio, HTTP, or host-supported transports only after checking host docs.
- Keep request/response handling deterministic and fail clearly on bad input.
- Keep server state explicit.
- Prefer environment or command arguments for config.
- Validate required paths and credentials at startup.
- Fail clearly when dependencies are missing.
- Generate host wiring.
- Use each host's current docs for config file location, field names,
environment expansion, approval policy, and plugin-scoped server settings.
- Keep host wiring outside the server implementation.
- Document how each host exposes tool names to the model, logs, approvals,
and hooks. Treat server/tool prefixes or event names as host-specific until
current docs prove otherwise.
- Validate with a probe.
- Confirm the protocol handshake and tool call using the current MCP spec or
official SDK tooling.
- Confirm arguments and result returned to the model.
- Capture server logs for evidence.
Server Rules
- Keep protocol strict and deterministic.
- Use stable tool names and task-level input/output contracts; do not freeze full
MCP protocol schemas in this skill.
- Do not infer required fields silently.
- Separate host config generation from server code.
- Do not depend on a specific model or IDE binary in server logic.
- Tool names should be stable even if host event names are prefixed differently.
Output Shape
For implementation requests, produce:
- Server file.
- Tool schema.
- Official docs consulted.
- Host-specific wiring snippets.
- Host-specific exposed tool-name and event-name mapping.
- Smoke-test command or fixture.
- Notes for approvals or trust prompts.
For design-only requests, return the same shape as a concise design response
without writing files or running smoke tests.
Validation Notes
- Non-interactive hosts may need documented approval settings for automated MCP calls.
- Host output can show connected MCP servers and tool calls; verify from the
current host docs before relying on a specific event shape.
- Hook matchers for MCP may use host-specific tool-event names; keep that mapping in wrapper code or documentation.
