Skills, MCP, LSP, and Web capabilities
Operating guides, dynamic tools, code semantics, and internet access each keep an independent service boundary
discover → normalize → register → same tool pipelineSkills and plugins both extend agents—why are they not the same?
A skill is an operating procedure for the worker. A plugin installs machinery. MCP is an external equipment protocol. LSP is a specialized code measurement instrument.
Mechanism
ctx.skills merges provider catalogs. tool-skill first shows a catalog and injects full bodies on demand; content enters model context without registering JavaScript services.
MCP discovers remote tools then registers them into ctx.tools. LSP exposes four normalized queries without protocol escape hatches. Web search/fetch providers sit behind stable tool-web names.
Discover
Scan skill files, MCP servers, or provider registrations.
What extensions must preserve
- MCP tools cannot bypass ctx.tools
- Skill bodies are model context, not trusted code
- LSP providers must translate into normalized results
The tempting wrong turns
- ×Executing a skill as arbitrary plugin code
- ×Trusting MCP schemas as internal types without normalization
- ×Exposing a generic LSP request escape hatch
Do not trust the conclusion—verify it
These anchors are pinned to official deepseek-harness@47f9438; account for later breaking changes when reading current upstream.
docs/subsystems/skills.mdSkill providers, catalogs, and body loading.
docs/subsystems/lsp.mdNormalized code-query boundary.
packages/mcp/mcp-client/src/index.tsDynamic tool discovery and registration.
docs/subsystems/web.mdSearch/fetch providers and tool-web.
Pause for ten seconds before revealing
Why register discovered MCP tools into ctx.tools?
The capability map is complete. The final layer turns it into four extension tasks: tools, providers, surfaces, and product composition.