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.
1---2name: engineer-plugin-mcp3description: 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 building or adding an MCP server to a plugin. Not for plugin manifests or packaging when the MCP server already exists (that is a separate packaging concern).4---56# Plugin MCP Engineer78Use this skill for MCP tools inside an AI IDE plugin. Keep server implementation host-neutral and generate host-specific wiring separately.910## Official Docs First1112Do not treat this skill as a full MCP protocol or host configuration13specification. Protocol versions, SDK APIs, host config fields, approval14policies, and validation commands can change. Before implementation, open the15current official docs for the MCP protocol and every requested host, then cite16or link the pages used in the output.1718- MCP intro: https://modelcontextprotocol.io/docs/getting-started/intro19- MCP latest specification: https://modelcontextprotocol.io/specification/latest20- Claude Code MCP: https://code.claude.com/docs/en/mcp21- Claude Code plugins: https://code.claude.com/docs/en/plugins22- Codex MCP: https://developers.openai.com/codex/mcp23- Codex plugin build guide: https://developers.openai.com/codex/plugins/build24- Cursor MCP: https://cursor.com/docs/mcp25- Cursor extension API: https://cursor.com/docs/extension-api2627Fetch only the sections needed for the current task. For any host not listed,28find its official MCP, plugin, extension, or connector docs first. If no29official docs exist, say so and separate verified behavior from assumptions.3031## Workflow32331. Classify the request.34 - Design, plan, evaluate, or "help me design" -> output an MCP design only;35 do not create files or run tests.36 - Create, implement, scaffold, write files, or modify this repo -> implement37 after the protocol docs, host docs, and validation path are clear.38 - A concrete server or tool name does not make a request an implementation39 request. The verbs decide.402. Define the tool contract.41 - Server name, tool names, input schema, result shape, errors.42 - Whether calls read, write, or trigger external side effects.433. Choose the transport and implementation path from current docs.44 - Prefer official MCP SDKs or the current MCP specification for protocol45 details instead of copying method schemas into this skill.46 - Use stdio, HTTP, or host-supported transports only after checking host docs.47 - Keep request/response handling deterministic and fail clearly on bad input.484. Keep server state explicit.49 - Prefer environment or command arguments for config.50 - Validate required paths and credentials at startup.51 - Fail clearly when dependencies are missing.525. Generate host wiring.53 - Use each host's current docs for config file location, field names,54 environment expansion, approval policy, and plugin-scoped server settings.55 - Keep host wiring outside the server implementation.56 - Document how each host exposes tool names to the model, logs, approvals,57 and hooks. Treat server/tool prefixes or event names as host-specific until58 current docs prove otherwise.596. Validate with a probe.60 - Confirm the protocol handshake and tool call using the current MCP spec or61 official SDK tooling.62 - Confirm arguments and result returned to the model.63 - Capture server logs for evidence.6465## Server Rules6667- Keep protocol strict and deterministic.68- Use stable tool names and task-level input/output contracts; do not freeze full69 MCP protocol schemas in this skill.70- Do not infer required fields silently.71- Separate host config generation from server code.72- Do not depend on a specific model or IDE binary in server logic.73- Tool names should be stable even if host event names are prefixed differently.7475## Output Shape7677For implementation requests, produce:7879- Server file.80- Tool schema.81- Official docs consulted.82- Host-specific wiring snippets.83- Host-specific exposed tool-name and event-name mapping.84- Smoke-test command or fixture.85- Notes for approvals or trust prompts.8687For design-only requests, return the same shape as a concise design response88without writing files or running smoke tests.8990## Validation Notes9192- Non-interactive hosts may need documented approval settings for automated MCP calls.93- Host output can show connected MCP servers and tool calls; verify from the94 current host docs before relying on a specific event shape.95- Hook matchers for MCP may use host-specific tool-event names; keep that mapping in wrapper code or documentation.
korchasa