DeepSeek Capability Hub

Overview Schema Source Related Servers Discussions Admin

Lazy MCP and skill capability hub

capability_hub

Search and inspect a compact capability catalog, enable trusted MCP servers only when needed, list and call their tools, and load approved skills on demand.

Instructions

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.

Input Schema

Name	Required	Description
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.10.3Oct 29, 2026
- changedInput schema / properties / arguments / additionalProperties
```
Previous value: -{}New value: +true
```
- addedInput schema / properties / arguments / properties
```
Added value: +{}
```
- removedInput schema / properties / arguments / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedInput schema / properties / cursor / maxLength
```
Removed value: -80
```
- removedInput schema / properties / name / maxLength
```
Removed value: -80
```
- removedInput schema / properties / payloadJson / maxLength
```
Removed value: -200000
```
- removedInput schema / properties / query / maxLength
```
Removed value: -500
```
- removedInput schema / properties / tool / maxLength
```
Removed value: -500
```

Changed2 schema fields changedv0.10.1Oct 27, 2026

changedInput schema / properties / action / enum

Previous 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"
+]

addedInput schema / properties / cursor

Added value: +{
+  "description": "For action page: the cursor from a paged result's last line.",
+  "maxLength": 80,
+  "type": "string"
+}

Changed1 schema field changedv0.8.0Sep 20, 2026

addedInput schema / properties / arguments

Added 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"
+}

Changed5 schema fields changedv0.3.1Aug 29, 2026

removedInput schema / properties / argumentsJson

Removed value: -{
-  "description": "JSON object forwarded to the selected child MCP tool, for example {\"query\":\"MCP\"}.",
-  "maxLength": 100000,
-  "type": "string"
-}

removedInput schema / properties / configJson

Removed value: -{
-  "description": "JSON object with non-secret configuration. Only catalog-whitelisted keys are accepted.",
-  "maxLength": 100000,
-  "type": "string"
-}

removedInput schema / properties / entryJson

Removed value: -{
-  "description": "JSON capability proposal. It remains untrusted until a human approves it outside this MCP.",
-  "maxLength": 200000,
-  "type": "string"
-}

addedInput schema / properties / payloadJson

Added 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"
+}

changedInput schema / properties / query / description

Previous 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."

First observedv0.1.0Aug 25, 2026

TDQS

A4/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools

capability_hubA