DeepSeek Capability Hub

Overview Schema Source Related Servers Discussions Admin

Lazy MCP and skill capability hub

capability_hub

Discover, enable, and call MCP tools or load skills on demand, keeping only needed capabilities active and reducing context overhead.

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. Action "tools" starts a stopped capability by itself, so "enable" is only for starting one deliberately. 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

TableJSON 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.
`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.

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.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations only indicate non-readonly and open-world behavior, so the description adds useful context: lazy starting via 'tools', deliberate-only enabling, includeSchema cost, and out-of-band human approval for third-party proposals. It does not overpromise around mutation, and there is no contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loads the core actions, and every sentence carries operational value. The capability list at the end is a terse but useful reference rather than padding.

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 multi-action hub with 8 parameters and no output schema, the description covers the key call patterns: search, enable, tools, call, skill.load, and propose. It leaves minor ambiguity around inspect vs status and the exact shape of configure/proposal payloads, but the schema names and payloadJson guidance cover most invocation needs.

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?

With 100% schema description coverage the baseline is 3, but the description adds value beyond the schema: it disambiguates arguments vs payloadJson and forbids combining them, clarifies action-dependent query semantics, documents the payloadJson overload for call/configure/enable/propose, and warns about includeSchema overhead. It still leaves some payload details implicit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a verb list tied to a concrete resource ('compact catalog') and names the two available capabilities with their types. It is specific enough that an agent knows what surface this tool controls; there are no sibling tools to confuse it.

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?

No sibling tools exist, but the description gives operational guardrails: 'tools' self-starts a stopped capability so 'enable' should only be used deliberately, includeSchema should be avoided unless the argument shape is needed, and third-party proposals require human approval. This is clear context, though it does not provide alternative-tool routing.

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