DeepSeek Capability Hub

DeepSeek Capability Hub

One stable MCP tool instead of every schema you own — 93.2% smaller resident context, at the same tool-selection accuracy. Both measured.

Capability Hub is a lazy MCP and skill broker for DeepSeek Harness and other MCP clients. The host sees one compact tool, capability_hub, instead of paying the context cost of every tool schema from every configured server.

The agent searches a lightweight catalog, inspects permissions, wakes one trusted server, calls it through the hub, and can shut it down again. Skill bodies are loaded only after selection.

Measured context savings

Numbers below are produced by bench/measure.mjs, not estimated.It starts each real, published MCP server over stdio, asks for tools/list, andcounts the tokens (o200k_base) of the exact JSON a host injects per tool(name + description + inputSchema). The hub is measured the same way, bystarting it and reading its own tools/list.

pnpm bench

The permanent cost drops 93.2%, or 14.7x. That is the part of the prompt you payfor on every single turn, whether or not the task touches a tool.

The saving grows with your catalog

The hub publishes one schema no matter how many servers you configure, so the classicside grows linearly while the hub side grows only by a line of catalog prose per entry —and stops growing once the list degrades to names only. Each hub figure below is measuredby starting the real server against a catalog of that size, not projected:

The drop at 30 is the degradation firing: full descriptions no longer fit the budget, thelist falls back to names, and the resident cost roughly halves.

The honest other half

The hub is not free: what the classic setup pays once up front, the hub pays atruntime when the agent actually opens a capability. There is no single "per task"number — an earlier version of this README published one, and it was the mostexpensive possible path presented as typical. Three scenarios:

The direct row still charges a search, which the inlined catalog list often makesunnecessary — a conservative choice, since the bias should run against our own number.

The direct path is cheap for two reasons that were already in the code while thebenchmark was ignoring them: tools starts the server itself, so enable is noton the critical path, and tools accepts a query, costing 60 tokens instead of 558when the agent already knows what it wants:

{"action":"tools","name":"playwright","query":"click"}

Break-even is about 47 direct discoveries in one session, or 8 if the agent takesthe cautious path every time. Below that the hub wins; above it a static configuration ischeaper. The hub is therefore the right trade when you have many servers and each tasktouches few of them, and the wrong one when every task uses every tool you have.

Three design decisions came directly out of these measurements:

• enable used to return the full tool list, and the documented next step is tools —so the workflow paid for the same list twice, 1,567 tokens instead of 780. enablenow returns a count and a pointer to the next action.
• Model-facing JSON is serialized compactly. Indentation is not information, andpretty-printing measured 31% more tokens on the same payload.
• The capability list ships inside the tool description rather than behind a searchcall — see the accuracy table below for what that bought.

Measured tool-selection accuracy

Saving context is worthless if the model then picks the wrong tool. So that is measuredtoo, against Qwen3.8-27B running locally at temperature 0 — 28 tasks with knownanswers, of which 6 need no tool at all and calling one is scored as a failure.

pnpm bench:accuracy

Same accuracy on a twelfth of the resident context — and fewer total tokens. 1,873prompt tokens per task against 7,269, summed across every turn of the multi-turnprotocol. The penalty a broker is supposed to pay for extra round trips did not appear.

The classic setup's single failure is worth naming: asked "Is 97 a prime number?", themodel with 47 tools resident reached for sequentialthinking. Every hub condition with ausable catalog scored 100% on the no-tool tasks.

The vague-catalog row is the same code and the same servers — only the descriptionsdiffer. Write your catalog so it can be found; it is worth ~14 points.

The hub rows are multi-turn against live child processes, so borderline tasks move a fewpoints between runs. Across three runs the classic condition reproduced at exactly 96.4%every time and the shipped hub scored 96.4–100%; the two ablation rows always landed belowboth, never above.

Head to head against Tool Search

Everything above compares this broker to a static configuration, which cannot support aclaim of being better than the other lazy approaches. So they were measured too — same28 tasks, same model, and a tool_search condition built the way Anthropic's Tool SearchTool and Claude Code's MCP Tool Search work, with real semantic retrieval.

pnpm bench:head-to-head

