DeepSeek Capability Hub
Capability Hub — это MCP-брокер и брокер навыков с отложенной загрузкой для DeepSeek Harness и других MCP-клиентов. Хост видит один компактный инструмент, capability_hub, вместо того чтобы платить контекстом за каждую схему инструмента на каждом настроенном сервере.
Агент ищет в компактном каталоге, проверяет разрешения, поднимает один доверенный сервер, вызывает его через хаб и может снова остановить. Навыки загружаются только после выбора.
Зачем это нужно
Большие статические MCP-конфигурации расходуют контекст и делают выбор инструмента более шумным. Capability Hub сохраняет стабильной поверхность, видимую модели:
search → inspect → enable → tools → call → disableОдна фиксированная схема остаётся в промпте Harness.
Схемы дочерних инструментов остаются вне контекста модели до тех пор, пока их не запросят.
toolsпо умолчанию возвращает имена и описания; полные схемы — по запросу.MCP-процессы запускаются лениво и живут только в течение времени жизни процесса хаба.
Навыки обнаруживаются по метаданным и загружаются по одному.
Сторонние дополнения попадают в очередь подтверждения человеком; модель сама не может подтвердить исполняемый код.
Related MCP server: dsh-skills-anywhere
Быстрый старт
Требования: Node.js 22.19+ и pnpm.
git clone https://github.com/NeoXider/deepseek-capability-hub.git
cd deepseek-capability-hub
pnpm install --frozen-lockfile
pnpm test
pnpm client -- --json '{"action":"search","query":"demo"}'Каталог по умолчанию содержит только встроенный echo MCP и пример ML-навыка. Тесты не скачивают и не выполняют сторонние пакеты.
Настройка DeepSeek Harness
Соберите хаб, затем внесите examples/dsh/cordis.patch.yml в активный профиль Harness Web и скорректируйте абсолютный путь к репозиторию. Перезапустите Harness.
pnpm buildHarness предоставит модели один инструмент:
mcp__capability_hub__capability_hubНачните с:
{"action":"search","query":"web research"}Катой контракт для модели
Публичная схема намеренно сделана плоской, чтобы движки с ограниченным декодированием, такие как LM Studio, могли надёжно компилировать её. Произвольные аргументы дочерних инструментов передаются как JSON-строки.
Найдите и вызовите инструмент:
{"action":"tools","name":"web-search-neo"}{
"action": "call",
"name": "web-search-neo",
"tool": "web_info",
"argumentsJson": "{\"topic\":\"search_status\"}"
}Доступные действия:
Action | Purpose |
| Поиск по компактным метаданным возможностей |
| Просмотр одной возможности, разрешений, конфигурации и состояния окружения |
| Задание разрешённых несекретных значений через |
| Запустить или остановить один доверенный MCP |
| Список дочерних инструментов; схемы остаются необязательными |
| Проксирование вызова дочернего инструмента через |
| Загрузка одного одобренного локального навыка |
| Сохранение недоверенного предложения из |
| Список ожидающих предложений |
| Перезагрузка одобренного состояния каталога |
Реальные примеры интеграции
Включены готовые к рассмотрению предложения:
Web Search Neo — динамический веб-исследования и инструменты браузера.
Unity CLI MCP — официальный транспорт Unity CLI. Его список инструментов заполняется только при подключённом Unity Editor с Unity Pipeline.
Эти файлы — примеры, а не молча принимаемые значения по умолчанию. Проверяйте пути, версии и права перед согласованием.
Установка с подтверждением человека
Предложения, созданные моделью, хранятся в data/state/pending и не могут быть выполнены. Подтвердите их из отдельной команды, выполняемой человеком:
node dist/src/admin.js approve <proposal-id> --state .\data\state --yesЗатем вызовите catalog.reload и activate. Лучше использовать зафиксированные версии пакетов или неизменяемые версии Git; избегайте установщиков с плавающей версией latest в одобренных записях.
Каталоги, секреты и навыки
Транспорты MCP:
stdioиstreamable-http.Шаблоны:
${catalogDir},${packageDir}и явно разрешённые значения${config:key}.Секреты: только ссылки на переменные окружения. Ключи конфигурации модели, похожие на секреты, отклоняются.
Навыки: одобренные локальные Markdown-файлы, загружаемые по требованию, ограниченные 256 КиБ.
Состояние: конфигурация времени выполнения и предложения игнорируются Git.
См. SECURITY.md с описанием границы доверия.
Текущая область применения
Вызовы инструментов проксируются; ресурсы и подсказки дочерних MCP пока не подключены.
Переподключение выполняется явно:
disable, затемenable.Удалённая загрузка навыков, проверка подписей и установка в песочнице — будущая работа.
Модель с неограниченным доступом к оболочке хоста может обойти политику, заданную для плагина; используйте разрешения Harness как внешнюю границу.
Сопутствующий проект
Хотите компактное анимированный вктросное представление агентов, контекста, моделей, рассуждений и чата? Смотрите DeepSeek Harness Widget.
Участие
Приветствуются фокусные pull request и сообщения об ошибках. Новые интеграции должны включать зафиксированный пример, узкое описание разрешений и сквозной тест.
MIT © NeoXider
Available Tools
1 toolcapability_hubLazy MCP and skill capability hubA
Search and inspect a compact catalog, enable a trusted MCP only when needed, list its tools, proxy a tool call, or load one skill body. Shortest path: action "call" with name, tool and arguments starts the server by itself; use action "tools" (optionally with a query) first only when you do not know the tool name, and "enable" only to start one deliberately. Long results arrive in pages: continue with action "page" and the cursor printed on the last line. Avoid includeSchema unless you need the argument shape. Third-party proposals require human approval outside this MCP. Available capabilities — demo-echo (mcp): Bundled local MCP used to verify dynamic discovery, enable, tool listing, calls, and disable. | ml-experiment-review (skill): Review an ML experiment as a falsifiable, reproducible evidence package.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Optional capability type filter. | |
| name | No | Exact capability name. | |
| tool | No | Raw child MCP tool name for call. | |
| query | No | Search text. With action search it filters the catalog; with action tools it filters that server's tool names and descriptions. | |
| action | Yes | Operation to perform. | |
| cursor | No | For action page: the cursor from a paged result's last line. | |
| arguments | No | Call arguments as an object (e.g. {"url":"https://example.com"}). Prefer this over payloadJson for action call; the two must not be combined. | |
| payloadJson | No | JSON object for the action: arguments for call (e.g. {"url":"https://example.com"}), non-secret whitelisted configuration for configure and enable, or a capability proposal for propose. | |
| includeSchema | No | Include full child tool schemas. Leave false unless arguments cannot be inferred. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare openWorldHint/readOnlyHint/destructiveHint, and the description adds real context beyond them: calls self-start the backing server (a side effect), results are paginated with a cursor printed on the last line, and third-party proposals need human approval outside this MCP. It does not say what enable/disable do to persistent state or how failures surface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The shortest-path instruction is front-loaded and each sentence carries distinct operational information (routing, pagination, schema flag, approval gate). The trailing capability listing is useful for discovery but is volatile content embedded in a definition, adding length that will date quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-action dispatcher with no output schema, the description covers the critical call/tools/enable/page flows plus the approval constraint well enough to act on. Completeness falls short on the secondary actions (status, configure, disable, propose, proposals, catalog.reload), which an agent must infer from enum names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds action-to-parameter coupling the schema does not express: name+tool+arguments for "call", query as an optional filter for "tools", cursor from the last line for "page". It does not clarify when payloadJson is required over arguments beyond the schema's own note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names specific verbs and resources — search/inspect a catalog, enable an MCP, list its tools, proxy a call, load a skill body — so the hub's role is unmistakable. It omits any explanation of several enum actions (status, configure, disable, propose, proposals, catalog.reload), leaving those to the bare enum labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit shortest path (action "call" with name/tool/arguments auto-starts the server), states when to use "tools" instead (only when the tool name is unknown), and when to use "enable" (only to start deliberately), plus "avoid includeSchema unless...". Guidance is absent for the remaining actions, including the easily confused propose vs. proposals and configure vs. enable pairs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.10.3- Changed
capability_hub8 fields changed- changed
Input schema / properties / arguments / additionalPropertiesPrevious value: -{}New value: +true - added
Input schema / properties / arguments / propertiesAdded value: +{} - removed
Input schema / properties / arguments / propertyNamesRemoved value: -{ - "type": "string" -} - removed
Input schema / properties / cursor / maxLengthRemoved value: -80 - removed
Input schema / properties / name / maxLengthRemoved value: -80 - removed
Input schema / properties / payloadJson / maxLengthRemoved value: -200000 - removed
Input schema / properties / query / maxLengthRemoved value: -500 - removed
Input schema / properties / tool / maxLengthRemoved value: -500
1 tool update
v0.10.1- Changed
capability_hub2 fields changed- changed
Input schema / properties / action / enumPrevious value: -[ - "search", - "inspect", - "status", - "configure", - "enable", - "disable", - "tools", - "call", - "skill.load", - "propose", - "proposals", - "catalog.reload" -]New value: +[ + "search", + "inspect", + "status", + "configure", + "enable", + "disable", + "tools", + "call", + "skill.load", + "propose", + "proposals", + "catalog.reload", + "page" +] - added
Input schema / properties / cursorAdded value: +{ + "description": "For action page: the cursor from a paged result's last line.", + "maxLength": 80, + "type": "string" +}
1 tool update
v0.8.0- Changed
capability_hub1 field changed- added
Input schema / properties / argumentsAdded value: +{ + "additionalProperties": {}, + "description": "Call arguments as an object (e.g. {\"url\":\"https://example.com\"}). Prefer this over payloadJson for action call; the two must not be combined.", + "propertyNames": { + "type": "string" + }, + "type": "object" +}
1 tool update
v0.3.1- Changed
capability_hub5 fields changed- removed
Input schema / properties / argumentsJsonRemoved value: -{ - "description": "JSON object forwarded to the selected child MCP tool, for example {\"query\":\"MCP\"}.", - "maxLength": 100000, - "type": "string" -} - removed
Input schema / properties / configJsonRemoved value: -{ - "description": "JSON object with non-secret configuration. Only catalog-whitelisted keys are accepted.", - "maxLength": 100000, - "type": "string" -} - removed
Input schema / properties / entryJsonRemoved value: -{ - "description": "JSON capability proposal. It remains untrusted until a human approves it outside this MCP.", - "maxLength": 200000, - "type": "string" -} - added
Input schema / properties / payloadJsonAdded value: +{ + "description": "JSON object for the action: arguments for call (e.g. {\"url\":\"https://example.com\"}), non-secret whitelisted configuration for configure and enable, or a capability proposal for propose.", + "maxLength": 200000, + "type": "string" +} - changed
Input schema / properties / query / descriptionPrevious value: -"Search text for names, descriptions, and tags."New value: +"Search text. With action search it filters the catalog; with action tools it filters that server's tool names and descriptions."
1 tool update
v0.1.0- First observed
capability_hub
TDQS
Scored across 1 tool
There is only one tool, so there is no cross-tool misselection risk. However, capability_hub multiplexes many behaviors behind an action parameter, so the agent must distinguish search, enable, tools, call, page, and skill-loading modes internally.
There is a single tool named capability_hub, using consistent snake_case, and its action values appear to follow a simple lowercase convention. With only one exposed tool, naming consistency is inherently strong.
A one-tool gateway can be intentional for a capability hub that dynamically discovers and proxies other MCPs. Still, exposing all discovery, enablement, listing, invocation, paging, and skill loading through one polymorphic tool feels thin and pushes complexity into parameters.
The tool covers discovery, inspection, deliberate enablement, tool listing, proxied calls, pagination, and skill loading, which is broad lifecycle coverage for a hub. Minor gaps remain, such as no explicit disable action despite the demo-echo capability mentioning disable verification.
Maintenance
Related MCP Connectors
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
Search and inspect source-pinned agent skills, plugins and tools through a free public MCP.
Agent-native catalogue of Baseframe Labs dev tools and MCP servers.
Find, vet, and run MCP tools through a secure audited gateway with prompt-injection risk scoring
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceEnables agents to securely discover and invoke a centrally governed catalog of tools from distributed internal and external providers, with policy enforcement, quotas, inspection, and audit controls.-
- AlicenseNot gradedqualityCmaintenanceEnables MCP clients to discover, search, and load agent skills from many sources, including other agents' skill directories, Claude Code plugin marketplaces, and remote git repositories, with no copying or syncing required.1,058 npm6MIT
- AlicenseNot gradedqualityBmaintenanceEnables agents to search a local catalog, load skills, inspect MCP tool schemas, and invoke selected tools through a single unified MCP tool, reducing per-request overhead.1MIT
- FlicenseNot gradedqualityBmaintenanceGives AI agents a single MCP interface to discover, inspect, scope, and execute external capabilities—downstream MCP servers, HTTP APIs, and local tools—resolved on demand from a local index instead of preloaded catalogs. Enforces agent scopes, allow/ask/deny policies, health gates, and schema snapshots at execution time, with local execution traces.-