@yawlabs/mcph 0.46.4 → 0.47.0

package/CHANGELOG.md

@@ -2,6 +2,11 @@
 
 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.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

@@ -342,6 +342,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.0" : "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.0" : "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.0" : "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.0" : "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.0" : "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.0",
   "description": "mcp.hosting — one install, all your MCP servers, managed from the cloud",
   "license": "UNLICENSED",
   "author": "Yaw Labs <support@mcp.hosting> (https://mcp.hosting)",