Read this honestly: it is a tie on accuracy, and Tool Search is the more compactdesign. 75 resident tokens against 709, and it does not grow with the catalog, becauseits resident surface is one query string. This project's surface carries an action enum, apayload field and an inlined capability list.

What both lazy approaches do beat is a static list: about a fifth of the prompt tokens,and 100% on the six tasks where the correct answer is to call nothing, against classic's83.3%.

Where this broker still earns its place is the axis none of these numbers cover — it keepscapabilities stopped, not merely hidden, and it carries permissions, configuration andhuman approval that a search tool has no opinion about. The comparison is also unfair inour favour in one way that is spelled out in the write-up: the Tool Search index assumesevery server has already been enumerated, and its embedding model is not charged for.

Full tables for both scales, the failure analysis and the prior-art section are indocs/context-economy.md.

Raw per-tool measurements are committed under bench/snapshots/, thetoken report in bench/results.json, the accuracy report inbench/accuracy.json and the comparison inbench/head-to-head.json, so every table can be re-derivedwithout network access.

Proof that it is actually dynamic

The table above shows what the model does not have to carry. This shows the otherhalf — that a capability nobody loaded at startup can be found by intent, opened, usedfor a real tool call, and shut down again. Nothing in it is mocked: the child is thepublished @playwright/mcp package.

pnpm proof

host-visible tools          capability_hub

search (by intent)              72 tokens   playwright found, enabled=false
inspect (permissions)          121 tokens   permissions listed, still stopped
enable (starts process)         22 tokens   real child process, 24 tools live
tools (schemas withheld)       558 tokens   names + descriptions, schemasIncluded=false
tools (narrowed by query)       60 tokens   matched 1 of 24
tools (one schema, opt-in)     144 tokens   schema returned only when asked
call (real child tool)         107 tokens   browser_navigate executed
disable (stops process)         11 tokens   wasEnabled=true
search (after disable)          72 tokens   enabled=false again

Each step is asserted, not just printed: the run fails if more than one tool is exposedto the host, if a capability reports itself running before enable, if a child schemaappears in the default tools listing, if includeSchema is ignored, if the query doesnot narrow the list, or if the capability is still marked running after disable. Thereceipt is written to bench/dynamic-proof.json.

The contrast with a static configuration is the point: those same 24 Playwright toolscost 3,383 resident tokens in every prompt of every turn, whether or not the task evertouches a browser. Here they cost nothing until the model asks, and 24 tools' worth ofnames costs 558 tokens once — or 60 if it already knows what it wants.

Why it exists

Large static MCP configurations waste context and make tool choice noisier. Capability Hub keeps the model-facing surface stable:

search → inspect → enable → tools → call → disable

• One fixed schema stays in the Harness prompt.
• Child tool schemas remain outside the model context until requested.
• tools returns names and descriptions by default; full schemas are opt-in.
• MCP processes start lazily and live only for the hub process lifetime.
• Skills are discovered by metadata and loaded one at a time.
• Third-party additions enter a human approval queue; the model cannot self-approve executable code.

Quick start

Requirements: Node.js 22.19+ and pnpm.

git clone https://github.com/NeoXider/neoxider-mcp-hub.git
cd neoxider-mcp-hub
pnpm install --frozen-lockfile
pnpm test
pnpm client -- --json '{"action":"search","query":"demo"}'

The default catalog contains only a bundled echo MCP and an example ML skill. Tests do not download or execute third-party packages.

DeepSeek Harness setup

Build the hub, then merge examples/dsh/cordis.patch.yml into the active Harness Web profile and adjust the absolute repository path. Restart Harness.

pnpm build

Harness will expose one model-facing tool:

mcp__capability_hub__capability_hub

Start with:

{"action":"search","query":"web research"}

Model-facing contract

The public schema is intentionally flat so constrained-decoding engines such as LM Studio can compile it reliably. Arbitrary child arguments travel as JSON strings.

Discover and call a tool:

{"action":"tools","name":"web-search-neo"}

{
  "action": "call",
  "name": "web-search-neo",
  "tool": "web_info",
  "payloadJson": "{\"topic\":\"search_status\"}"
}

Available actions:

Real integration examples

Ready-to-review proposals are included for:

• Web Search Neo — dynamic web research and browser tooling.
• Unity CLI MCP — the official Unity CLI transport. Its tool list is populated only while a Unity Editor with Unity Pipeline is connected.

