@yawlabs/mcph 0.46.4 → 0.47.1

package/CHANGELOG.md

@@ -2,6 +2,15 @@
 
 All notable changes to `@yawlabs/mcph` are documented here. This project uses [semantic versioning](https://semver.org) and a CI-gated release flow: pushing a `vX.Y.Z` tag triggers `.github/workflows/release.yml`, which publishes to npm.
 
+## 0.47.1 — 2026-04-18
+
+- **README intro rewritten to frame mcph's value vs. `claude mcp add` / hand-edited `mcp.json`** — Same forum thread (r/cursor, 2026-04-18) had a second comment that v0.47.0 didn't address: "I don't think any developer is 9$ a month afraid of json. Also all of those tools have a nicer way of installing mcp servers than editing json." Fair — the old intro led with "never hand-edit MCP JSON configs again," which is exactly the dismissal that lands. The new intro replaces that line with four concrete situations where mcph earns its keep (multi-client / multi-machine sync, `dispatch` context-pruning for large server accounts, encrypted credential centralization, A–F compliance visibility). It then *concedes* the skeptic's point directly in the last sentence: "If you use one client on one machine with a handful of servers, `claude mcp add` or hand-editing `mcp.json` is fine — mcph's value shows up when that setup stops scaling." Honest framing beats defensive framing; the people who actually have the scaling problem will self-select in.
+
+## 0.47.0 — 2026-04-18
+
+- **Compliance grade surfaces on every `discover` output, not just when `MCPH_MIN_COMPLIANCE` is set** — Previously the `[A]`/`[B]`/… tag only appeared when the user had pre-configured a floor with `MCPH_MIN_COMPLIANCE`, which meant the trust signal was invisible by default. Forum feedback (r/cursor, 2026-04-18) called this out directly: "how do you manage trust … making sure MCPs do not contain malicious code?" The grade is the answer — but only if you can see it without opting in first. Now every scored server renders with its grade inline (`github — GitHub [ready] [A]`), so the model (and the human reading the output) factors trust into activation decisions unconditionally. The `mcp_connect_discover` tool description picks this up ("treat it as a trust signal and prefer higher-graded alternatives when otherwise equivalent"). Ungraded servers still render untagged (don't punish unknown on a catalog where many entries aren't scored yet). When the floor IS set and a server is below it, the tag is replaced by the existing `(grade D — below MCPH_MIN_COMPLIANCE=B, won't auto-activate)` refusal line. Paired test: `server.test.ts` flips the "omits `[grade]` when env unset" contract to "shows `[grade]` when env unset" and keeps the ungraded-leaves-line-clean invariant.
+- **`Trust & security` section in `README.md`** — Explicit trust-model section addressing the three concerns raised in the same forum thread: (1) malicious code in MCPs, (2) prompt injection through tool output, (3) data siphoning to third parties. Takes the posture that mcph is a source of **visibility and a gate**, not a sandbox — compliance grades + `MCPH_MIN_COMPLIANCE` + `mcph compliance <target>` + `mcph servers` transparency + per-server encrypted credentials + response pruning + namespace isolation — and explicitly documents what mcph does **not** try to solve (outbound network firewalling, process sandboxing, source-hash pinning) so users know where to layer their own defenses (restricted OS user, containers, token rotation). Direct answer to the forum question rather than a hand-wave.
+
 ## 0.46.4 — 2026-04-18
 
 - **`mcph --help` Setup block rewritten for clarity** — The v0.46.3 rewrite used jargony wording ("Auto-edit an MCP client's config") and split the client list onto an ambiguous continuation line. Rewrote the three install rows to action-first prose: `install <client>` says "Configure one MCP client to launch mcph" and spells out the exact slugs (`claude-code, claude-desktop, cursor, vscode`) inline; `--list` says "List which MCP clients are installed on this machine"; `--all` says "Configure every installed MCP client in one go". Same three commands, but it now reads as plain English.

package/README.md

@@ -2,7 +2,14 @@
 
 One install. All your MCP servers. Managed from the cloud.
 
-mcph is an MCP server that orchestrates all your other MCP servers. Configure your servers once on [mcp.hosting](https://mcp.hosting), install mcph in your client, and never hand-edit MCP JSON configs again.
+mcph is an MCP server that fronts every other MCP server you use. Install it once per AI client (Claude Code, Claude Desktop, Cursor, VS Code) and your servers come from your [mcp.hosting](https://mcp.hosting) account instead of a hand-edited `mcpServers` block. It earns its keep when you hit any of these:
+
+- **More than one client or more than one machine.** Add a server once on the dashboard; every client/device picks it up on the next poll. No copy-paste of the same JSON into four config files, no per-machine drift.
+- **Tool-context bloat.** The `dispatch` meta-tool ranks your installed servers against the task at hand and loads only the top match(es). A 30-server account stays at a handful of tools in context at any moment instead of surfacing hundreds by default.
+- **API tokens you'd rather not sit in disk configs.** Credentials live encrypted on mcp.hosting and inject at spawn time. Rotate once — every client picks up the new value. Revoke the mcp.hosting token and every install stops working.
+- **A trust signal before you activate.** Every scored server renders with its A–F compliance grade in `discover`. Set `MCPH_MIN_COMPLIANCE=B` to refuse anything below.
+
+If you use one client on one machine with a handful of servers, `claude mcp add` or hand-editing `mcp.json` is fine — mcph's value shows up when that setup stops scaling.
 
 ## How it works
 
@@ -342,6 +349,25 @@ The popular Python-based MCP servers (`fetch`, `sqlite`, `time`, `sentry`, etc.)
 
 `uvx ARGS` is always rewritten to `uv tool run ARGS` at spawn time — so only `uv` needs to be reachable, not `uvx` separately. Fixes Windows setups where one was on PATH and the other wasn't.
 
+## Trust & security
+
+MCP servers are third-party code that you choose to run, and mcph launches them on your machine or calls them over the network. We don't sandbox arbitrary code and we're not an antivirus — that's your OS and network. What mcph gives you is **visibility and a gate**:
+
+- **Compliance grades (A–F)** — the `@yawlabs/mcp-compliance` suite runs 88 behavioral tests against an MCP server and reports a grade. mcp.hosting publishes grades for catalog servers; `mcph servers` shows them, and `mcp_connect_discover` surfaces them inline on every listing (e.g., `github — GitHub [ready] [A]`). Set `MCPH_MIN_COMPLIANCE=B` (or any grade) and `mcp_connect_activate` will refuse to load anything below the floor — the refusal message spells out the grade and the env var to unset. Ungraded servers always pass (don't punish unknown), so audit unknowns yourself with `mcph compliance <target>` before you rely on them.
+- **Source transparency** — `mcph servers` and the mcp.hosting dashboard show the exact `command`, `args`, and `url` each server launches with. Nothing is hidden or wrapped — if a server is `npx -y @example/foo` you see that, and you can trace it back to npm / GitHub / the remote endpoint before installing.
+- **Credentials stay encrypted at rest on mcp.hosting** — API tokens and other secrets you paste into a server's `env` block are encrypted on the backend and injected at spawn time. They don't sit in a committed `.env` file or a client config JSON, and they are never logged. Revoke the mcp.hosting token (Settings → API Tokens) and every install loses access on the next poll.
+- **Response pruning** — `MCPH_PRUNE_RESPONSES` (on by default) redacts large file-blob-shaped content before it reaches your LLM. This cuts the easiest form of cross-server prompt injection (stuffing a giant payload into a tool reply to swamp the model's context) and reduces accidental token burn. Set to `0` to disable.
+- **Namespace isolation** — tools are namespace-prefixed (`gh_create_issue`, never bare `create_issue`), so a server can't impersonate tools from another server it has no business touching. `mcp_connect_read_tool` lets you inspect a tool's schema without loading its server, so you can decide before any code runs.
+
+**What mcph does not try to solve.** mcph does not prevent a server you deliberately installed from doing harmful things inside its own process. It doesn't block outbound network traffic, firewall DNS, analyze source, or pin package hashes. A malicious server you chose to run can call any URL your machine can reach; cross-server prompt injection through tool output is a fundamentally model-layer problem that no orchestrator fully fixes. The defenses that matter for those threats live at the layer below mcph:
+
+- Review the command (`npx -y @scope/pkg`, a remote URL, …) before adding a server. If you don't recognize it, run `mcph compliance <target>` against it first.
+- Run mcph and its spawned servers under a restricted OS user or inside a container if you're handling sensitive data. mcph stays out of your sandbox's way — a restricted user will block egress just like it would for anything else.
+- Keep the mcp.hosting token scoped to the devices that need it. Rotate with `mcph install <client> --token …`; every client picks up the new value.
+- Prefer graded servers when the alternatives are otherwise equivalent. A server that can't pass the compliance suite on basic spec conformance is a worse choice than one that does.
+
+If you find a security issue in mcph itself, email `support@mcp.hosting` — details in [`SECURITY.md`](./SECURITY.md).
+
 ## Requirements
 
 - Node.js 18+

package/dist/index.js

@@ -1458,7 +1458,7 @@ function selectFlakyNamespaces(entries, limit) {
 }
 
 // src/doctor-cmd.ts
-var VERSION = true ? "0.46.4" : "dev";
+var VERSION = true ? "0.47.1" : "dev";
 async function runDoctor(opts = {}) {
   if (opts.json) return runDoctorJson(opts);
   const lines = [];
@@ -3254,7 +3254,7 @@ var LearningStore = class {
 var META_TOOLS = {
   discover: {
     name: "mcp_connect_discover",
-    description: 'List the MCP servers installed on the user\'s mcp.hosting account and ready to use. Call this when browsing what\'s available or when the task isn\'t specific yet. If the task is already clear ("file a github issue", "query postgres", "post to slack"), prefer `mcp_connect_dispatch` \u2014 it picks the right server and loads its tools in one call. Load only the servers the CURRENT task needs; each one adds tools to your context. Shows names, namespaces, tool counts, a token-cost estimate per server (e.g. "22 tools, ~2.8k tokens") so you can budget context before activating \u2014 tilde values are estimates based on cached tool metadata, unprefixed values reflect live tool schemas. Also surfaces whether each server is loaded, any local CLI it shadows (prefer the MCP tools over the CLI when a shadow is listed), and usage hints ("used Nx" or "often loaded with X") when the signals are present (counts persist across mcph restarts). Recurring packs that have been loaded together \u22652 times get their own block at the top with a ready-to-run `activate` call \u2014 skip the extra `mcp_connect_suggest` round-trip when the signal is already there. If a `mcph://guide` resource is listed, read it FIRST: it carries project/user-specific routing rules and credential conventions that override generic defaults.',
+    description: 'List the MCP servers installed on the user\'s mcp.hosting account and ready to use. Call this when browsing what\'s available or when the task isn\'t specific yet. If the task is already clear ("file a github issue", "query postgres", "post to slack"), prefer `mcp_connect_dispatch` \u2014 it picks the right server and loads its tools in one call. Load only the servers the CURRENT task needs; each one adds tools to your context. Shows names, namespaces, tool counts, a token-cost estimate per server (e.g. "22 tools, ~2.8k tokens") so you can budget context before activating \u2014 tilde values are estimates based on cached tool metadata, unprefixed values reflect live tool schemas. Scored servers carry an inline `[A]`\u2013`[F]` compliance grade from the mcp.hosting test suite \u2014 treat it as a trust signal and prefer higher-graded alternatives when otherwise equivalent (ungraded servers are unmarked, not penalized). Also surfaces whether each server is loaded, any local CLI it shadows (prefer the MCP tools over the CLI when a shadow is listed), and usage hints ("used Nx" or "often loaded with X") when the signals are present (counts persist across mcph restarts). Recurring packs that have been loaded together \u22652 times get their own block at the top with a ready-to-run `activate` call \u2014 skip the extra `mcp_connect_suggest` round-trip when the signal is already there. If a `mcph://guide` resource is listed, read it FIRST: it carries project/user-specific routing rules and credential conventions that override generic defaults.',
     inputSchema: {
       type: "object",
       properties: {
@@ -4746,7 +4746,7 @@ function categorizeSpawnError(err) {
 }
 async function connectToUpstream(config, onDisconnect, onListChanged) {
   const client = new Client(
-    { name: "mcph", version: true ? "0.46.4" : "dev" },
+    { name: "mcph", version: true ? "0.47.1" : "dev" },
     { capabilities: {} }
   );
   let transport;
@@ -5227,7 +5227,7 @@ var ConnectServer = class _ConnectServer {
     this.apiUrl = apiUrl6;
     this.token = token6;
     this.server = new Server(
-      { name: "mcph", version: true ? "0.46.4" : "dev" },
+      { name: "mcph", version: true ? "0.47.1" : "dev" },
       {
         capabilities: {
           tools: { listChanged: true },
@@ -6088,11 +6088,11 @@ var ConnectServer = class _ConnectServer {
         }
       }
       let complianceLabel = "";
-      if (minCompliance !== null && server.complianceGrade) {
-        if (passesMinCompliance(server.complianceGrade, minCompliance)) {
-          complianceLabel = ` [${server.complianceGrade}]`;
-        } else {
+      if (server.complianceGrade) {
+        if (minCompliance !== null && !passesMinCompliance(server.complianceGrade, minCompliance)) {
           complianceLabel = ` (grade ${server.complianceGrade} \u2014 below MCPH_MIN_COMPLIANCE=${minCompliance}, won't auto-activate)`;
+        } else {
+          complianceLabel = ` [${server.complianceGrade}]`;
         }
       }
       lines.push(
@@ -7572,7 +7572,7 @@ async function runUpgrade(opts = {}) {
   return { exitCode: 3, lines };
 }
 function readCurrentVersion() {
-  return true ? "0.46.4" : "dev";
+  return true ? "0.47.1" : "dev";
 }
 
 // src/index.ts
@@ -7728,7 +7728,7 @@ if (subcommand === "compliance") {
 `);
   process.exit(0);
 } else if (subcommand === "--version" || subcommand === "-V") {
-  process.stdout.write(`mcph ${true ? "0.46.4" : "dev"}
+  process.stdout.write(`mcph ${true ? "0.47.1" : "dev"}
 `);
   process.exit(0);
 } else if (subcommand && !subcommand.startsWith("-")) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yawlabs/mcph",
-  "version": "0.46.4",
+  "version": "0.47.1",
   "description": "mcp.hosting — one install, all your MCP servers, managed from the cloud",
   "license": "UNLICENSED",
   "author": "Yaw Labs <support@mcp.hosting> (https://mcp.hosting)",