tidee-mcp 1.0.0 → 1.0.2

package/README.md

@@ -60,6 +60,66 @@ needs Node and a token you paste into a config file.
 `TIDEE_API_URL` exists for pointing at a local server during
 development. Leave it unset otherwise.
 
+## Releasing
+
+```sh
+pnpm run mcp:release                   # from the repo root
+cd packages/tidee-life-mcp && npm publish
+```
+
+`mcp:release` bumps the patch version and records a fingerprint of
+everything that determines what gets published — this package's source,
+`tidee-life-core/mcp`, and the runtime dependencies. CI verifies that
+record on every pipeline.
+
+That check exists because there are two of these in the wild: the hosted
+endpoint at `app.tidee.com/mcp`, which updates on every deploy, and this
+package, which updates only when somebody remembers. Sharing the tool
+definitions stops the source drifting; nothing stops the artefacts
+drifting, and when they do it is silent — package users just get older
+tools than URL users. Editing a tool description in
+`tidee-life-core/mcp` is enough to cause it, and that file is nowhere
+near this package.
+
+Publishing stays manual: it needs credentials and a 2FA code, the
+version is claimed forever, and unpublishing is heavily restricted after
+72 hours.
+
+## The MCP registry
+
+`server.json` is the registry entry. It lists BOTH ways to connect —
+the hosted endpoint under `remotes`, and this package under `packages` —
+so a client can prefer whichever suits it. The hosted one needs no token;
+this one does, which is why only the package entry declares
+`TIDEE_API_TOKEN`.
+
+Three things must agree, or publishing is rejected:
+
+| | |
+|---|---|
+| `server.json` → `name` | `package.json` → `mcpName` |
+| `server.json` → `version` | `package.json` → `version` |
+| `server.json` → `packages[0].version` | `package.json` → `version` |
+
+`mcpName` is how the registry verifies ownership: it checks that the npm
+package claims the same name the registry entry does, which stops anyone
+registering a server pointing at a package they do not own. It therefore
+has to be inside the published tarball — bump and republish before
+publishing to the registry, not after.
+
+The `com.tidee/` namespace needs DNS authentication (a TXT record on
+tidee.com) rather than the GitHub flow, so that a listing carries the
+product's own name rather than a personal account's:
+
+```sh
+brew install mcp-publisher
+mcp-publisher login dns --domain tidee.com
+mcp-publisher publish
+```
+
+The registry is in preview and warns about breaking changes, so check
+the current docs at modelcontextprotocol.io/registry before running it.
+
 ## Building
 
 ```sh

package/dist/index.js

@@ -207,6 +207,52 @@ var OAUTH_REGISTRATION_WINDOW_MS = 60 * 60 * 1e3;
 // ../tidee-life-config/dist/src/index.js
 var ALLOWED_PRIORITIZABLE_TYPES = [ITEM_TYPES.todoText.name];
 
+// ../tidee-life-core/dist/src/paths/index.js
+var paths = {
+  // Phase 4 slice F2b — the OAuth consent screen. Under /app because
+  // approving a grant needs a signed-in user; the signed request the
+  // authorize endpoint issues travels in `?request=`.
+  authorize: () => "/app/authorize",
+  activateAccount: (confirmHash) => confirmHash ? `/activate-account/${confirmHash}` : "/activate-account",
+  workspace: () => "/app/workspace",
+  forgot: () => "/forgot",
+  forgotSuccess: () => "/forgot/success",
+  // Phase 3 slice S — landing page for item-share invites. The hash
+  // is the ItemShareInvite.inviteHash carried in the recipient's
+  // email; the page decides which of the three branches to render
+  // (unauth signup CTAs / silent claim / add-and-verify) based on
+  // the caller's auth state and verifiedEmails set.
+  shareInvite: (inviteHash) => inviteHash ? `/invite/${inviteHash}` : "/invite",
+  loggedInRoot: () => "/app",
+  /**
+   * Phase 4 slice M — a link straight to one item.
+   *
+   * A query parameter on the workspace rather than a route of its own,
+   * because the destination IS the workspace: the item is opened in
+   * its box, in place, exactly as clicking it from the sidebar would.
+   * A dedicated route would have to reproduce that, and would leave
+   * the user somewhere the app has no other way of reaching.
+   *
+   * Used by the confirmations external surfaces send back — Slack and
+   * MCP — where the thing captured is otherwise out of sight.
+   */
+  workspaceItem: (itemShareId) => itemShareId ? `/app/workspace?item=${encodeURIComponent(itemShareId)}` : "/app/workspace",
+  login: () => "/login",
+  logout: () => "/app/logout",
+  notLoggedInRoot: () => "/",
+  organiser: () => "/app/organiser",
+  prioritized: () => "/app/prioritized",
+  backlog: () => "/app/backlog",
+  passwordReset: ({ passwordResetHash = null } = {}) => passwordResetHash ? `/password-reset/${passwordResetHash}` : "/password-reset",
+  passwordResetSuccess: () => "/password-reset-success",
+  resendActivationLink: () => "/resend-activation-link",
+  resendActivationLinkSuccess: () => "/resend-activation-link-success",
+  shares: () => "/app/shares",
+  signup: (organisationInviteHash) => organisationInviteHash ? `/signup/${organisationInviteHash}` : "/signup",
+  signupSuccess: () => "/signup/success",
+  verifyEmail: (token) => token ? `/app/verify-email/${token}` : "/app/verify-email"
+};
+
 // ../tidee-life-core/dist/src/mcp/tools.js
 var describeToolError = (failure) => {
   const { code, status, message } = failure ?? {};
@@ -225,6 +271,11 @@ var describeToolError = (failure) => {
     return `tidee returned ${status}.`;
   return message || "The request to tidee failed.";
 };
+var itemUrl = (api2, itemShareId) => {
+  if (!api2.appBaseUrl || !itemShareId)
+    return null;
+  return `${api2.appBaseUrl.replace(/\/+$/, "")}${paths.workspaceItem(itemShareId)}`;
+};
 var tool = (spec) => spec;
 var TIDEE_TOOLS = [
   tool({
@@ -241,10 +292,14 @@ var TIDEE_TOOLS = [
     },
     async run(api2, { text, parentId }) {
       const data = await api2.capture({ text, parentId });
-      const titles = (data.created ?? []).map((c) => c.title);
-      if (titles.length === 0)
+      const created = data.created ?? [];
+      if (created.length === 0)
         return "Nothing was created.";
-      const quoted = titles.map((t) => `"${t}"`).join(", ");
+      const titles = created.map((c) => c.title);
+      const quoted = created.map((c) => {
+        const url = itemUrl(api2, c.itemShareId);
+        return url ? `"${c.title}" (${url})` : `"${c.title}"`;
+      }).join(", ");
       if (data.usedFallback) {
         return `Saved as one item: ${quoted}. tidee could not split that into separate items, so it kept the text as given.`;
       }
@@ -372,6 +427,9 @@ var call = async (path, init) => {
   return body;
 };
 var api = {
+  // The API host and the app host are the same deployment, so the
+  // token's server is also where its items can be looked at.
+  appBaseUrl: API_URL,
   capture: ({ text, parentId }) => call("/api/v1/capture", {
     method: "POST",
     body: { text, parentId }

package/package.json

@@ -1,6 +1,7 @@
 {
 	"name": "tidee-mcp",
-	"version": "1.0.0",
+	"version": "1.0.2",
+	"mcpName": "com.tidee/tidee",
 	"description": "MCP server for tidee — let an assistant add items to your workspace, read what is there, and mark things done.",
 	"keywords": [
 		"mcp",
@@ -13,11 +14,6 @@
 	"license": "MIT",
 	"author": "tidee Ltd",
 	"homepage": "https://www.tidee.com",
-	"repository": {
-		"type": "git",
-		"url": "git+https://gitlab.com/joetidee/tidee-life.git",
-		"directory": "packages/tidee-life-mcp"
-	},
 	"bugs": {
 		"url": "https://www.tidee.com/en/contact"
 	},