These files are examples, not silently trusted defaults. Review paths, versions and permissions before approval.

Human-gated installation

Model-created proposals are stored under data/state/pending and cannot execute. Approve from a separate human-operated command:

node dist/src/admin.js approve <proposal-id> --catalog .\data\catalog.json --state .\data\state --yes

Then call catalog.reload and enable. Prefer pinned package versions or immutable Git revisions; avoid floating latest installers in approved entries.

Catalogs, secrets and skills

• MCP transports: stdio and streamable-http.
• Templates: ${catalogDir}, ${packageDir} and explicitly allowlisted ${config:key} values.
• Secrets: environment-variable references only. Secret-like model configuration keys are rejected.
• Skills: approved local Markdown files, loaded on demand, limited to 256 KiB. Resolved paths must remain under the catalog/package directory; an external directory requires an explicitly reviewed skill.allowedRoots entry.
• State: runtime config and proposals are ignored by Git.

Strict Harness model smoke

The reusable smoke creates an isolated temporary DSH_HOME, forces the read-only permission preset, and starts a new headless session. Its isolated hub state contains approved metadata only for the Web Search Neo and Unity CLI examples; neither capability is started. The smoke validates exactly seven calls through the single outer hub tool — search, inspect, tools, call (add with 2 + 3), skill.load, status, disable — followed by the exact assistant token CAPABILITY_HUB_SMOKE_OK. Retries, other tools, missing results, tool errors, or extra final text fail validation.

The compact JSON receipt under data/state/smoke-receipts records the final assistant text, catalog visibility, selected Harness provider/model, permission preset, action sequence, and model lifecycle. Before loading LM Studio, the smoke checks the process list: an already-loaded matching model is reused and never unloaded by the smoke; a model loaded by the smoke is released after the Harness evidence receipt has been persisted (with TTL as a fallback).

pnpm smoke:harness

For a stricter source-checkout-only proof, the optional external smoke uses the pinnedlocal @playwright/[email protected] dev dependency. Qwen must discover it, inspect it,explicitly enable it, list the narrowed navigation tools, call browser_navigate on aninert data: page, load the bundled skill, observe the child running, disable it, andfinally observe an empty enabled list. The receipt rejects retries, any second outertool, tool errors, a different model, an unverified page title, or a child that remainsenabled. The browser is headless and isolated, writes only below the temporary smokehome, and the command never downloads a package:

pnpm smoke:harness:external

The ordinary pnpm smoke:harness remains the fast bundled/offline-contract smoke anddoes not require Playwright.

With no model overrides, the default lmstudio smoke reads lms ls --json and deterministically selects the smallest already-installed trainedForToolUse LLM (size first, then modelKey). Its modelKey is also used as the Harness API model identifier. The smoke never downloads a model. Context is 32K and the idle TTL fallback is one hour. Explicit overrides keep the requested model and disable auto-selection:

$env:CAPABILITY_HUB_SMOKE_MODEL = "another-api-identifier"
$env:CAPABILITY_HUB_SMOKE_MODEL_KEY = "installed-lm-studio-model-key"
$env:CAPABILITY_HUB_SMOKE_RECEIPT = "C:\receipts\capability-hub.json"
pnpm smoke:harness

Set CAPABILITY_HUB_SMOKE_DSH_ENTRY when Harness is installed outside C:\AI\work\deepseek-harness-runtime. For non-LM-Studio providers, set CAPABILITY_HUB_SMOKE_PROVIDER and, when needed, CAPABILITY_HUB_SMOKE_PROVIDER_CONFIG_JSON; the script does not install providers or models.

See SECURITY.md for the trust boundary.

Current scope

• Tool calls are proxied; child MCP resources and prompts are not bridged yet.
• Reconnect is explicit: disable, then enable.
• Remote skill download, signature verification and sandboxed installers are future work.
• A model with unrestricted host shell access can bypass plugin-local policy; use Harness permissions as the outer boundary.

Companion project

Want a compact animated desktop view of agents, context, models, reasoning and chat? See NeoXider Agent Deck.

Contributing

Issues and focused pull requests are welcome. New integrations should include a pinned example, a narrow permission description and an end-to-end test.

MIT © NeoXider