Skip to content

Recipes knowledge base, three new catalogue servers, v0.7.0 - #9

Merged
Wixely merged 5 commits into
mainfrom
feat/recipes
Sep 1, 2026
Merged

Wixely merged 5 commits into
mainfrom
feat/recipes

Conversation

@Wixely

@Wixely Wixely commented Aug 31, 2026

Copy link
Copy Markdown
Owner

Why

Some tasks need two servers that know nothing about each other. Kodi's tools are useless until Kodi is running, but ADB can launch it on Android and Remote Admin can start it on a Windows or Linux box. An agent that works that out has nowhere to keep it, so the next session rediscovers it — or fails.

What

Recipes — a small knowledge base of "if X then Y" notes naming the servers involved. Service-agnostic: any upstream, catalogued or user-added, can appear in one.

  • Agents reach them through the proxy as recipes__list / get / add / update / remove. The host also sends MCP server instructions on connect so agents know to consult recipes before a multi-server task, or when a server's tools fail because a dependency isn't running.
  • The proxy package gains a small generic seam, ILocalToolProvider: hub-native tools advertised, routed, authorized and audited exactly like an upstream's. MCPHub.Hosting gains ProxyHostOptions.ServerInstructions.
  • Stored in recipes.json beside settings.json (atomic writes, tight size limits, corrupt file quarantined). A new Recipes page searches, adds, edits and deletes, refreshing live when an agent writes.
  • Two switches on the page: Let agents use recipes (off hides every recipes__* tool) and Let agents add and edit recipes (off leaves list/get). Enforced as the proxy's tool authorization, so they apply immediately. For headless deployments MCPHUB_RECIPES_ENABLED / MCPHUB_RECIPES_AGENT_EDIT override the settings; the page shows a pinned checkbox as locked and names the variable.

Catalogue — ADBMCPSharp, KodiMCPSharp and BambuMCPSharp, each verified against its repo config and the contents of its release zip. Kodi and ADB ship one flavour-less asset per OS and carry an AssetFileNameOverride like Slopworks. Kodi's default port (5712) collides with SQL; a change to 5719 has been requested upstream.

Single-instance guard fix — an unwritable data directory was reported as "MCPHub is already running" (exit 2, no window). Acquire now returns a three-way outcome; lock-unavailable starts the app unguarded with a warning naming the path.

Version → 0.7.0.

Verification

  • 192 tests (49 new) pass in Release; solution builds with no warnings.
  • Recipes exercised end-to-end over real HTTP through ProxyHost (instructions delivered, recipes__add writes the file).
  • A test pins the DI registration: registering ProxyHandlers by type silently dropped the providers, hence the explicit factory in Composition.cs.
  • Not yet eyeballed: the Recipes page layout (the live instance was running, so the dev build wasn't launched).

🤖 Generated with Claude Code

BS-AMcG and others added 5 commits August 31, 2026 15:10
Wixely has shipped three MCPSharp products since the catalogue was last
touched: ADBMCPSharp, KodiMCPSharp and BambuMCPSharp. Each was checked
against its repo config and the contents of its actual release zip.

Bambu follows the standard asset naming and needs nothing special. Kodi
and ADB each publish one self-contained asset per OS with no flavour
token — Kodi as {Name}-v{ver}-{os}-x64.zip, ADB as {Name}-{ver}-{os}-x64
with no "v" and a .tar.gz on Linux — so both carry an
AssetFileNameOverride that ignores the flavour setting, the same way
Slopworks does, rather than 404-ing when framework-dependent is selected.
ADB's zip nests everything under a versioned folder; the installer already
searches every depth for the executable, so that needs no change.

Ports are read from each server's own config as before. Kodi ships 5712,
which collides with SQL's default; a change to 5719 has been requested
upstream and only the README table moves when it lands.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Some tasks need two servers that know nothing about each other. Kodi's
tools are useless until Kodi is running, but ADB can launch it on
Android and Remote Admin can start it on a Windows or Linux box. An
agent that works that out has nowhere to keep it, so the next session
rediscovers it — or fails. Recipes are that place: short "if X then Y"
notes naming the servers involved, service-agnostic, so any upstream
(catalogued or user-added) can appear in one.

Agents reach them through the proxy as recipes__list / get / add /
update / remove. The tools are hub-native, so the proxy gains a small
generic seam, ILocalToolProvider, which ProxyHandlers advertises, routes,
authorizes and audits exactly like an upstream. The host also sends MCP
server instructions on connect telling agents recipes exist, to consult
them before a multi-server task or when a server's tools fail because a
dependency isn't running, and to save what they discover.

The store is recipes.json beside settings.json: atomic writes, size
limits that keep entries terse, a corrupt file quarantined rather than
overwritten. A Recipes page lets the user search, add, edit and delete
the same entries and refreshes live when an agent writes, without
clobbering an edit in progress.

Two switches on the page decide what agents may do. "Let agents use
recipes" off hides every recipes__* tool; "Let agents add and edit" off
leaves list and get only. Both are enforced as the proxy's tool
authorization, so they apply immediately — a disallowed tool vanishes
from tools/list and is refused as unknown, the same treatment an
ungranted tenant gets. For headless deployments MCPHUB_RECIPES_ENABLED
and MCPHUB_RECIPES_AGENT_EDIT override the settings, following the
MCPHUB_GITHUB_PAT convention; the page shows a pinned checkbox as locked
and names the variable. The connect-time instructions adapt too (full,
read-only, or none) and are captured when the host is built.

ProxyHandlers is registered through an explicit factory: registering it
by type made the container fall back to the registry-only constructor,
which silently dropped the providers. A test pins that registration and
another exercises the whole thing over real HTTP.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
TryAcquire answered false both when another MCPHub held the lock and
when the lock's directory could not be created, and Program.Main treated
every false as "already running". On a machine whose data directory is
unwritable that produced the wrong diagnosis — look for the tray icon,
exit code 2 — and no window, while the comment beside the early return
described the opposite intent.

Acquire now returns a three-way outcome. AlreadyHeld keeps the refusal.
LockUnavailable (directory creation failed, or the file exists but this
account cannot open it) starts the app unguarded with a warning on
standard error naming the path, since being unstartable is the worse
failure. TryAcquire remains as the boolean view for callers that only
care whether they got the lock.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Minor rather than patch: this release adds the recipes knowledge base
(a new page, five agent-facing proxy tools, MCP server instructions, and
the two access switches with their MCPHUB_RECIPES_* overrides), gives the
proxy package its ILocalToolProvider seam and Hosting its
ServerInstructions option, and catalogues three new MCPSharp servers
(ADB, Kodi, Bambu Lab).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The manual update flow ends with swapping the new build into the
folder the running executable lives in, so put a button on the page
that opens that folder in Explorer.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@Wixely
Wixely merged commit 5a8e281 into main Sep 1, 2026
1 check passed
Wixely added a commit that referenced this pull request Sep 6, 2026
Recipes knowledge base, three new catalogue servers, v0.7.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants